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/
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 of buses.
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
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
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 subsystem,
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 subsystem
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
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
>-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
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
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.
-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 data.
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 there
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 type
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
> 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
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
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 call it
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 from
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 to be
20 matches
Mail list logo
