[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070624070601.GB24941@kroah.com>
Date: Sun, 24 Jun 2007 00:06:02 -0700
From: Greg KH <greg@...ah.com>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: "Stefan Richter" <stefanr@...6.in-berlin.de>,
"Cornelia Huck" <cornelia.huck@...ibm.com>,
"Adrian Bunk" <bunk@...sta.de>, "david@...g.hm" <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 parallelism
control
On Wed, Jun 20, 2007 at 09:00:58PM +0000, Huang, Ying wrote:
> Hi,
>
> This is a new version of multithreaded probing patch, with more
> parallelism control added.
>
> There are more control over which devices and drivers will be probed
> parallelized or serially. For example, in IEEE1394 subsystem, the
> different "units" in one "node" can be probed serially while the
> different "nodes" can be probed parallelized.
>
> The number of threads can be controlled through a kernel command line
> parameters.
>
> The patch is against 2.6.22-rc5. The "wait_for_probes" function in the
> patch comes from the original multithreaded probing patch. If I need do
> anything because of it, please let me know.
>
> Any comment is welcome.
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
-
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