ANNOUNCE: User-space System Device Enumeration (uSDE)

ANNOUNCE: User-space System Device Enumeration (uSDE)

[Mark Bellon]

Initial availability of User-Space System Device Enumeration (uSDE) 
package, version 0.74, can be found at http://sourceforge.net/projects/usde

The uSDE provides an open framework for the enumeration (specification) 
of system devices in a dynamic environment. Device handling is 
implemented via plug-in programs known as policy methods. Policy methods 
are free to handle their devices in any way, from trivial to complex - 
anything from providing LSB device nodes to persistent device name 
handling with
replacement and relocation strategies.

The uSDE depends on /sbin/hotplug (for dynamic insertions and removals), 
sysfs (for device information) and /proc (various pieces of 
information). It is not dependent on initrd - it explicitly scans sysfs 
upon system startup to determine the initial device ensemble.

Part of the uSDE release is a collection of sample polices:

disk-ide-policy - handles IDE, EIDE, SATA and USB-EIDE disks. Implements 
persistent device naming, automatic device replacement and automatic 
device relocation features.

disk-scsi-policy - handles SCSI, IEEE-1394, FibreChannel and USB-SCSI 
disks including multiported devices. Iplements persistent device naming, 
automatic device replacement and automatic device relocation features.

multipath-policy - handles the automatic provisioning of multipathing 
for multiported storage devices.

ethernet-policy - handles ethernet interefaces. Implements persistent 
interface naming, interface anchoring, automatic device replacement and 
automatic device relocation features.

floppy-policy - handles internal floppy disks.

simple-device-policy - a "catch all" policy for block and character devices.

devfs-policy - provides devfs device names.

lsb-policy - provides LSB device names.


Location:       http://sourceforge.net/projects/usde
Mailing list:   usde-general@lists.sourceforge.net

mark

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

[Patrick Mochel]

> Initial availability of User-Space System Device Enumeration (uSDE) 
> package, version 0.74, can be found at http://sourceforge.net/projects/usde
> 
> The uSDE provides an open framework for the enumeration (specification) 
> of system devices in a dynamic environment. Device handling is 
> implemented via plug-in programs known as policy methods. Policy methods 
> are free to handle their devices in any way, from trivial to complex - 
> anything from providing LSB device nodes to persistent device name 
> handling with
> replacement and relocation strategies.
> 
> The uSDE depends on /sbin/hotplug (for dynamic insertions and removals), 
> sysfs (for device information) and /proc (various pieces of 
> information). It is not dependent on initrd - it explicitly scans sysfs 
> upon system startup to determine the initial device ensemble.

How does uSDE relate to udev? You do not mention it in your email, though 
it claims to implement similar, if not identical functionality. Is it 
related? Is it built on top of it? 

If not, are you planning on merging your efforts with udev in the future? 

Are you using the libsysfs library for accessing sysfs data? If not, I 
highly recommend it. 

I would also recommend sending email to the linux-hotplug list, as most of 
the hotplug-related applications are discussed and developed via that 
list.


	Pat

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

[Mark Bellon]

>
>
>How does uSDE relate to udev? You do not mention it in your email, though it claims to implement similar, if not identical functionality. Is it related? Is it built on top of it?
>
The uSDE is not built on top of udev.

The uSDE and udev are similar in some respects. They both create device 
nodes. There is a lot more to handling devices than managing device nodes.

Some differences between uSDE and udev that come to mind as I type (a 
good deal of this is part of the INTRO in the uSDE tarball):

Devices are classified and an explicit, ordered list of policies are 
invoked on behalf of the devices based on that classification.

Policies are implemented as open plug-ins that have complete control 
(e.g. naming, configuration, special needs) over a device.

Multiple policies can be executed concurrently; they can be independent 
or cooperative.

All device types are embraced - ethernet, disks, cdroms, floppies, MD, 
LVM and so on. Policies can analyze data and handle complex situations 
such as ethernet interface anchoring, multiported disk handling and 
automatic multipath device management.

The concept of service agents who provide critical information to the 
enumeration framework allowing policies to handle extremely diverse 
hardware situations such as multiple chassis and geographical addressing.

The uSDE sample policies implement basic device replacement and 
relocation strategies, something that the community has been asking 
about for some time.

If you want to learn more about that differences, download the tarball 
and try it out...

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.

>Are you using the libsysfs library for accessing sysfs data? If not, I 
>highly recommend it.
>
The uSDE is not currently using the libsysfs library. The project will 
look into this in the near future.

Patches gladly accepted. :)

>I would also recommend sending email to the linux-hotplug list, as most of 
>the hotplug-related applications are discussed and developed via that 
>list.
>
>
>	Pat
>
Thanks, I'll copy them.

mark

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

[Greg KH]

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?

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.

thanks,

greg k-h

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

[Mark Bellon]

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

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

[Greg KH]

On Tue, Oct 28, 2003 at 10:47:45AM -0700, Mark Bellon wrote:
> >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:

Wait, all the Carrier Grade Linux Requirement Definition Version 2.0 say
about "Persistent Device Naming" is the following:

	OSDL CGL specifies that carrier grade Linux shall provide
	functionality such that a device's identity shall be maintained
	when it is removed and reinstalled even if it is plugged into a
	different bus, slot, or adapter.  "Device identity" is the name
	of the device presented to user space, and this identity is
	assigned based on policies set by the administrator, e.g., based
	on location or hardware identification information.

Which is all well and good, as nameif satisfies this requirement :)

But for you to read more into this, is fine, just don't say that it is
required by the CGL spec.

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

"all" is a wide range.  Do you mean you are handling ethernet devices in
uSDE?  Why when nameif is already in use by all distros today, and
satisfies almost everyone's needs.

udev does not handle network devices, because there is already
infrastructure to handle them just fine.

> * 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.

Hm, like the "CALLOUT" function in udev?

> * 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.

Ah, I love "design patterns" as much as the software engineer.  But can
you try to explain how this will help out any user?  It just seems to
make the code more complex and larger than it needs to be.

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

Wait, you say above that you have to be able to call out to "external
policy programs".  Now you say that you never want to call fork/exec,
ever.  Which is it? 

And you all _keep_ saying this without ever providing any numbers to
back this up.  Linux has the fastest fork/exec than any other OS out
there right now.  Again, do you have REAL NUMBERS that show this is a
problem?  As I've found out in testing udev, devices are slow compared
to fork/exec.  My old, slow, and no memory 300Mhz laptop can _easily_
outrun the ability for the scsi core to create virtual devices.  So much
that I have to put sleep() calls in udev just to slow it down to wait
for the kernel to catch up.  Using real scsi devices is a piece of cake,
they take seconds to initialize.

I think you have found the same thing in your testing, or so you nodded
in agreement when I said this at the last CGL meeting.

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

"Aggressive"?  That's an odd use of an adjective :)
What does this really mean, in simple terms.

> * Device information persistence is a function of device policies, not 
> the enumeration framework.

What does this mean?

> 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?

What memory?  udev is only 45Kb, static, which I know is _quite_
different from uSDE, based on the number of shared libraries you use,
and build :)

Anyway, if you don't have a rule for a device, udev just uses the kernel
name, no harm or overhead there.  What is the real point here?

> * 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.

Ah, mom and apple pie.  I love those things too.  But what is the real
point?  Don't have multiple config files?  If that's a real problem,
then don't do that.  Or put your config into a database if again, it's a
real problem.  But I don't see the problem.  An admin changes the config
file, sends a SIGHUP to the daemon, which reloads the config file, and
everyone is happy.

Why should this be any different from what runs important programs
today, like your mail or web server?

> >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.

Besides the refusal to handle network devices, I don't see any thing
that udev is lacking that uSDE has.  But I'm not too familar with uSDE,
being that it has only been released for a few days now.  If you could
point out anything that udev is lacking, I would be glad to help solve
that.

thanks,

greg k-h

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

[John Cherry]

> > 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:
> 
> Wait, all the Carrier Grade Linux Requirement Definition Version 2.0 say
> about "Persistent Device Naming" is the following:
> 
> 	OSDL CGL specifies that carrier grade Linux shall provide
> 	functionality such that a device's identity shall be maintained
> 	when it is removed and reinstalled even if it is plugged into a
> 	different bus, slot, or adapter.  "Device identity" is the name
> 	of the device presented to user space, and this identity is
> 	assigned based on policies set by the administrator, e.g., based
> 	on location or hardware identification information.

Thanks for point out the actual CGL requirement, Greg. 


> > 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.
> 
> Besides the refusal to handle network devices, I don't see any thing
> that udev is lacking that uSDE has.  But I'm not too familar with uSDE,
> being that it has only been released for a few days now.  If you could
> point out anything that udev is lacking, I would be glad to help solve
> that.
> 

The Carrier Grade Linux specification has never dictated an
implementation.  In fact, both udev and uSDE are listed as potential
implementations.

As Lars stated in an earlier email, "Competition is good, but only if
they explore distinct approaches".  It is a shame that much effort has
been duplicated here on similar approaches.  I'm not fully aware of the
history behind the divergence, but it makes sense to enumerate NOW what
is lacking in udev from a uSDE perspective.  One objective of the
carrier grade initiative is to prevent duplicate effort.  Now that we
have two implementations, let's get the issues/differences on the table
and cooperatively move to convergence.

John

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

[Greg KH]

On Tue, Oct 28, 2003 at 11:40:55AM -0800, John Cherry wrote:
> As Lars stated in an earlier email, "Competition is good, but only if
> they explore distinct approaches".  It is a shame that much effort has
> been duplicated here on similar approaches.  I'm not fully aware of the
> history behind the divergence, but it makes sense to enumerate NOW what
> is lacking in udev from a uSDE perspective.

I'm not aware of why there was a divergence in the first place either :)

As udev has been public for a long time now, would someone from Monta
Vista care to detail why they found udev lacking and deserving of a
duplicate effort?

> One objective of the carrier grade initiative is to prevent duplicate
> effort.  Now that we have two implementations, let's get the
> issues/differences on the table and cooperatively move to convergence.

I'm trying :)

greg k-h

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

[Patrick Mochel]

> 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...

I find it difficult to see your justification for designing a project from
scratch instead of contributing your time, effort, and ideas to a pair of
already existing, albeit immature, projects that do exactly the same
thing.

Please note that I'm not trying to incite yet another device naming flame
war, but you have to understand how frustrating it is to see you guys make
the same mistakes over and over, ad inifitum.

Let's review. SDET was posted several months ago by the Montavista telco
group as a 2.4 solution that was driven by customer requirements. So be
it.

In the last year, you (and/or your group) has posted several proposed
device naming solutions; each of which were shot down because of
over-design, misdirection, or simply tastelessness. Each time we
encouraged you to align yourselves with the overall design goals or simply
contribute to existing projects.

Personal contact in Ottawa resulted the same message. IIRC, many if not
all, of the atttending MV telco engineers even saw Greg's talk on udev.

In the time since, you've designed and written a solution from scratch,
without even trying to contribute to the udev effort. (And while, I might
add, another MV engineer contributed several patches to in his free time
to help package and productize it.)

I fail to see your point in this project. AFAIC, you've wasted your time.
It surely can't be customer requirements, as I highly doubt any customer
solutions are based on a 2.6 kernel yet. You've completely duplicated the
efforts of a project destined to become the de facto standard for the
requirement you're trying to fulfill, for what gain?



	Pat

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

[Mark Bellon]

Patrick Mochel 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...
>>    
>>
>
>I find it difficult to see your justification for designing a project from
>scratch instead of contributing your time, effort, and ideas to a pair of
>already existing, albeit immature, projects that do exactly the same
>thing.
>
>Please note that I'm not trying to incite yet another device naming flame
>war, but you have to understand how frustrating it is to see you guys make
>the same mistakes over and over, ad inifitum.
>
>Let's review. SDET was posted several months ago by the Montavista telco
>group as a 2.4 solution that was driven by customer requirements. So be
>it.
>
>In the last year, you (and/or your group) has posted several proposed
>device naming solutions; each of which were shot down because of
>over-design, misdirection, or simply tastelessness. Each time we
>encouraged you to align yourselves with the overall design goals or simply
>contribute to existing projects.
>
>Personal contact in Ottawa resulted the same message. IIRC, many if not
>all, of the atttending MV telco engineers even saw Greg's talk on udev.
>
>In the time since, you've designed and written a solution from scratch,
>without even trying to contribute to the udev effort. (And while, I might
>add, another MV engineer contributed several patches to in his free time
>to help package and productize it.)
>
>I fail to see your point in this project. AFAIC, you've wasted your time.
>It surely can't be customer requirements, as I highly doubt any customer
>solutions are based on a 2.6 kernel yet. You've completely duplicated the
>efforts of a project destined to become the de facto standard for the
>requirement you're trying to fulfill, for what gain?
>
>
>
>	Pat
>
>
>  
>
I can't respond to the emotion and ad hominum references in this 
message. The uSDE announcement is my first posting. I can't address any 
past dealings with MontaVista.

The uSDE ideas and implementation was started with the OSDL requirements 
in August of 2002.
This is the first time any form of it has been posted. From 
time-to-time, since the project started, ideas related to it have been 
floated with the community. The feedback was carefully listened to and 
utitized in the implementation that was just posted.

mark

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

[Chris Friesen]

Mark Bellon wrote:

> The uSDE ideas and implementation was started with the OSDL requirements 
> in August of 2002.
> This is the first time any form of it has been posted. From 
> time-to-time, since the project started, ideas related to it have been 
> floated with the community. The feedback was carefully listened to and 
> utitized in the implementation that was just posted.

When floating those ideas, was it clear that an implementation was being 
actively developed?  You could have said something when Greg posted 
version 0.1 of udev back in April.

If people had known that this was in the works, they might have chosen 
to concentrate on this rather than udev. As it is, there has been 
significant effort put into udev, and now there is duplicated 
functionality and more work will be required to figure out how to 
combine them (if that is the chosen path).

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

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

[Greg KH]

On Tue, Oct 28, 2003 at 11:12:15AM -0700, Mark Bellon wrote:
> I can't respond to the emotion and ad hominum references in this 
> message. The uSDE announcement is my first posting. I can't address any 
> past dealings with MontaVista.

It might be your first public posting.  But it is not your first email
to people here ever.  I have a few emails from you lying around here
from back in Feb and March of this year in which you detailed this
project.  And you have been aware of udev from at least April, as it's
code has been public since then.

I also have email messages from Intel employees who were helping you
with uSDE over the past few months, asking questions about different
things that udev does, in order to get a better understanding of it.
I'm guessing that was done to provide that functionality in uSDE, which
is fine.

The major frustration of mine is why, if you found udev lacking for one
reason or another, did you decide to not help us out, and instead go off
and work on your own, in secret?  We could really use the help with
udev, and having at least 2 full time people working on it (like it
looks like uSDE has) would make a real difference. 

> The uSDE ideas and implementation was started with the OSDL requirements 
> in August of 2002.
> This is the first time any form of it has been posted.

Again, in public.  I have older code drops of yours in my email folders.

> From time-to-time, since the project started, ideas related to it have
> been floated with the community.  The feedback was carefully listened
> to and utitized in the implementation that was just posted.

I have provided help to you and your team over time, but that has been a
one-way street.  Help has not flowed back the other way, even when we
have asked for it (help with udev, or with the kernel changes that are
required for udev or uSDE to work properly.)  That is why I am
frustrated, and I think that others in the open source community have
the same frustration.

udev isn't going away any time soon, and I am committed to working on it
for quite some time in order to address issues people have raised.  If
you want to spend your time on uSDE, that's up to you.  I'm very willing
to work with your team, if your team is willing to work with us.

thanks,

greg k-h

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

[Andreas Jellinghaus]

> I find it difficult to see your justification for designing a project from
> scratch instead of contributing your time, effort, and ideas to a pair of
> already existing, albeit immature, projects that do exactly the same
> thing.

Hi Patric,

maybe you can tell me:
with devfs it is _very_ simple to see what a driver does, and what
information it passes on devices. it is the major and minor number,
the device type, a name, and a default permissions (that does not
require changes in most cases).

sysfs is very sparse:
 - no (explicit) device type
   (/sys/block/ has block devices, the rest is char.)
 - no default permissions
   (the driver author often knows well, if a device should be secured
   or not. why can't he pass that information?)
 - only plain names like old /dev. I still can't see how any user space
   tool can find out, that my /sys/block/hda/ is a hard disk, and 
   /sys/block/hdc/ is a cdrom. how could any tool create /dev/discs/ and
   /dev/cdrom/ devices without that distinction?
 - why is a usb printer class usb? I thought that was the bus? shouldn't
   it be class printer (or "lp" or something like that)? how can any
   tool create /dev/printers/ devices, if it cannot see how some usb
   device is a printer or not?

and how would some driver create additional export information for many
devices? understanding how floppy.c creates devfs devices for all those
fd0u1440 and friend devices is easy. but how would that driver create
information on those devices via sysfs?

I don't know exactly what the problem with devfs is, but maybe it is
because devfs is a filesystem? if so, could devfs be turned into a
/proc/ file, so we can get all those information currently registered
by all or most devices via that file, and some small userspace tool
has a chance to create a devfs like /dev/?

if sysfs doesn't gather and export the same amount of information 
devfs does, I don't know how any tool based on sysfs can ever 
seriously replace it. you want people to join current effords
(i.e, udev+sysfs). with many open questions I don't see how that
is possible? 

finishing the sysfs documentation and porting some drivers like
floppy.c and lp.c to sysfs could help. In its current state, I
don't understand many parts of sysfs, and it looks very natural
to me, that people rather implement something from scratch if it
is easy, than try to understand some very complex.

Regards, Andreas

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

[Greg KH]

On Tue, Oct 28, 2003 at 11:59:14PM +0100, Andreas Jellinghaus wrote:
> > I find it difficult to see your justification for designing a project from
> > scratch instead of contributing your time, effort, and ideas to a pair of
> > already existing, albeit immature, projects that do exactly the same
> > thing.
> 
> Hi Patric,
> 
> maybe you can tell me:

Hm, off topic here... Oh well...

> with devfs it is _very_ simple to see what a driver does, and what
> information it passes on devices. it is the major and minor number,
> the device type, a name, and a default permissions (that does not
> require changes in most cases).
> 
> sysfs is very sparse:
>  - no (explicit) device type
>    (/sys/block/ has block devices, the rest is char.)

There's your explicitness :)

>  - no default permissions
>    (the driver author often knows well, if a device should be secured
>    or not. why can't he pass that information?)

Permissions are often _not_ known better by the driver author.  Let's
leave this up to the distro to get correct.

>  - only plain names like old /dev. I still can't see how any user space
>    tool can find out, that my /sys/block/hda/ is a hard disk, and 
>    /sys/block/hdc/ is a cdrom. how could any tool create /dev/discs/ and
>    /dev/cdrom/ devices without that distinction?

Look at the type of the device associated with the block device.  That
will tell you if it's a floppy, or cdrom, or whatever.  If IDE devices
don't export the proper info for this in sysfs, we need to fix it.  I'm
pretty sure SCSI already does.

>  - why is a usb printer class usb? I thought that was the bus? shouldn't
>    it be class printer (or "lp" or something like that)? how can any
>    tool create /dev/printers/ devices, if it cannot see how some usb
>    device is a printer or not?

The USB class is for those types of devices that use the USB major
number.  See devices.txt for a list of these devices.  There is no
"class lp" for the kernel, as devices.txt does not specify such a thing.
There are parallel port printers, serial printers, and USB printers, all
with different majors and minors.  If you want to consolidate these,
into one major and class code, please do, but that's a 2.7 issue.  For
2.6, we have to stick with what we have been doing since at least 2.2.


> and how would some driver create additional export information for many
> devices? understanding how floppy.c creates devfs devices for all those
> fd0u1440 and friend devices is easy. but how would that driver create
> information on those devices via sysfs?

The individual driver can create sysfs files using the existing sysfs
functions (like DEVICE_ATTR(), CLASS_DEVICE_ATTR(), etc.)  Or for the
block devices, create an attribute and register it with the block code
(yeah, for block devices it's harder, but not impossible.)

> I don't know exactly what the problem with devfs is, but maybe it is
> because devfs is a filesystem?

Please see the many discussions about this in the past in the
linux-kernel archives.

> if sysfs doesn't gather and export the same amount of information 
> devfs does, I don't know how any tool based on sysfs can ever 
> seriously replace it. you want people to join current effords
> (i.e, udev+sysfs). with many open questions I don't see how that
> is possible? 

sysfs does export enough information for us to do this in userspace.  If
it's missing anything, please let us know.  Again, permissions will be
done in userspace, and should not be in the kernel.

> finishing the sysfs documentation and porting some drivers like
> floppy.c and lp.c to sysfs could help. In its current state, I
> don't understand many parts of sysfs, and it looks very natural
> to me, that people rather implement something from scratch if it
> is easy, than try to understand some very complex.

See the lwn.net series about kobjects and sysfs for some other sysfs
information.  Usually driver authors will not have to care about that
stuff at all, but possibly they might want to add a file or two to
sysfs, through the driver model.  See any of the existing kernel drivers
that do this (there are a lot of them) for examples of this.

Hope this helps,

greg k-h

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

[Lars Marowsky-Bree]

On 2003-10-27T16:09:26,
   Mark Bellon <mbellon@mvista.com> said:

> 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...

That makes perfect sense. If it helped to articulate and understand your
ideas and concerns, this is certainly an important 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.

Great! However, I suggest that you should explore this idea yourself.
Only you can eventually articulate the requirements and solutions in
your code; you cannot expect others to go look at it and guess them.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett