Re: [PATCH] driver core: multithreaded probing - more parallelismcontrol

[Stefan Richter]

Huang, Ying wrote:
> I think the queue IDs of different subsystem need not to be exclusive.
> The subsystem can allocate queue IDs arbitrarily. If one queue ID is
> shared between several subsystems, corresponding probing will be
> serialized. This will slow down the probing unnecessarily, but there
> will be no race condition.

Parallelism between subsystems may be interesting during boot ==
"coldplug", /if/ the machine has time-consuming devices to probe on
/different/ types of buses.  Of course some machines do the really
time-consuming stuff on only one type of bus.  Granted, parallelism
betwen subsystems is not very interesting anymore later after boot ==
"hotplug".

[...]
> Whether is it possible that a new unit is inserted during probing
> kthread is running.

Nodes and units on nodes may came and go at arbitrary points in time,
and I'm sure similar things can be said about the majority of other bus
architectures or network architectures.  We take this into account.

(The old FireWire stack will re-enter the main loop of the bus scanning
thread sometime after a bus reset event signaled that nodes or units may
have appeared or disappeared.  The new FireWire stack will schedule
respective scanning workqueue jobs after such an event.)
-- 
Stefan Richter
-=====-=-=== -==- =-=-=
http://arcgraph.de/sr/
-
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/