Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11(PCI_MULTITHREAD_PROBE)

[Cornelia Huck]

On Wed, 9 May 2007 02:25:10 -0700 (PDT),
david@xxxxxxx 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.

> step 2 can take a long time and so you want it to be async so that it's 
> timeouts can be running in parallel (for that matter step 1 may have some 
> timeouts as well)
> 
> however, you can't tell what devices to register until after step 3
> 
> so in at least some cases, it seems as if the registratin of devices needs 
> to be after the async section.

If you're talking about devices registered by the driver, these should
be in the async section.

> Linus made a good case fo an example (hard drives) where the registration 
> can happen first and fast, but the async section (spinning up) takes a 
> while and could come second.

I don't really see the difference?

> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/