Next Steps

• Write a spec? How to move to convergence rather than co-existence.
• Quantify RT overhead. Could leverage some of the work that Inaky has done.
• Determine Ingos plans. Probably the best way to do this is through code.
• Determine the best way to enable/configure RT.
• Detail and quantify the shortcomings of the futex interface.
• Topic at kernel summit??

Kernel Mutex Solutions and Drawbacks

The solutions presented are the obvious first steps to disseminating the problem. They do not constitute fully fleshed-out solution proposals.

A. Use RT Mutex in all Preemption Modes

• Creates conflict with legacy system semaphore implementation
• User space mutex development is possible logical next step for RT mutex

B. Use Robust Mutex Kernel Implementation in Non-RT configuration

• Uses RT mutex in RT mode
• Changes behavior in RT configuration
• Redundancy

C. Make Existing Projects Cooperate

• Modify low-level scheduling code of both to make them interact correctly.
• Cross-domain priority inheritance awareness changes are needed. Implement PI-awareness between FUSYN and RT mutex.
• Changes behavior in RT configuration
• Redundancy

User Space Mutex Solutions and Drawbacks

I. User Space Extension to RT Mutex
Prerequisite: (A) Use RT Mutex in all Preemption Modes

• New Library Support
• New System Call Support
• New Binary Compatibility
• New test development

• Fusyn is a Mature Implementation with foothold in the userspace community.
• FUSYN kernel portion likely obsoleted by RT implementation.
• FUSYN UserSpace implementation reusable.
• No Binary Compatibility issues for Fusyn Users
• Tests can be reused