> > Since I do get benefits on all fronts, there is no mixup in terminology· As > > long as the application can be held simple enough, an in-kernel approach > > works. At least that is my conclusion. > > The "simple enough" probably rules out almost all real interesting > applications. It does not, because only a small part of my app runs in the kernel, which is exactly the part that benefits greatly from it. It is an isolated part, with a great need for timing exactness and minimal latencies. All other processing is done in user space, with libraries, scripting languages, etc. Apache speeds up static content processing with an in-kernel module as well. If you can isolate a task that can for this or that reason be done better in the kernel in form of a driver, why not? IMNSHO several applications can benefit from such an approach. > If you have a netfilter extension, that's completely another thing. I did that, too, but for my own purposes, so some adaptions were necessary. > BTW does "realtime" not necessarily mean "fast". It means "deterministic > in time" in the very first place. Never said anything else. > You can use RTAI or similar stuff. And with RTAI you can have > Realtime-Tasks in Userspace (to put it simple). RTAI doesn't look like a sound solution to me. Too x86-centric. And LXRT (the user space/kernel space/RTAI task combination) is not that mature, and not ported. All in all RTAI does not look like a mature system at all, your mileage may differ. > You got it - the linux kernel is not for realtime and this will IMHO not > change because if you want realtime on layer X you need realtime on > layers below - with the overhead of guaranteeing the realtime behaviour > over all the layers. And a realtime application is (and must be) > designed on the whole for realtime behaviour (at least where it is > necessary and specified) - which e.g. rules out 99% of all libraries. That's why most realtime applications do not use libraries but instead bind directly to a kernel, like in eCos and VxWorks. My application does evaluate a similar approach in Linux to compare to those systems, to compare to the results with a userspace solution, and to see how hard it is to do. And all the noncritical parts are free to use as much libraries and other stuff as they want as well, so I see no such disadvantage as you mention, anyhow. > Or do you mean "realtime" as used now by marketing and sales droids as > buzzword for "it's as fast as affordable"? No, until now I mean soft realtime: The most minimal latency available with a vanilla Linux kernel. Possibly I could furthermore test the realtime capabilities of kernel from Molnar (if and only if the PowerPC gets fully supported (ktimer lacks when I last checked), or Montavista and TimeSys kernels. To be honest, I find this discussion rather fruitless, because I do not want to find another approach. I simply wanted to know what a good way is to represent an independent thread of execution - a unit of scheduling. My reasons are sound. If realtime applications can be reliably done on VxWorks or eCos or whatever, why not in Linux in-kernel? It's an idea worth evaluating. I can leverage massive amounts of widely ported, mature code and driver support, and the new realtime work. That's reason enough. With kind regards, Oliver Korpilla -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
