Approaches to realtime Linux [LWN.net]

Approaches to realtime Linux

Posted Oct 15, 2004 1:35 UTC (Fri) by karim (subscriber, #114)
In reply to: Approaches to realtime Linux by simlo
Parent article: Approaches to realtime Linux

The main reason I don't like RTAI/Fusion is that you have to make special drivers for it. If the real-time is included in the kernel you would "only" have to review the drivers and subsystems you want to call directly from you real-time threads and check their behaviour wrt. real-time. The obligation of the rest of the system is that it only holds spinlocks for a very short time and otherwise use mutexes as locks.

The point is as I made it before: for many developers, including driver developers, the kernel's behavior is not entirely clear. Add a new API and people will use it, and it will find its way into "normal" Linux drivers. And once it's everywhere we'll still be at square one in regards to finding who's influencing the latency ... The solution to this problem is to provide a very basic API that provides hard-rt while not being as simple to use as just yet another locking scheme. I believe the Adeos interrupt pipeline does this quite well for the reasons I have enumerated elsewhere, and it changes nothing to kernel's current behavior.

It is up to companies like MontaVista to test how you can change the various parameters and they can earn their living by selling that knowledge. It is also their job to check that the various subsystems behave nicely wrt. locking. Forinstance, if somebod...

Sorry, the Linux community is not about depending on any distro. The fact of the matter is that whatever new feature finds itself in the kernel out to be accessible to anyone out there who cares about that type of functionality, regardless of whether he uses Debian, MV, or if he/she builds his own from scratch. Notice that, as Jonathan points out, the existing minimal preemption functionality that's already there has not yet been adopted by all kernel developers. Certainly trying to sell this new preemption on steriods by making the case that distros will audit the kernel for their clients is likely to be received coldly.

to post comments

Approaches to realtime Linux

Posted Oct 15, 2004 9:04 UTC (Fri) by simlo (guest, #10866) [Link]

Add a new API and people will use it, and it will find its way into "normal" Linux drivers.

What new API? To be honest I think there are already too many lock-APIs in the kernel and weird kind of rules of what kind of locks should be used where. What is needed is actually a cleanup such the developer only sees one API and a generic method for locking. The specific kind of lock should be set at configuration time. The developer has to worry about is to avoid deadlocks no matter what kind of locks is used, but nothing more really. By making interrupt handlers run in threads by default it will make it a easier for the driver developer as he don't have to worry about the special rules of interrupt context.

Another of my points is that there is no "one size fits all" solution. To make a real-time system you have to configure stuff for your specific application. Thus the kernel developer should not be giving a lot of new APIs and options. He shouldn't forinstance pick at what priority his interrupt has to be performed at. He should make it such that it will work no matter what the priority is - and maybe also such it works even if it runs in interrupt context still but that could be too high a demand on him.

Sorry, the Linux community is not about depending on any distro. The fact of the matter is that whatever new feature finds itself in the kernel out to be accessible to anyone out there who cares about that type of functionality, regardless of whether he uses Debian, MV, or if he/she builds his own from scratch. Notice that, as Jonathan points out, the existing minimal preemption functionality that's already there has not yet been adopted by all kernel developers. Certainly trying to sell this new preemption on steriods by making the case that distros will audit the kernel for their clients is likely to be received coldly.

There is something called experimental drivers. I tried out the ArcNet driver on 2.6.8.1. It called a NULL'ed function pointers. Not testet at all. Somebody has to test stuff - and Linus can't verify that everything have been tested in every configuration. One could say: "remove the ArcNet driver", but that would only make it much harder to get anyone to fix it. And even after I fixed it it still didn't work with SMP and preemption. I.e. you have configurations in the default kernel which simply does not work. You need someone to veryfy your configuration. That somebody can be yourself or you can buy help from a company.

Another examble is the PPC board sitting next to me on the table. Can I make Linux run it? Yes, I can, but I need an expert for it. MontaVista and other companies offers to sell be that expertice. I can buy that or I can spend approximately 2 weeks to figure it out myself.

All I say to the kernel community is: Make these things configurable, but allow the default kernel to have clauses with "If you pick these options don't expect your kernel to be stable". Let companies like MontaVista make a living of pushing into these areas. The most important thing is to avoid code forks which will make it a mess for everybody in the long run. On the other hand make the changes to the actual kernel you build from main tree minimal by make things configurable compile time.