Re: RT patch acceptance

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2005-05-30 at 21:58 +1000, Nick Piggin wrote:
> Esben Nielsen wrote:
> 
> > I do like the idea of guest kernels - especially the ability to enforce a
> > strict seperation of RT and non-RT. But you can't use _any_ part of the
> > Linux kernel in your RT application - not even drivers. I know a lot of
> 
> If you can't use the drivers, then presumably they're no good
> to be used as they are for realtime in Linux either, though :(
> 
> In which case, you may still be better off porting the driver
> over and rewriting it to be hard-realtime than rewriting Linux
> itself ;)
> 
> But I could be wrong. I don't pretend to have the answers (just
> questions!).

Sorry Nick, I know you want out of this thread but I figured I'll just
comment on this note alone. :-)

If a driver is well written in Linux then you don't need to rewrite it
for -RT.  The thing that Ingo's locks give us is that it makes the
kernel able to preempt in more locations.  When a normal driver calls
spin_lock_irqsave in the -RT kernel, it doesn't turn off interrupts or
preemption.  A low priority RT task can be using it when a higher
priority RT task wakes up, and this won't slow down the waking of the
higher prio task. Thus, a Linux driver can be used in the -RT kernel for
RT tasks.  As long as you know the effects of using it.

I only focus on the single kernel RT approach so I'm not going to give
any comments on the single verses nano- since I don't know enough about
the nano.  But I figured I'd just comment on some of the issues of a
driver in today's Linux compared to the -RT Linux, since that part I do
know.  Actually, including the -RT into mainline would probably have
more developers help out the maintainers of the devices.  If someone has
an issue with a driver in regards to RT, then an RT programmer would
have to be the one to work on it, and the ending result should be
something that works better for the non-RT kernel. 

OK, I'll let you get back to whatever you were doing now. ;-)

-- Steve