Re: RT patch acceptance

[Esben Nielsen <simlo@phys.au.dk>]

On Wed, 1 Jun 2005, Andrea Arcangeli wrote:

> 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?
> 
It is simply not needed: Any driver suitable for SMP is using spin-locks,
which becomes mutexes when CONFIG_PREEMPT_RT is set. Therefore: SMP safe
becomes RT safe.
Ofcourse, you can manually have to grep the code for offending
local_irq_disable() or cli()'s just to make sure.

Doesn't RTAI at least in principle have the same problem? Someone might
have coded a local irq-disable directly in assambler without the official
macros? The Adeos patch wouldn't catch it then, right? (The risc of that
is very small, I know...)

Esben

-
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/