RE: ANNOUNCE: User-space System Device Enumation (uSDE)

RE: ANNOUNCE: User-space System Device Enumation (uSDE)

[Guo, Min]

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.

>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

> -----Original Message-----
> From: linux-hotplug-devel-admin@lists.sourceforge.net 
> [mailto:linux-hotplug-devel-admin@lists.sourceforge.net]On 
> Behalf Of Greg KH
> Sent: Wednesday, October 29, 2003 6:44 AM
> To: Steven Dake
> Cc: Lars Marowsky-Bree; Mark Bellon; 
> linux-raid@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-hotplug-devel@lists.sourceforge.net
> Subject: Re: ANNOUNCE: User-space System Device Enumation (uSDE)
> 
> 
> On Tue, Oct 28, 2003 at 11:12:07AM -0700, Steven Dake wrote:
> > On Tue, 2003-10-28 at 04:00, Lars Marowsky-Bree wrote:
> > > On 2003-10-27T14:14:18,
> > >    Mark Bellon <mbellon@mvista.com> said:
> > > 
> > > > 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. 
> > > 
> > > 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.
> 
> 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.
> 
> > 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.
> 
> 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
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
> 

RE: ANNOUNCE: User-space System Device Enumation (uSDE)

[Steven Dake]

On Tue, 2003-10-28 at 22:12, 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?
> 

No kernel changes necessary for either usde or udev; I believe any bug
fixes have been merged into 2.6.0-test6 or later.

> 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.
> 
> >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
> 
> > -----Original Message-----
> > From: linux-hotplug-devel-admin@lists.sourceforge.net 
> > [mailto:linux-hotplug-devel-admin@lists.sourceforge.net]On 
> > Behalf Of Greg KH
> > Sent: Wednesday, October 29, 2003 6:44 AM
> > To: Steven Dake
> > Cc: Lars Marowsky-Bree; Mark Bellon; 
> > linux-raid@vger.kernel.org; linux-kernel@vger.kernel.org; 
> > linux-hotplug-devel@lists.sourceforge.net
> > Subject: Re: ANNOUNCE: User-space System Device Enumation (uSDE)
> > 
> > 
> > On Tue, Oct 28, 2003 at 11:12:07AM -0700, Steven Dake wrote:
> > > On Tue, 2003-10-28 at 04:00, Lars Marowsky-Bree wrote:
> > > > On 2003-10-27T14:14:18,
> > > >    Mark Bellon <mbellon@mvista.com> said:
> > > > 
> > > > > 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. 
> > > > 
> > > > 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.
> > 
> > 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.
> > 
> > > 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.
> > 
> > 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
> > Linux-hotplug-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
> > 
> 
> 

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

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

[Rusty Lynch]

On Wed, Oct 29, 2003 at 11:04:21AM -0800, Greg KH wrote:
<huge snip>
> In the interest of full disclosure, Min is one of the SDE authors, and I
> am one of the udev authors.

man... I saw this thread and thought there is no way in hell I am jumping in
this bloody mess.  oh well...
 
...and I told Min to help out on usde. 

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

I have never believed that any one implementation of (in CGL speak) "persistent
device naming" would be palatable by everyone, and have no problem in donating
some resources toward udev.  

In the past we experimented with udev, and even did a little work on
sysfsutils (which I though udev was using, but looking at udev-005 I still
see the libsysfs directory.)

I see the the TODO list in udev-005.  Are all these items wide open, or have
people already spoken for some parts?  Maybe you have a couple of items you 
consider higher priority?

    --rustyl

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

[Greg KH]

On Wed, Oct 29, 2003 at 04:37:20PM -0800, Rusty Lynch wrote:
> 
> In the past we experimented with udev, and even did a little work on
> sysfsutils (which I though udev was using, but looking at udev-005 I still
> see the libsysfs directory.)

Yes, udev uses libsysfs, and your (Intel's) help on libsysfs is greatly
appreciated.

> I see the the TODO list in udev-005.  Are all these items wide open, or have
> people already spoken for some parts?  Maybe you have a couple of items you 
> consider higher priority?

Hm, some of those things on the TODO list are already done (latest
libsysfs, man page, and a few others.)  But no, they are all pretty much
wide open, feel free to jump in with whatever you feel like helping out
with.

thanks,

greg k-h

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

[Eric.Chacron]

>From a pure technical point of view  and from presentations made by the
authors of u*** perspective
i think uSDE could add some interresting features like a customizable
naming policy.
For instance: geographical addressing to identify devices using rack,
subrack, slot numbers
seems possible.

I have not a good knowledge of the history of all these projects : udev,
sysfs, /sbin/hotplug , devfs ...
But what could be needed is some references from one project to others it
depends on or inherits.
I have read such a reference in Greg udev whitepaper and it is very
helpfull to understand added values.


Eric







"Guo, Min" <min.guo@intel.com>@lists.osdl.org on 10/29/2003 06:12:26 AM

Sent by:    cgl_discussion-bounces@lists.osdl.org


To:    "Greg KH" <greg@kroah.com>, "Steven Dake" <sdake@mvista.com>
cc:    linux-raid@vger.kernel.org,
       linux-hotplug-devel@lists.sourceforge.net, Lars Marowsky-Bree
       <lmb@suse.de>, "Ling,  Xiaofeng" <xiaofeng.ling@intel.com>, Mark
       Bellon <mbellon@mvista.com>, linux-kernel@vger.kernel.org,
       cgl_discussion@osdl.org
Subject:    [cgl_discussion] RE: ANNOUNCE: User-space System Device
       Enumation  (uSDE)


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.

>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

> -----Original Message-----
> From: linux-hotplug-devel-admin@lists.sourceforge.net
> [mailto:linux-hotplug-devel-admin@lists.sourceforge.net]On
> Behalf Of Greg KH
> Sent: Wednesday, October 29, 2003 6:44 AM
> To: Steven Dake
> Cc: Lars Marowsky-Bree; Mark Bellon;
> linux-raid@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-hotplug-devel@lists.sourceforge.net
> Subject: Re: ANNOUNCE: User-space System Device Enumation (uSDE)
>
>
> On Tue, Oct 28, 2003 at 11:12:07AM -0700, Steven Dake wrote:
> > On Tue, 2003-10-28 at 04:00, Lars Marowsky-Bree wrote:
> > > On 2003-10-27T14:14:18,
> > >    Mark Bellon <mbellon@mvista.com> said:
> > >
> > > > 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.
> > >
> > > 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.
>
> 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.
>
> > 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.
>
> 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
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>

_______________________________________________
cgl_discussion mailing list
cgl_discussion@lists.osdl.org
 http://lists.osdl.org/mailman/listinfo/cgl_discussion

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

[Greg KH]

On Wed, Oct 29, 2003 at 05:20:01PM +0100, Eric.Chacron@alcatel.fr wrote:
> 
> 
> >From a pure technical point of view  and from presentations made by the
> authors of u*** perspective
> i think uSDE could add some interresting features like a customizable
> naming policy.

udev doesn't provide such a feature right now?

> For instance: geographical addressing to identify devices using rack,
> subrack, slot numbers seems possible.

Sure, udev can do that today, if you have a way of identifying devices
in such a manner.

thanks,

greg k-h

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

[jw schultz]

On Wed, Oct 29, 2003 at 11:07:16AM -0800, Greg KH wrote:
> On Wed, Oct 29, 2003 at 05:20:01PM +0100, Eric.Chacron@alcatel.fr wrote:
> > 
> > 
> > >From a pure technical point of view  and from presentations made by the
> > authors of u*** perspective
> > i think uSDE could add some interresting features like a customizable
> > naming policy.
> 
> udev doesn't provide such a feature right now?
> 
> > For instance: geographical addressing to identify devices using rack,
> > subrack, slot numbers seems possible.
> 
> Sure, udev can do that today, if you have a way of identifying devices
> in such a manner.

.From a distance this udev vs uSDE remind me of dm vs evms.
Based on the rhetoric udev is oriented toward implementing
policy and uSDE, articulating policy.  It seems to me that
the code that should be run on device add and remove ought
to be implementation oriented not policy oriented.  When
policy articulation is wanted it belongs in the user
interface.  This could be a set of files to build the final
config file or a library and user interface.   A bit like
using EVMS to manage dm.

Just my $0.02 in case distance lends perspective.

I also wonder how one is supposed to pronounce uSDE,
you-zdee, us-dee, us-day?

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt