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