On Tue, Jun 12, 2007 at 04:30:57PM +0200, Stefan Richter wrote:
>
> There is so much unskilled labor in driver hacking land (I'm merely
> speaking for myself of course) that something like the driver core
> /really/ needs well-working, easy to understand, and well-documented APIs.
>
> PS: By a
On Tue, Jun 12, 2007 at 04:30:57PM +0200, Stefan Richter wrote:
There is so much unskilled labor in driver hacking land (I'm merely
speaking for myself of course) that something like the driver core
/really/ needs well-working, easy to understand, and well-documented APIs.
PS: By a
Huang, Ying wrote:
> The summary of dependency rule is as follow:
>
> 1. A flag as follow is added to struct device.
> unsigned multithreaded_probe:1;
> If it is set, the devices sub-tree with this device as root will be
> probed parallelized with other devices sub-tree. If it is clear, the
Huang, Ying wrote:
The summary of dependency rule is as follow:
1. A flag as follow is added to struct device.
unsigned multithreaded_probe:1;
If it is set, the devices sub-tree with this device as root will be
probed parallelized with other devices sub-tree. If it is clear, the
> > Index: linux-2.6.22-rc4/include/linux/device.h
> > ===
> > --- linux-2.6.22-rc4.orig/include/linux/device.h2007-06-08
> > 18:26:11.0 +0800
> > +++ linux-2.6.22-rc4/include/linux/device.h 2007-06-09
> >
Index: linux-2.6.22-rc4/include/linux/device.h
===
--- linux-2.6.22-rc4.orig/include/linux/device.h2007-06-08
18:26:11.0 +0800
+++ linux-2.6.22-rc4/include/linux/device.h 2007-06-09
19:41:03.0 +0800
Huang, Ying wrote:
> Can this mechanism solve the demand of IEEE1394 subsystem effectively?
Probably. I don't know when I will have time to try it.
(BTW, we should actually be able to probe subunits in parallel, however
I suspect that some firmwares will not tolerate this.)
...
> +/**
> + *
Hi, Stefan,
I have worked out a new patch with single-threaded unit supported in
multithreaded device probing. A new flag as follow is added to struct
device,
unsigned singlethreaded_probe:1;
Which indicate that the device node and all its children node must be
probed single-threaded. During
Hi, Stefan,
I have worked out a new patch with single-threaded unit supported in
multithreaded device probing. A new flag as follow is added to struct
device,
unsigned singlethreaded_probe:1;
Which indicate that the device node and all its children node must be
probed single-threaded. During
Huang, Ying wrote:
Can this mechanism solve the demand of IEEE1394 subsystem effectively?
Probably. I don't know when I will have time to try it.
(BTW, we should actually be able to probe subunits in parallel, however
I suspect that some firmwares will not tolerate this.)
...
+/**
+ *
>A bad API. Subsystems and the driver core will both traverse the trees
>(usually just lists) which can be built from the depend pointers, and
>the trees grow and shrink dynamically. Perhaps it would be simpler if
>the subsystem would just use a mutex per group of devices which have to
>be
Huang, Ying wrote:
>>From: Stefan Richter [mailto:[EMAIL PROTECTED]
>>
>>How can subsystems control multithreaded vs. singlethreaded probes?
>>
>>For example, the IEEE 1394 subsystem should probe different nodes in
>>parallel, but different units on the same node serially. Similar
>>requirements
>From: Stefan Richter [mailto:[EMAIL PROTECTED]
>
>How can subsystems control multithreaded vs. singlethreaded probes?
>
>For example, the IEEE 1394 subsystem should probe different nodes in
>parallel, but different units on the same node serially. Similar
>requirements exist with other hardware.
Huang, Ying wrote:
> This is another solution to implement multithreaded device matching
> (probing). The device matching is delayed until all drivers are
> registered. The driver registering is executed one by one, this
> eliminates the potential of interdependency between driver. All devices
>
Huang, Ying wrote:
This is another solution to implement multithreaded device matching
(probing). The device matching is delayed until all drivers are
registered. The driver registering is executed one by one, this
eliminates the potential of interdependency between driver. All devices
are
From: Stefan Richter [mailto:[EMAIL PROTECTED]
How can subsystems control multithreaded vs. singlethreaded probes?
For example, the IEEE 1394 subsystem should probe different nodes in
parallel, but different units on the same node serially. Similar
requirements exist with other hardware.
For
Huang, Ying wrote:
From: Stefan Richter [mailto:[EMAIL PROTECTED]
How can subsystems control multithreaded vs. singlethreaded probes?
For example, the IEEE 1394 subsystem should probe different nodes in
parallel, but different units on the same node serially. Similar
requirements exist with
A bad API. Subsystems and the driver core will both traverse the trees
(usually just lists) which can be built from the depend pointers, and
the trees grow and shrink dynamically. Perhaps it would be simpler if
the subsystem would just use a mutex per group of devices which have to
be
18 matches
Mail list logo
