Messages in this thread |  | | | Date | Wed, 1 Jun 2005 21:22:24 +0200 | | From | Andrea Arcangeli <> | | Subject | Re: RT patch acceptance |
| |
On Wed, Jun 01, 2005 at 07:53:11PM +0200, Thomas Gleixner wrote: > Thank god thats not the case. We did a patent research on this last year > and the result was that you can replace the cli/sti by a software flag > in the OS itself without violating the patent.
Did you publish something about it (so that people won't have to do it over and over again)?
> The combination of replacing it in the host OS and running said host OS > as an idle task of the underlying RTOS would violate the patent. > > So if PREEMPT-RT would use a soft cli/sti emulation, no problem should > arise.
So I wonder why it doesn't do that and it leaves local_irq_disable uncovered making it a "metal hard" instead of "ruby hard" like rtai.
Why should preempt-RT leave any driver out there capable of breaking the RT guarantee when it can simply redefine local_irq_disable too like rtlinux? That sounds just wrong.
I'm talking about this:
#define local_irq_disable() do { __asm__ __volatile__("cli": : :"memory"); trace_irqs_off(); } while (0) Why is the "cli" still there and capable of breaking the hard-RT every time a driver (out of the kernel, whatever kernel module) calls it?
The software (and not hardware) local_irq_disable is the fundamental piece of the "ruby hard" RT-guarantee. Be it done like in rtlinux, or with a nanokernel hypervisor like in RTAI.
I don't get why preempt-RT doesn't fix this _last_ bit too to become a "ruby hard" solution fully equivalent to RTAI and rtlinux.
Perhaps that's planned and not yet implemented? - 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/
|  |