Re: [PATCH] driver core: multithreaded probing - more parallelism control

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Huang, Ying wrote:
>> Is the queue number kernel-global or per subsystem?
> 
> The queue number is kernel-global.

Then there is an API required to allocate and deallocate exclusive queue
IDs.  This feels strange as a mechanism for (de-)serialization, and
might introduce some bulk WRT code and data.

Really, I don't believe there is anything else required from subsystems'
point of view than
  - the possibility to keep plain serial driver matching/probing,
  - to allow unrestricted parallelism,
  - to mark devices whose child devices shall be matched/probed
    serially.

Should there be a subsystem which has more special demands on mixture of
parallelism and serialization, it can easily use private means to
serialize certain parts of driver probes, for example with the familiar
mechanism of mutexes.

Or if need be, such a subsystem can implement its own threading model.
The FireWire subsystem for example first fetches so-called configuration
ROMs from each node on a bus by means of asynchronous split
transactions.  The ROMs are scanned for device properties and
capabilities, and then drivers are matched/probed.  The new FireWire
subsystem currently uses workqueue jobs to read the ROMs.  The old
FireWire subsystem uses one kernel thread per bus.  Before the new
FireWire subsystem was announced, I planned to let the bus kthread spawn
node kthreads which (1) fetch and scan ROMs and (2) match and probe
drivers for each unit in a node.

If the old FireWire subsystem had a future, I would most certainly not
use your mechanism but implement what you described.  I am not sure
about the new FireWire subsystem; there isn't much practical experience
with it yet.
-- 
Stefan Richter
-=====-=-=== -==- =-=-=
http://arcgraph.de/sr/