This shows you the differences between two versions of the page.
| 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> | ||