On Wed, 9 May 2007, Cornelia Huck wrote:
On Wed, 9 May 2007 02:25:10 -0700 (PDT),
[email protected] wrote:
makeing up an example
today the process would be
call driver X to initialize it's devices.
driver X follows these steps
1. see if a compatible chipset/device appears to be available
2. initialize the chipset/device (loading firmware)
3. query the now partially initialized chipset/device to see what specific
options are enabled in the hardware
4. for each 'thing' that's enabled in hardware, initialize and register
it.
The sync ->probe() could return after step 1 (when it is clear the
driver wants to bind to the device). The remainder should be done in
the async function, so that the bus could go on with other devices. The
driver should then signal when it is done with its registrations.
but then won't the devices get registered in a random order? (i.e.
whenever the async portion finishes the probing and finds the details of
what there is to register)
to acommodate both of these device models it seems to me that you can't
defice either
async followed by sync
or
sync followed by async
but instead need to support the combined
sync followed by async followed by sync.
now, it's very possible that I'm mistaken and one of the two-part models
can be used for everything, if so then it's definantly simpler to do so.
Hm, maybe I'm dense, but I really don't understand the problem here.
Why should (optional) sync followed by (optional) async followed by bus
synchonization not cover all cases? The async portion can also do some
"sync" stuff and then signal completion, can't it?
If you're worried about notifications to userspace, you could first
suppress the add uevent via uevent_suppress and then generate it when
you signal completion to the bus.
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.
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
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]
