Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jun 01, 2005 at 09:34:58PM +0200, Esben Nielsen wrote:
> It is simply not needed: Any driver suitable for SMP is using spin-locks,
> which becomes mutexes when CONFIG_PREEMPT_RT is set. Therefore: SMP safe
> becomes RT safe.
> Ofcourse, you can manually have to grep the code for offending
> local_irq_disable() or cli()'s just to make sure.

There's a significant number of local_irq_disable across the kernel, I
don't see why should we risk a driver update possibly looping a bit too
logn, to break the RT guarantee. It's not too hard to reach the hundred
usec range when doing hardware operations in inefficient drivers when
touchign the mmio/io regions. That would not be a bug in any config but
preempt-RT. Possibly not nice, but not a bug (keep in mind the usb irq
in my firewall for whatever reasons keeps irq disabled for >1msec).

> Doesn't RTAI at least in principle have the same problem? Someone might
> have coded a local irq-disable directly in assambler without the official
> macros? The Adeos patch wouldn't catch it then, right? (The risc of that
> is very small, I know...)

Using cli by hand never happens anywhere, while if you grep for
local_irq_disable that happens in many drivers.

Using cli in asm is like doing memset() all over the ram... then kernel
will crash and irq will stop too ;) While local_irq_disable os far was a
supported API for drivers and generic kernel code (most commmonly used
before touching per-cpu data structures, so very common in certain part
of the kernels, including the scheduler).