Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[david@lang.hm]

On Wed, 9 May 2007, Cornelia Huck wrote:

> On Wed, 9 May 2007 09:18:10 -0700 (PDT),
> david@lang.hm wrote:
>
> > I'm not worried about notification to userspace, I'm worried about devices
> > getting registered during the async stage appearing in different orders on
> > different boots due to different timeings.
>
> Ah, now I think I understand what you mean. You're talking about stuff
> like block devices or net devices, right?

they will work as examples, but I am not sure that that is the limit of 
this sort of problem

> > if you can identify the device well enough to register it quickly then the
> > approach that Linus proposed works well, which is
> >
> > sync probe, identify devices, register devices
> > async initialize devices
> > wait for all async to complete
> >
> > however I'm talking about cases where you can't fully identify the devices
> > (at least not well enough to register them with the kernel) and am saying
> > that doing
> >
> > sync probe
> > async initialize device, register device
> > wait for all async to complete
> >
> > results in unpredictable device ordering, but if instead you did
> >
> > sync probe
> > async initialize device
> > sync wait for all async to complete, register device
> >
> > you can get back to predictable ordering
>
> Hm, so that sound like a case for a distinct setup() routine:
>
> 1. bus calls ->probe(), which return synchronously
> 2. bus calls ->probe_async() for all devices (optional)
> 3. bus waits for all probes to finish
> 4. bus calls ->setup() for all devices (which does the registering)

this is exactly what I've been trying to describe.

> (->setup() can but need not be sync, although it should be for your
> case)

if it's not sync then you have race conditions again

> Note that ordering is not guaranteed on hotpluggable busses anyway, and
> if you use ->setup() as a function that may or may not be called later
> on, there's no ordering guarantee either. (Unless the bus/device driver
> implements something to that effect, or you have udev rules in place.)

correct.

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