Sure there is.
What happens _now_ happens in an interrupt, which means that it had better
be in a kernel module. And yes, you can (and apparently do) add low-level
task switching etc, at the expense of a slower interrupt response time.
Most people don't need that. In fact, most people could probably do
perfectly well with just soft realtime, and to a lot of those people "hard
realtime" is just a marketing term.
It all tends to boil down to a device driver in the end, and the amount of
support you're willing to give it. Soft realtime can handle the rest.
Personally, I'm _not_ interested in making device drivers look like
user-level. They aren't, they shouldn't be, and microkernels are just
stupid.
> Sure. I'm not contesting the merits of using GPL modules. True, this
> is the best way to go. However, not everyone has this option and my
> claim is that this is one of the facts that is putting Linux out in the
> cold in front of the competition in regards to rt.
You know what? I don't care. If the RTAI people are trying to make it easy
for non-GPL module people, I have absolutely zero interest.
In contrast, I _am_ interested if the kernel module is required to be (a)
small, (b) clear (c) GPL. You seem to not care about any of the three
things _I_ care about.
That's ok. The GPL means that you don't have to agree with me.
> Again, from a purely technical standpoint, there are many advantages in
> having the hard-rt tasks in user-space.
That's simply not true.
In user space, you'll never get the kinds of low overheads for the _true_
hard realtime, and to me that just says that what you're talking about is
really mostly just a slightly hardened soft-realtime.
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/