On Tue, 8 May 2007 13:26:00 -0700 (PDT), [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
