How? This is something that seems very difficult to me and I'd be happy
to see how it could be done well.
> hardrealtime part could be a normal Linux driver. I don't think this has
I don't see how. Certanly you can get a kind of pseudo RT with a device driver
approach, and certainly if you turn Linux synchronization into a horrible
nightmare, you can allow for certain "rt" interrupts to have low latency.
But in this case you (A)make interrupt controller dependencies visible
throughout code , (B) make the general case run slower, and (C) make the
main kernel impossible to debug or maintain.
> to be slower, but the important part would be to make the user space
> realtime part more responsive, there of course would be a small price, but
> that could be disabled by a config option.
It's important to keep in mind the different kinds of realtime.
1. Hard realtime: Guaranteed limits on interrupt latency and RT periodic task
jitter. This is what RTLinux provides.
2. Soft realtime: Statistical measure of success.
3. Marketing realtime: Whatever you want it to mean.
(2) is an interesting problem that I am starting to believe must be addressed
via a solution for (1). But (1) has nothing to do with more responsive user
space processes. In fact "more responsive" is absolutely unrelated to hard
realtime. In Linux, "more responsive" is an average measurement: over a period
of time, processes generally run within T time units of becoming runnable.
In hard realtime, we care about the worst case.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/