[cgl_discussion] Re: ANNOUNCE: User-space System Device Enumation (uSDE)

[Greg KH]

On Wed, Oct 29, 2003 at 01:12:26PM +0800, Guo, Min wrote:
> 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:

What's with the wierd intercaps of the udev name?

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

Then use something that will not change if you move the device.  Like a
serial number, or other unique identifier.  It's not udev's fault that
you used a non-flexible rule :)

Oh, and the file is called udev.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

What do you mean by this?  Memory devices?

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

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

Not true.  The CALLOUT rule handles this just fine.  I have a small
userspace program here from someone else that handles multipath devices
through the CALLOUT rule.

In fact I think this shows the flexibility of udev.  If you come up with
some new kind of device, or subsystem, or way of determining that you
want to name a device, udev can run _any_ program to do this.  No
rebuilding the code, or creating a shared library.  Small simple
programs all talking together in a universal manner.  Hm, where have I
heard that design decision before....

> 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 

And this is on purpose.  Why would we, when there are so many other
programs out there that do deal with network devices.   Remember, not
all network connections are ethernet, which shows the limitation of SDE
in not handling all of them (ppp, ipsec, usb network devices, isdn, atm,
wireless, etc.)

>  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

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 :)

But again, no rebuilding needed, if such a config file shows up, udev
will do this just fine.

>   uSDE
> 	    provide devfs simulation method.
> 
> >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.

But it is at least one indicator, correct?

> Thanks
> Guo Min

In the interest of full disclosure, Min is one of the SDE authors, and I
am one of the udev authors.

Min, maybe you can answer why Intel has spent effort on this project
instead of offering to help udev, which has been public for a long time
now?

thanks,

greg k-h