Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jun 01, 2005 at 03:58:45PM +0100, Paulo Marques wrote:
> >providing a real time operating system for running real time tasks and 
> >components and non-real time tasks; 
> >providing a general purpose operating system as one of the non-real time 
> >tasks; 
> 
> This seems like the RTAI kind of nano-kernel approach and has nothing to 
> do with the way the RT-PREEMPT patch works, AFAICS.

Well I'm very happy to hear that.

The reason I raise this topic is that the fact spin_lock_irq wasn't
disabling irqs like it does in the non-RT configuration, sounded like
the technique described in the patent and it's one technique I always
considered not-usable. I possibly wrongly remembered that redefining the
disable-interrupt operation not to disable irqs, was the crucial point
of the patent. But as I've said I'm not a lawyer and so I may have
misunderstood completely the technique that the rtlinux patent is
covering (the way patents are written is not very readable to me).

Keep in mind that you wouldn't need to remove the cli from spin_lock_irq
if all the critical sections would be deterministic. But I definitely
agree this is much better.

Still the local_irq_disable isn't redefinined in the patch (only
spin_lock_irq isn't disabling irqs), and in turn calling
local_irq_disable will truly generate hangs, and every driver should be
audited in order to be as robust as RTAI. So there's less auditing to
do, but preempt-RT is still prone to break with every new kernel patch
that has some call to local_irq_disable.