A couple things to think about:
a) Mr Gooch's hacks don't help you if your RT run queue is greater than 1.
All he has done is to create a shorter list to traverse. If you lengthen
that list by having more RT processes that want to run, you're right back
to where we started. This is one reason that I consider the changes a
hack. They don't really solve the problem, they solve a subset of the
problem and it's a very questionable subset.
b) If you can't run in the kernel, you really ought to consider upcalls from
driver's interrupt routine. What are those? Think of them as signal
handlers that you install in the driver. The driver calls these "signal"
handlers when an interrupt occurs. You could just steal the signal handler
code and use it directly but that is sort of a bummer thing to do, it's
pretty slow, about the same speed as a context switch. A better thing would
be to define a type of function that the kernel could actually execute.
Obviously, there are limitations on this function - the code & data must
be wired down, the function can't call into the kernel again, etc. But
if you had a light weight way to get out to user space when an event occurs,
you could do some rally cool things - it could well amount to you having
the speed of kernel code and the ease of use of user code.
I haven't prorotyped this so maybe I'm full of it, maybe there is some
problem that says this can't be done. So far, I don't see it but
that doesn't mean much. Anyway, I'd be a lot more inclined to look
favorably on this sort of approach - it is a lot more useful for stuff
like what you described than Mr Gooch's approach, and it is likely
to be faster. And it's just cool. Mr Gooch's hacks leave me with a sort
of tired feeling, they are definitely /not/ something you'd go write a
paper about to tell the world "look at this cool thing that we can do
in Linux". So I hope someone cares enough to think hard about this and
do something cool. If anyone is inclined, send me private mail and we'll
talk about it and try and come up with a plan.
-
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/