>Future of Real-Time Linux?

>So I’ve been thinking about real time Linux and how we actually provide an entirely separate kernel for it. I’ve been thinking, there could be a better way. Please keep in mind that I am not a kernel hacker.

What is Real-Time?
Real-time is a requirement that the worst-case response time to an event of an operating system is under some time requirement. It’s useful for multimedia, embedded devices, etc.

What is MAC (SELinux and AppArmor)?
Mandatory Access Control (or the part I am covering here) basically wraps individual running processes in there own security sandbox. Basically forcing it to run with only access to certain things.

My idea: Could we use MAC to allow some applications real-time, instead of having a separate kernel?
This would mean that when you download an application through the package manager that applications that require real-time would come with apparmor or selinux configuration files to force them to run in a real-time context.


3 thoughts on “>Future of Real-Time Linux?”

  1. >A quick browse of memory lane and you end up at around 2003, when the Realtime LSM was made.. 2004/05 saw some heated and interesting arguments about it.

    Check over at LWN/Kerneltrap to see what the reasons for it NOT to be part of mainline is.

  2. >If I recall my university time (quite far away now), a real time kernel has some internal mechanism that allow a designer to build predictable (in terms of behaviour) algorithm to constraint a processus under certain time limit. This is useful to a limited amount of desktop application and this can also impair performances of other applications.

    Actually, there are 2 separate breeds of kernel (RT and not-RT or pseudo-RT) because the needs of the users are different.
    Multimedia applications (sound or video applications), mobile applications (inside telephones, GPS devices, etc.), car on-board application or spacecraft on-board systems have similar needs: time is vital or extremely important.
    – For multimedia application it could mean that the music stops while playing it, or some artifact sounds can be heard.
    – For mobile application, this mean that when the user press the button to answer a call on his mobile phone, the response has to be instantaneous, not a few seconds later.
    – The same apply inside cars, where when you use your horn or press on the warnings button, you do not want it to have several seconds delay, you want to be sure it is triggered inside a real short time response.
    – And for space or aeronautic on-board applications this can be vital or cost effective that the system react under a certain defined and expected time constraint or it could put the mission at risk or worth.
    For a desktop user, it is a convenience if an application is ready as soon as you click on it, but if it takes a minute to load, it is not critical. On a desktop, and appart for multimedia application, time is not a constraint, the constraint is the performance perception of an application by a user. If he finds it sluggish, he might change for another one. Performance perception does not mean it has to be super fast, it means that you have to find ergonomical means to make the user feel he is not wasting his time while he performs a background computation, or simply that the user can easily finds the action he is looking for in an application (in this case this is pure ergonomic and has nothing to do with algorithm performance).

    As for MAC, this is a different topic. It is independant of time constraint. This is needed for certain users that are not necessary in the same groups as the users I mentionned in the previous paragraph. Basically, some users might need a RT kernel and do not want MAC. In case of on-board space mission, you do not want the processus to be block or killed, you prefer to try to recover from it (depending on the complexity of the processus).

    MAC is a system tool that enhance the security of a system. Whereas a RT kernel is a system that could enhance the safety of system.

    Now to come back to your question: can we use MAC to enforce RT for some applications only? This would mean being able to run two kernels in parallel, as a non-RT kernel will not (as far as I know) be able to act as a RT kernel. The internal clock, ticking and the algorithm to choose which process to run differs from RT to non-RT kernels.
    Therefore in my humble opinion and to the best extents of my knowledge, this would not be possible.
    But, it is almost 10 years since I have studied system computing (RT and so forth), things could have changed and/or my memory could have altered.

  3. >No you can’t do this. The realtime preemption patches are signifigantly deviating from upstream. Things like converting spinlocks to secretly be mutexes and whatnot. RealTime changes very fundamental parts of the kernel in (sometimes) very strange ways.

    Your idea is good, but if it could have been done it already would have been done.

Leave a Reply

Your email address will not be published. Required fields are marked *