Messages in this thread | | | Date | Sat, 25 May 2002 17:07:03 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)] |
| |
On Sun, 26 May 2002, Robert Schwebel wrote: > > Show me how you will implement a closed loop controller where the > application is _not_ implemented as a kernel module. I would really love to > do it this way, but unfortunately no one of the realtime programmers has > found a way how it can be achieved so far.
The thing is, if your whole app is really RT, then neither RTAI nor RTLinux will help you all that much.
The "user space" in RTAI ends up being equally limited as any kernel module in RTLinux. No dynamic memory allocation, no deep recursion, no regular system calls. That's just fundamental to hard realtime, and has nothing to do with any of the environments themselves.
The "advantage" of RTAI is a copyright license issue at that point, nothing more (well, you get your own address space, but since you mustn't fault anything anyway, the advantage is dubious, _and_ it certainly eats into your performance). And as explained elsewhere, I don't find that to be an advantage at all (and as pointed out by Larry, there seems to be some dubious issues about the RTAI copyright itself).
Don't get me wrong - I'd love to say that it could be easily fixed by doing xxxx, but the fact is that since the linux kernel itself isn't hard realtime, the lack of kernel services really is unavoidable.
And once you lack kernel services, from a programming standpoint it shouldn't really matter whether it's a kernel module or not. You've got basically the same amount of (or rather, "lack of") support. A lot of things are a lot easier in kernel mode (interrupts, IO etc), while you might find loading the app etc easier in the RTAI model, for example. You win some, you lose some.
Can we make the whole kernel truly hard-RT? Sure, possible in theory. In practice? No way, José. It's just not mainline enough.
So I'm agreeing with you: for true hard RT, you need a kernel module. I can't come up with a way to avoid any of the fundamental problems either..
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |