Messages in this thread | | | Date | Wed, 1 Jun 2005 17:17:01 +0200 | From | Andrea Arcangeli <> | Subject | Re: 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |