Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

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/