Re: RT patch acceptance

[hui]

On Wed, Jun 01, 2005 at 11:07:16PM +0200, Andrea Arcangeli wrote:
> Why don't you run grep yourself, this is only drivers/
> 
> ./usb/gadget/pxa2xx_udc.c:	local_irq_disable();
> ./usb/gadget/pxa2xx_udc.c:	local_irq_disable();
> ./video/aty/radeon_base.c:	local_irq_disable();

Which only supports my claim more that away from the core kernel issues
near the terminals of the call/lock graph. No working RTOS app is going
to be running on arbitrary hardware. Auditing of path and reworking them
is relatively easy as you must have noticed during the development of
this patch 6 months ago with the removal of semaphore abuses.

> As said even if all the above is audited, it _can_ break over time,
> while it wouldn't break with RTAI/rtlinux even if you infinite loop and
> hang in there.
 
> > Doesn't have to yet. Drivers are case by case problem as expected. Look
> > at the patch.
> 
> The "case by case" appoach is the problem, so that you plug an usb
> gadget in, and your robot breaks and damages stuff. That would never
> happen with RTAI/rtlinux. (ok, a bad driver could corrupt memory anyway,
> but introducing a latency problem is much easier than introducing a
> memory corruption)

This is a new patch that's not in the mainline and putting additional
hack code constraints preexisting code.

> > Wrong. I did a parallel implementation of this patch and I understand
> > the issues very clearly. Deterministic single kernel RT isn't new or
> > novel in the RTOS world (LynxOS, SGI IRIX, ...).
> 
> Don't change topic, you said local_irq_disable isn't smp safe in
> drivers...

For protecting data in SMP systems, yes. This is obivous and you know
this from the SMP conversion of Linux about 6+ years ago. Bad drivers
can be a pain, but it's really an incremental process at this time and
hasn't been bad to convert high latency points into piecewise sections.

I understand what you're referrng to but you have to understand that
the changes make the core kernel preemptive, which make this kind of
track where you deal with drivers on a case by case practical. Previous
to that, it was impossible because of the size of the kernel. The
current problems you mention is basically slop that should be reworked
to no hold that mask for extended periods of time.

> > Listen to what Ingo, me and others have said and read the patch. You're
> 
> Ingo just said that making local_irq_disable a "soft-cli" is planned.
> 
> > into the patch. Really, read the patch and stop asking question, spreading
> > FUD until then.
> 
> You're the one spreading FUD that preempt-RT is as good as RTAI, and
> even worse than local_irq_disable isn't used in drivers or not safe to
> use in smp.

preempt RT will be deterministic as this patch gets pounded more and
remaining latency paths are reworked. It hasn't been hard so far and the
results have been near perfect since the core kernel is, for the most
part, fully preemptive.

There are problem areas, but that's an excersize left for the readers
(of the patch) to discover and is not mentioned in this text. :)

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/