[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9D7649D18729DE4BB2BD7B494F7FEDC2180928@pdsmsx415.ccr.corp.intel.com>
Date: Sun, 24 Jun 2007 23:04:13 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: "Greg KH" <greg@...ah.com>
Cc: "Stefan Richter" <stefanr@...6.in-berlin.de>,
"Cornelia Huck" <cornelia.huck@...ibm.com>,
"Adrian Bunk" <bunk@...sta.de>, <david@...g.hm>,
"David Miller" <davem@...emloft.net>,
"bunk@...sta.de; 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 parallelismcontrol
>From: Greg KH [mailto:greg@...ah.com]
>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.
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
-
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/
Powered by blists - more mailing lists