linux-kernel - Re: [PATCH] driver core: multithreaded probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <467A3B9E.6040201@s5r6.in-berlin.de>
Date:	Thu, 21 Jun 2007 10:49:34 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Huang, Ying" <ying.huang@...el.com>
CC:	Greg K-H <greg@...ah.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Adrian Bunk <bunk@...sta.de>, "david@...g.hm" <david@...g.hm>,
	David Miller <davem@...emloft.net>,
	Duncan Sands <duncan.sands@...h.u-psud.fr>,
	Phillip Susi <psusi@....rr.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] driver core: multithreaded probing - more parallelism
 control

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