User Tools

Site Tools


realtime:rtl:all_topics

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
realtime:rtl:all_topics [2017/02/08 11:14]
anna-maria Add a backlink to RTL project main page
realtime:rtl:all_topics [2017/10/05 20:25] (current)
tglx Update to current state of affairs
Line 4: Line 4:
 PREEMPT_RT mainlined since the RTL collaborative project started. ​ The PREEMPT_RT mainlined since the RTL collaborative project started. ​ The
 main reason for these changes is to simplify RT interaction and main reason for these changes is to simplify RT interaction and
-integration. ​ The topics are split into different types and are listed +integration. ​ The topics are split into different types. ​ In addition ​ 
-in the planned order.  In addition to the topics listed, testing, +to the topics listed, testing, documentation,​ and LTS kernel support for 
-documentation,​ and LTS kernel support for the PREEMPT_RT patch have to +the PREEMPT_RT patch have to be done continuously.
-be done continuously.+
  
 ===== Changes to current kernel functionality ===== ===== Changes to current kernel functionality =====
-  * The CPU hotplug code needs an overhaul in general +  * The CPU hotplug code needs an overhaul in general ​- Mostly done 
-  * Some of the existing timer infrastructure needs to be rewritten +  * Some of the existing timer infrastructure needs to be rewritten ​- Initial problems solved, still work in progress 
-  * Pagefault disable/​enable handling (the kernel pagefault disable/​enable mechanism is not RT compatible. Rework it to fit RT)+  * Pagefault disable/​enable handling (the kernel pagefault disable/​enable mechanism is not RT compatible. Rework it to fit RT) - Done
  
  
 ===== Extensions to current kernel functionality ===== ===== Extensions to current kernel functionality =====
  
-  * kmap infrastructure – adaption to make it RT compatible +  * kmap infrastructure – adaption to make it RT compatible ​- Open item, no real benefit for mainline so it's postponed to the 'RT only section'​ 
-  * Additional annotation mechanisms are necessary which allow RT to substitute functionality. (Such annotations are useful in general even for non-RT as they add value by making the code clearer and the scope of functionality documented) +  * Additional annotation mechanisms are necessary which allow RT to substitute functionality. (Such annotations are useful in general even for non-RT as they add value by making the code clearer and the scope of functionality documented) ​- Work in progress 
-  * Extending debug infrastructure,​ e.g. lockdep to handle the new lock types. +  * Extending debug infrastructure,​ e.g. lockdep to handle the new lock types. ​- Open item, partial issues solved
  
 ===== Redesigning RT components ===== ===== Redesigning RT components =====
Line 26: Line 24:
   * Make use of the new annotation mechanisms   * Make use of the new annotation mechanisms
   * Soft interrupt handling – structure must be adopted to be RT compatible   * Soft interrupt handling – structure must be adopted to be RT compatible
-  * Reader/​writer lock handling - they are not scalable on RT. Find a scalable solution +  * Reader/​writer lock handling - they are not scalable on RT. Find a scalable solution ​- Replacement exists but might need to be revisited 
-  * Hotplug interaction – find a proper solution able to be compatible with RT requirements +  * Hotplug interaction – find a proper solution able to be compatible with RT requirements ​- Solved 
-  * Timer interaction – rework the kernel architecture to be compatible with RT requirements+  * Timer interaction – rework the kernel architecture to be compatible with RT requirements ​- Partially solved, work in progress 
 +  * More palatable approach to RT friendly memory management - develop an upstream acceptable solution for the RT requirements - work in progress
  
 +Various details which do not fit into any of the above categories, but need to be addressed to make RT upstream acceptable
  
-===== Redesigning components & Documentation =====+===== Documentation =====
  
-  * More palatable approach to RT friendly memory management - develop an upstream acceptable solution for the RT requirements 
   * Required to make mainline developers comfortable with it   * Required to make mainline developers comfortable with it
   * Required for driver developers   * Required for driver developers
-  * Various details which do not fit into any of the above categories, but need to be addressed to make RT upstream acceptable 
- 
  
 ---- ----
 <WRAP rightalign>​Go back to [[realtime:​rtl:​start|RTL Project Main Page]]</​WRAP>​ <WRAP rightalign>​Go back to [[realtime:​rtl:​start|RTL Project Main Page]]</​WRAP>​
realtime/rtl/all_topics.1486552469.txt.gz · Last modified: 2017/02/08 11:14 by anna-maria