[lkml]   [2005]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT patch acceptance
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-01 17:24    [W:0.156 / U:2.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site