Re: ANNOUNCE: User-space System Device Enumeration (uSDE)

Greg KH wrote:

>On Mon, Oct 27, 2003 at 04:09:26PM -0700, Mark Bellon wrote:
>
>> The uSDE was built in response to a set of telco and embedded community
>> requirements. We found it difficult to express our ideas. Everyone
>> wanted to see code and documentation. Here is the code and the initial
>> documentation. This is a starting point...
>>
>>
>>>If not, are you planning on merging your efforts with udev in the future?
>>>
>>>
>> It is to everyone's advantage to converge on an implementation of
>> enumeration that meets all of the requirements.
>>
>
>What are your requirements, and why does udev not meet them?  Is there
>some major disagreement between what udev does, and what you want to do?
>If so, what?
>
The requirements were collected from the OSDL CGL requirements
specification version 1.0 and 1.1 ratified September 2002. They come from
extensive discussions with the OSDL members as part of the definition of
these requirements, expounding on them:

* The embracing of all device types with no specialization or limitation.

* The ability to have total control over the handling a device via external
policy programs. Policy programs are invoked with a formal command line and
description of the event that caused there invocation.

* The "service container" concept. A device is classified (or recognized by
a pattern match) and this raises an (queued) event which is caught by a
configurable "service container". The container is an ordered list of
handlers that process the device.

* Event queuing and aggregation. Minimizing the number of program
invocations (fork/exec) is critical in embedded environments - small
processors.

* Aggressive device enumeration. Multiple concurrent policy execution and
management.

* Device information persistence is a function of device policies, not the
enumeration framework.
There are many situation where persistence is not an issue at all or only
in specific cases (like disks). Why always pay for the memory/disk, for
persistence, when it is not (always) necessary?

* Transactional protection of multiple configuration files is
necessary. Multiple configuration files must often be modified in unison
and insurance is necessary that an accurate and correct set of data is used
when processing devices.

>udev has been out in the world since April, any reason for not helping
>out with the existing project instead of going off and starting your
>own?  It's not that I mind competing projects, it's just that I don't
>see your reasoning as to why there needs to be two different ones.
>
The two packages take philosophically different approaches and arrive with
(largely) overlapping and some non-overlapping capabilities - after all
they are both trying to do "the same thing". The uSDE has strengths and
weaknesses just as udev or any program does. It is certainly possible to
discuss changes (and make patches) to udev to incorporate the key issues
addressed in the uSDE implementation.

The uSDE is an encapsulation of ideas and techniques. It is "complete"
enough for those ideas to be discussed in a community setting and we can
see how/what to move things together. Think of it as the projects "resting
place" from which to confidently discuss techniques and implementions.

mark


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