On Wed, 9 May 2007, Cornelia Huck wrote:
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?
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
