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/