This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next 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 [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> | <WRAP rightalign>Go back to [[realtime:rtl:start|RTL Project Main Page]]</WRAP> |