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

2007-07-03 Thread Cornelia Huck
On Fri, 22 Jun 2007 09:52:38 +, "Huang, Ying" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: > > Parallelism between subsystems may be interesting during boot == > > "coldplug", /if/ the machine has time-consuming devices to probe on > > /different/ types

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

2007-06-24 Thread Stefan Richter
Greg KH wrote: > 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 :) Yes, it should first be shown (with subsys

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

2007-06-24 Thread Greg KH
On Wed, Jun 20, 2007 at 09:00:58PM +, 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 subsyst

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

2007-06-21 Thread Huang, Ying
On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: > Parallelism between subsystems may be interesting during boot == > "coldplug", /if/ the machine has time-consuming devices to probe on > /different/ types of buses. Of course some machines do the really > time-consuming stuff on only one t

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

2007-06-21 Thread Stefan Richter
Huang, Ying wrote: > I think the queue IDs of different subsystem need not to be exclusive. > The subsystem can allocate queue IDs arbitrarily. If one queue ID is > shared between several subsystems, corresponding probing will be > serialized. This will slow down the probing unnecessarily, but ther

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

2007-06-21 Thread Huang, Ying
>-Original Message- >From: Stefan Richter [mailto:[EMAIL PROTECTED] >> 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

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

2007-06-21 Thread Stefan Richter
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

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

2007-06-20 Thread Huang, Ying
On Wed, 2007-06-20 at 17:09 +0200, Stefan Richter wrote: > I'd call it probe_queue_number or maybe probe_queue_id. The term "no" > is ambiguous. Yes, I think probe_queue_id is better. > Is the queue number kernel-global or per subsystem? The queue number is kernel-global. I think this is easy t

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

2007-06-20 Thread Stefan Richter
> Huang, Ying wrote: ... >> + * @probe: probing infromation include probing function and parameter > ^^^ > typo: information Also, the meaning of the rest of the sentence is unclear. -- Stefan Richter -=-=-=== -==- =-=-- http://arcgraph.de/sr/ - To unsubscribe fr

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

2007-06-20 Thread Stefan Richter
Huang, Ying wrote: > This is a new version of multithreaded probing patch, with more > parallelism control added. Thanks. (I'd like to try it out but will probably be busy with other stuff during the next few weeks.) ... > A field named "probe_queue_no" is added to "struct device", which I'd ca