On Wed, 9 May 2007 09:18:10 -0700 (PDT), [EMAIL PROTECTED] 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? > > 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) (->setup() can but need not be sync, although it should be for your case) 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.) - 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/
