Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jun 01, 2005 at 01:17:54PM -0700, Bill Huey wrote:
> stop asking FUD enabling questions until you look at the patch.

I'm reading the patch.

> with in the patch. The use of those function isn't SMP safe in drivers,

You don't know very much about local_irq_disable if you think it isn't
smp safe in drivers.

local_irq_disable is perfectly safe in drivers, infact it's _needed_
sometime to avoid race conditions with irqs.

> so any use of those functions and spin-waiting so far has already been
> reviewed and dealt with in the patch.

Even if the code after patching would be right, it _can_ break as soon
as you load a module out of the kernel, or as soon as a non-RT developer
submits a patch to the mainline.

All the problems would be solved with a "ruby hard" hard-RT appraoch
like rtlinux or RTAI, that simply does a soft-cli when cli is called.

Now tell me what do you gain by keeping premept-RT "metal hard" and
prone to break anytime somebody changes a device driver or some
networking subsystem when you can do the "ruby hard" thing like RTAI and
rtlinux do for years?

> Some of that stuff has been moved into work queues that are used to
> defer processing out-of-line, so that it doesn't effect that path.
> 
> Just about all you've been saying has been handled by the patch and I
> ask you to stop asking stupid question until you've looked at it..

The patch doesn't remove any local_irq_disable from drivers, nor it
outlaws it.

It's you who has learn what local_irq_disable does, why it's obviously
the _most_smp-safe_ function in the whole kernel (so much that it's the
only one you can use to avoids locks around per-cpu data structures to
get full scalability), and to grep for it in drivers and verify they're
still there after applying the patch, and subject to modifications and
brekages in future upgrades of the kernel.