I'm still not convinced that we need to add this kind of complexity to
the driver core, instead of just letting the individual driver
subsystems do this, if they want to do it.

Especially as no subsystem wants to do this today :)

thanks,

greg k-h
-

[ message continues ]

Yes, it should first be shown (with subsystem conversions and runtime
tests with, say, at least two different bus architectures) that features
like this really are appropriately implemented as a driver core abstraction.

I would lend a hand to put this to test, but I won't do this anymore
with the old ieee1394 subsystem, and work on the new firewire subsystem
will be focused on stabilization and feature completion in the short to
mid term.
-- 
Stefan Richter
-=====-=-=== -==- ==---
http://arcgraph.de/sr/
-

[ message continues ]

It may appear not necessary that providing more multithreaded device
probing in the driver core, but it seems more necessary that providing
more parallel control in the driver core to make some device probing
more single-threaded.

There does exist multithreaded device probing in current driver core
implementation, supposing two devices are hot-plugged at the same time.
But, many device drivers are written without this taken into account. I
think it may be better to make default device probing process more
single-threaded in the driver core. The single-thread workqueue or some
customized version of workqueue like that implemented by my patch can be
used for this. The parallel control mechanism can be used to implement
multithreaded device probing in needed subsystems too.

Best Regards,
Huang, Ying
-

[ message continues ]

No, that is a bus-specific thing, and no bus that I know of supports


But remember, the individual busses already do this all in a single
thread anyway, nothing is needed in the driver core to do this.

thanks,

greg k-h
-

[ message continues ]

On Mon, 25 Jun 2007 01:16:24 -0700,
Greg KH <greg@kroah.com> wrote:


The s390 channel subsystem busses should be fine with any parallelism,
especially as the css bus kicks off tons of probes (device recognition)
at the same time. Any ccw driver must be able to be handle to be called
for many devices in parallel as well (like, when someone attaches their
shiny new storage subsystem to the LPAR and some thousands of dasds

It is possible for busses for a small set of device drivers (like the
s390 busses; maybe there are others). It looks like a bad idea to try

I think I could make good use of some more parallelism control (for
throttling or so). Not sure if it should really sit at the driver
core level, but that would avoid reinventing the wheel.

[Goes reading the original patch]

Cornelia
-

[ message continues ]