Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[Cornelia Huck <cornelia.huck@de.ibm.com>]

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