ANNOUNCE: User-space System Device Enumation (uSDE)

Quoted 6 lines · Lars Marowsky-Bree

Quoted 2 lines · Mark Bellon

The uSDE and udev are simlar in some respects. The uSDE allows for complete control of the policy handling a device - not just its naming.

Quoted 8 lines

Well, so could udev in theory, and I had this plan to enhance it to do so for the specific case of multipathing one day in the not too distant future (ie, before q1/04).

In as far as I can see, udev and uSDE really do not have too different goals. Competition is good, but only if they explore distinct approaches ;-)

There are several distinct approaches which have been enumerated in other mails.

Since this point has not been addressed, I'd like to focus on the major difference in philosophy.

SDE places all policy in the hands of the policy developer in a seperate policy program. udev places the policies in the main processing loop of the system, effectively implementing whatever policy is desired by the udev maintainers.

Without seperating policies from the core executive of device naming system, the core of udev suffers from the same issues as placing policy
in the kernel suffers. Lack of maintainability, lack of user-defined
functionality, bloat, etc.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Greg KH
Sent: Wednesday, October 29, 2003 6:44 AM
To: Steven Dake
Cc: Lars Marowsky-Bree; Mark Bellon; [email protected]; [email protected]; [email protected]
Subject: Re: ANNOUNCE: User-space System Device Enumation (uSDE)

Quoted 5 lines · Steven Dake

Quoted 4 lines · Lars Marowsky-Bree

Quoted 1 line · Mark Bellon

The uSDE and udev are simlar in some respects. The uSDE

allows for

Quoted 1 line

Quoted 1 line

Quoted 1 line

complete control of the policy handling a device - not

just its naming.

Quoted 2 lines

Quoted 2 lines

Well, so could udev in theory, and I had this plan to

enhance it to do

Quoted 1 line

Quoted 1 line

so for the specific case of multipathing one day in the

not too distant

Quoted 3 lines

Quoted 3 lines

future (ie, before q1/04).

In as far as I can see, udev and uSDE really do not have

too different

Quoted 1 line

Quoted 1 line

goals. Competition is good, but only if they explore

distinct approaches

Quoted 6 lines

Quoted 2 lines

;-)

There are several distinct approaches which have been enumerated in other mails.

Since this point has not been addressed, I'd like to focus

on the major

Quoted 3 lines

difference in philosophy.

SDE places all policy in the hands of the policy developer

in a seperate

Quoted 1 line

policy program. udev places the policies in the main

processing loop of

Quoted 1 line

the system, effectively implementing whatever policy is

desired by the

Quoted 1 line

udev maintainers.

What do you mean by "policy"?

If you are saying that SDE allows programmers the ability to write new programs to plug into your framework to create new types of policies, then I understand that. Your loadable plugins look like they support that. But they require a dynamic loader :)

What udev is doing is trying to provide a flexible policy that will work
for everyone, with a heirchy of rules that can be easily controlled and
changed by anyone who can operate a text editor (and soon to be changed
by GUI applications, like the HAL project).

I have not heard of any situation in which the current udev set of rules
do not work out for them. And if you can think of one, can't it be covered by the CALLOUT rule? For example, someone has sent me a small userspace program that works with the CALLOUT rule that handles multipath devices by talking to the dm code. Now that's pretty flexible.

If you (or anyone else) thinks of something that the existing udev rules
do not handle, please let me know. If it's too complex, then yes, the user should use write their own SDE plugin. But remember, 99.9% of the
people out there just want the LSB device names, with possibly a persistent entry for their digital camera and USB joystick, which udev handles just fine today.

For people with 4000 real scsi disks, udev also works well. That seems
to cover the wide range of users.

Quoted 2 lines

Without seperating policies from the core executive of device naming system, the core of udev suffers from the same issues as

placing policy

Quoted 1 line

in the kernel suffers. Lack of maintainability, lack of

user-defined

Quoted 1 line

functionality, bloat, etc.

Easy Separation? Hm, in looking at udev, if you just replace 2 .c files
with your new naming scheme, everything works just fine.

And if you want to go down the path of accusations about lack of maintainability, bloat, etc. I will be glad to point people at your tree
and then they can see these kinds of numbers:

For SDE:

$ find . -type f | egrep '[.c|.h]$' | xargs wc -l | tail -1
  57328 total

Wow, you build 18 shared libraries:

$ find . -type f | grep '\.so' | wc
     18      18     625

For udev:

$ find . -type f | egrep '[.c|.h]$' | xargs wc -l | tail -1
  17632 total

And that includes all of klibc, which really is not fair for udev to calculate. So let's just look at the udev code size:

$ ls | egrep '[.c|.h]$' | xargs wc -l | tail -1
   2613 total

And to be complete, let's add the totals of libsysfs and tdb, but to be
fair any udev developer never has to look into those files:

libsysfs is this big:

   3798 total

And tdb is this big:

   2679 total

So adding those numbers up we get these kinds of numbers for size of the
.c and .h files in the different projects:

	SDE:	57328 lines
	udev:	 9090 lines

That makes SDE over 6 times bigger in source code alone than all of udev (including tdb and libsysfs).

I can compare executable size too, if you really want to still claim that udev is suffering from "lack of maintainability and bloat" if you really want :)

Oh, any reason you all haven't shown a working uSDE system in public anywhere?

thanks,

greg k-h

p.s. yes, I know lines of code is a horrible metric, and doesn't really
mean squat. I just want to point out the huge size difference between the current state of udev and SDE, with pretty much identical functionality from what I can tell.

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

In my opinion, competition is good and user can choose one they like because both of them are user-space applications with a little minor kernel changes,is that right?

Here I try to summary out some difference for uSDE and uDEV,any comments are welcome! In my opinion, competition is good and user can choose one they like because both of them are user-space applications with a little minor kernel changes,is that right?

1.For the IDE/SCSI/PCI hotplug devices.
uDEV:
edit namedev.config manually to specify certain map,
if slot change or device change, user can re-edit namedev.config
uSDE
record the id or slot at the first time, when move device to new slot or change to a new same type device, automatically persist the name.
user can also specify map manually.

2.For non-hotplug device
uDEV:
not deal with it
uSDE
scan at boot time and also perform policy method. so when moved or replaced devcie when the machine is
down, the name can also be persisted.

3. for multipath device.
uDEV
not support it.
uSDE
automatically detect mulitpath device and create md device. support hot add a new path and remove a path.

4. ethernet
uDEV
not deal with it
nameif
name interface based on MAC,
uSDE
can set map based on MAC, SLOT.
support both setting manually map and automatic processing
support hotplug, eg. when exchange two device, the name can also be exchanged automatically.
.
5.devfs simulation
uDEV
No such function
uSDE
provide devfs simulation method.

Quoted 1 line

From the above comparsion, we can see uSDE really have some advantages.As far maintaince,

I think that more codes don't mean lacking maintainability.

Thanks
Guo Min

Quoted 165 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Greg KH
Sent: Wednesday, October 29, 2003 6:44 AM
To: Steven Dake
Cc: Lars Marowsky-Bree; Mark Bellon; [email protected]; [email protected]; [email protected]
Subject: Re: ANNOUNCE: User-space System Device Enumation (uSDE)

Quoted 5 lines · Steven Dake

Quoted 4 lines · Lars Marowsky-Bree

Quoted 1 line · Mark Bellon

The uSDE and udev are simlar in some respects. The uSDE

allows for

Quoted 1 line

Quoted 1 line

Quoted 1 line

complete control of the policy handling a device - not

just its naming.

Quoted 2 lines

Quoted 2 lines

Well, so could udev in theory, and I had this plan to

enhance it to do

Quoted 1 line

Quoted 1 line

so for the specific case of multipathing one day in the

not too distant

Quoted 3 lines

Quoted 3 lines

future (ie, before q1/04).

In as far as I can see, udev and uSDE really do not have

too different

Quoted 1 line

Quoted 1 line

goals. Competition is good, but only if they explore

distinct approaches

Quoted 6 lines

Quoted 2 lines

;-)

There are several distinct approaches which have been enumerated in other mails.

Since this point has not been addressed, I'd like to focus

on the major

Quoted 3 lines

difference in philosophy.

SDE places all policy in the hands of the policy developer

in a seperate

Quoted 1 line

policy program. udev places the policies in the main

processing loop of

Quoted 1 line

the system, effectively implementing whatever policy is

desired by the

Quoted 1 line

udev maintainers.

What do you mean by "policy"?

If you are saying that SDE allows programmers the ability to write new programs to plug into your framework to create new types of policies, then I understand that. Your loadable plugins look like they support that. But they require a dynamic loader :)

What udev is doing is trying to provide a flexible policy that will work
for everyone, with a heirchy of rules that can be easily controlled and
changed by anyone who can operate a text editor (and soon to be changed
by GUI applications, like the HAL project).

I have not heard of any situation in which the current udev set of rules
do not work out for them. And if you can think of one, can't it be covered by the CALLOUT rule? For example, someone has sent me a small userspace program that works with the CALLOUT rule that handles multipath devices by talking to the dm code. Now that's pretty flexible.

If you (or anyone else) thinks of something that the existing udev rules
do not handle, please let me know. If it's too complex, then yes, the user should use write their own SDE plugin. But remember, 99.9% of the
people out there just want the LSB device names, with possibly a persistent entry for their digital camera and USB joystick, which udev handles just fine today.

For people with 4000 real scsi disks, udev also works well. That seems
to cover the wide range of users.

Quoted 2 lines

Without seperating policies from the core executive of device naming system, the core of udev suffers from the same issues as

placing policy

Quoted 1 line

in the kernel suffers. Lack of maintainability, lack of

user-defined

Quoted 1 line

functionality, bloat, etc.

Easy Separation? Hm, in looking at udev, if you just replace 2 .c files
with your new naming scheme, everything works just fine.

And if you want to go down the path of accusations about lack of maintainability, bloat, etc. I will be glad to point people at your tree
and then they can see these kinds of numbers:

For SDE:

$ find . -type f | egrep '[.c|.h]$' | xargs wc -l | tail -1
  57328 total

Wow, you build 18 shared libraries:

$ find . -type f | grep '\.so' | wc
     18      18     625

For udev:

$ find . -type f | egrep '[.c|.h]$' | xargs wc -l | tail -1
  17632 total

And that includes all of klibc, which really is not fair for udev to calculate. So let's just look at the udev code size:

$ ls | egrep '[.c|.h]$' | xargs wc -l | tail -1
   2613 total

And to be complete, let's add the totals of libsysfs and tdb, but to be
fair any udev developer never has to look into those files:

libsysfs is this big:

   3798 total

And tdb is this big:

   2679 total

So adding those numbers up we get these kinds of numbers for size of the
.c and .h files in the different projects:

	SDE:	57328 lines
	udev:	 9090 lines

That makes SDE over 6 times bigger in source code alone than all of udev (including tdb and libsysfs).

I can compare executable size too, if you really want to still claim that udev is suffering from "lack of maintainability and bloat" if you really want :)

Oh, any reason you all haven't shown a working uSDE system in public anywhere?

thanks,

greg k-h

p.s. yes, I know lines of code is a horrible metric, and doesn't really
mean squat. I just want to point out the huge size difference between the current state of udev and SDE, with pretty much identical functionality from what I can tell.

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Here I try to summary out some difference for uSDE and uDEV,any comments are welcome! In my opinion, competition is good and user can choose one they like because both of them are user-space applications with a little minor kernel changes,is that right?

1.For the IDE/SCSI/PCI hotplug devices.
uDEV:

edit namedev.config manually to specify certain map, if slot change or device change, user can re-edit namedev.config

uSDE
record the id or slot at the first time, when move device to new slot or change to a new same type device, automatically persist the name.
user can also specify map manually.

2.For non-hotplug device

uDEV:
not deal with it

uSDE
scan at boot time and also perform policy method. so when moved or replaced devcie when the machine is
down, the name can also be persisted.

3. for multipath device.
uDEV
not support it.

uSDE
automatically detect mulitpath device and create md device. support hot add a new path and remove a path.

4. ethernet
uDEV
not deal with it

nameif
name interface based on MAC,
uSDE
can set map based on MAC, SLOT.
support both setting manually map and automatic processing
support hotplug, eg. when exchange two device, the name can also be exchanged automatically.
.
5.devfs simulation
uDEV
No such function

uSDE
provide devfs simulation method.

Quoted 1 line

From the above comparsion, we can see uSDE really have some advantages.As far maintaince,

I think that more codes don't mean lacking maintainability.

Thanks
Guo Min

Hi folks,

On Wed, 29 Oct 2003 13:12:26 +0800 "Guo, Min" <[email protected]> wrote:

[snip]

Quoted 2 lines

In my opinion, competition is good and user can choose one they like because both of them are user-space applications with a little minor kernel changes,is that right?

[snip]

Will udev make devlabel use no longer useful? Feel free to send flames if it's not comparable..
http://www.lerhaupt.com/devlabel/

Quoted 3 lines · Min

5.devfs simulation
uDEV
No such function

Huh? All it needs is a single config file to be created. As the current installed base of devfs users can probably all fit into my basement with room to spare, and no one is coming up with such a file for udev yet, I don't think this is a real need yet :)

Quoted 1 line · Min

2.For non-hotplug device

Quoted 2 lines

uDEV:
not deal with it

See Robert Love's very simple script to populate stuff from sysfs. It can run from initscript just like SDE. But in the end, udev will end up in initramfs and we will not need to do this.

Quoted 2 lines · Greg KH

Quoted 1 line · Min

2.For non-hotplug device

[...]

Quoted 6 lines

Quoted 2 lines

uDEV:
not deal with it

See Robert Love's very simple script to populate stuff from sysfs. It can run from initscript just like SDE. But in the end, udev will end up in initramfs and we will not need to do this.

So the intent is to have compiled-in drivers for already-attached devices (framebuffer, system disks, loop, whatever) generate calls to /sbin/hotplug within initramfs?

Mainly I'm asking because I did try putting a hotplug script into an initramfs a few weeks ago (using -test7), and it didn't appear to be invoked for e.g. the VESA framebuffer. So I want to make sure this is a "future" capability and not something that should have worked :-)

On Thu, Oct 30, 2003 at 07:45:08PM -0500, David Dodge wrote:

Quoted 4 lines

Mainly I'm asking because I did try putting a hotplug script into an initramfs a few weeks ago (using -test7), and it didn't appear to be invoked for e.g. the VESA framebuffer. So I want to make sure this is a "future" capability and not something that should have worked :-)

This is something that should have worked for you today, /sbin/hotplug does get called during early boot, before init is started up.