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

Next revision
Previous revision
realtime:rtl:all_topics [2016/06/23 09:10]
anna-maria created
realtime:rtl:all_topics [2025/01/07 11:19] (current)
bigeasy All initial items are covered. Some rework is outstanding.
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 ​- Done 
-  * Some of the existing timer infrastructure needs to be rewritten +  * Some of the existing timer infrastructure needs to be rewritten ​- Mostly done. 
-  * 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 ​- Done 
-  * 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) ​- Done. 
-  * Extending debug infrastructure,​ e.g. lockdep to handle the new lock types. +  * Extending debug infrastructure,​ e.g. lockdep to handle the new lock types. ​- Mostly done.
  
 ===== Redesigning RT components ===== ===== Redesigning RT components =====
  
   * 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. Work is done. A fain grain locking is work in progress. 
-  * 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. A rework is done with multiple reader. Only the writer gets a PI boost. 
-  * 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 ​- Done. 
 +  * More palatable approach to RT friendly memory management - develop an upstream acceptable solution for the RT requirements. Done.
  
 +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>​
realtime/rtl/all_topics.1466673021.txt.gz · Last modified: 2016/06/23 09:10 by anna-maria