Mailing List Archive

> 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 this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
implemented. And the serialization demand between subsystem can be
satisfied too.

> > + * @probe: probing infromation include probing function and parameter
> ^^^^^^^^^^^
> typo: information

Sorry, I will correct it in the next version.

Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

Really, I don't believe there is anything else required from subsystems'
point of view than
- the possibility to keep plain serial driver matching/probing,
- to allow unrestricted parallelism,
- to mark devices whose child devices shall be matched/probed
serially.

Should there be a subsystem which has more special demands on mixture of
parallelism and serialization, it can easily use private means to
serialize certain parts of driver probes, for example with the familiar
mechanism of mutexes.

Or if need be, such a subsystem can implement its own threading model.
The FireWire subsystem for example first fetches so-called configuration
ROMs from each node on a bus by means of asynchronous split
transactions. The ROMs are scanned for device properties and
capabilities, and then drivers are matched/probed. The new FireWire
subsystem currently uses workqueue jobs to read the ROMs. The old
FireWire subsystem uses one kernel thread per bus. Before the new
FireWire subsystem was announced, I planned to let the bus kthread spawn
node kthreads which (1) fetch and scan ROMs and (2) match and probe
drivers for each unit in a node.

If the old FireWire subsystem had a future, I would most certainly not
use your mechanism but implement what you described. I am not sure
about the new FireWire subsystem; there isn't much practical experience
with it yet.
--
Stefan Richter
-=====-=-=== -==- =-=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

>-----Original Message-----
>From: Stefan Richter [mailto:stefanr@s5r6.in-berlin.de]
>> 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.

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
will be no race condition.

The benefit of the mechanism is that the maximum parallelism of probing
can be control.

>Really, I don't believe there is anything else required from
subsystems'
>point of view than
> - the possibility to keep plain serial driver matching/probing,
> - to allow unrestricted parallelism,
> - to mark devices whose child devices shall be matched/probed
> serially.

Maybe.

>Should there be a subsystem which has more special demands on mixture
of
>parallelism and serialization, it can easily use private means to
>serialize certain parts of driver probes, for example with the familiar
>mechanism of mutexes.
>
>Or if need be, such a subsystem can implement its own threading model.
>The FireWire subsystem for example first fetches so-called
configuration
>ROMs from each node on a bus by means of asynchronous split
>transactions. The ROMs are scanned for device properties and
>capabilities, and then drivers are matched/probed. The new FireWire
>subsystem currently uses workqueue jobs to read the ROMs. The old
>FireWire subsystem uses one kernel thread per bus. Before the new
>FireWire subsystem was announced, I planned to let the bus kthread
spawn
>node kthreads which (1) fetch and scan ROMs and (2) match and probe
>drivers for each unit in a node.

I know nothing about FireWire. If I say something nonsense, please just
ignore it.

Whether is it possible that a new unit is inserted during probing
kthread is running. If it is possible, the probing kthread maybe ignore
the new inserted unit. So a kthread for this new unit should be created
upon inserting. And there must be some synchronization mechanism
provided. So, I think something like probing queue may be better than
raw kthread for this. And the bus scanning thread may need to exist
during system running, using the probing queue the bus scanning thread
can be created and destroyed on demanded too.

Thank you very much for your comment.

Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/