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

[Mark Bellon <mbellon@mvista.com>]

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




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel