Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[david@lang.hm]

On Wed, 9 May 2007, Cornelia Huck wrote:

> On Tue, 8 May 2007 13:26:00 -0700 (PDT),
> david@lang.hm wrote:
>
> > is it really enough to do the sync followed by the async piece?
> >
> > it seems to me that there may be a need for three steps
> >
> > 1. prep (sync, what we do today)
> > which will all complete before
> > 2. parallel (async)
> > which will all complete before
> > 3. cleanup (sync)
> >
> > for some busses you can do the device enumeration in the prep phase, but I
> > would expect that for others you can't enumerate the devices until you
> > actually go looking for them. so by allowing the cleanup phase you have a
> > spot that can order everything as if the second phase was sequential.
> >
> > I would expect that almost no drivers would use all three, but I could see
> > some useing #1 and #2 while others use #2 and #3
>
> Hm, how about:
> 1. ->probe() called (wait until it is finished)
> 2. ->probe_async() called (only kick off, don't wait, go to next device)
> 3. bus waits until all async probes have returned
>
> This would imply a wait mechanism on the bus, like upping a counter for
> each successfully called ->probe_async(), the driver downing the
> counter when all actions triggered by ->probe_async() have finshed, and
> the bus waiting until the counter has reached 0.
>
> (Individual drivers can have 1., 2., or 1. & 2. A bus may support 1.
> (like now), 2. & 3. or 1., 2. and 3.)
>
> > in any case there needs to be a way to wait until the async portion
> > finishes before going on to next steps (you don't want to try to probe
> > drives for md partitions until the drives have finished spinning up for
> > example)
>
> Agreed. Would it be enough if we only have one bus in flight
> simuntaneously?

two things I see

1. why should different, unrelated busses need to wait for each other? 
picking two, why can't you have SCSI and USB going through their timeouts 
at the same time?

2. I'm not sure that you can always do the device enumeration before you 
do the slow probing, there's another message in this thread that talks 
about a USB device where you need to load firmware to it before you can 
find out what is really there. in a case like this devices would either 
show up in a random order during step #2, or they should not be added to 
the system until step #3, which makes step #3 more then just waiting for 
the async portions to finish.

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/