devfs vs. udev

devfs vs. udev

[Måns Rullgård]

I noticed this in the help text for devfs in 2.6.0-test6:

	  Note that devfs has been obsoleted by udev,
	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
	  It has been stripped down to a bare minimum and is only provided for
	  legacy installations that use its naming scheme which is
	  unfortunately different from the names normal Linux installations
	  use.

Now, this puzzles me, for a few of reasons.  Firstly, not long ago,
devfs was spoken of as the way to go, and all drivers were rewritten
to support it.  Why this sudden change?  Secondly, that link only
leads me to a package describing itself as an experimental
proof-of-concept thing, not to be used for anything serious.  How can
something that incomplete obsolete a working system like devfs?
Thirdly, udev appears to respond to hotplug events only.  How is it
supposed to handle device files not corresponding to any physical
device?  Finally, I quite liked the idea of a virtual filesystem for
/dev.  It reduced the clutter quite a bit.  As for the naming scheme,
it could easily be changed.


-- 
Måns Rullgård
mru@users.sf.net

Re: devfs vs. udev

[Andreas Jellinghaus]

On Tue, 07 Oct 2003 12:39:27 +0000, Måns Rullgård wrote:
> I noticed this in the help text for devfs in 2.6.0-test6:
> 
> 	  Note that devfs has been obsoleted by udev,

devfs works fine, lists all devices, and obsoletes makedev.

udev needs patching for several issues, current sysfs only exports
many but by far not all devices, and because of that makedev
is still needed to create an initial /dev.

in short: devfs works fine. udev has quite a way to go.
so marking devfs obsolete was done too soon by far. but
greg wronte me he will spend some time on udev this week
if possible, so lets wait and see.

oops, that reminds me I should have send him a patch to
fix one issue. better late then never...

maybe someone wants to remove the text about devfs being obsolete
till udev is actually ready for use?

Regards, Andreas

Re: devfs vs. udev

[Måns Rullgård]

Andreas Jellinghaus <aj@dungeon.inka.de> writes:

>> I noticed this in the help text for devfs in 2.6.0-test6:
>> 
>> 	  Note that devfs has been obsoleted by udev,
>
> devfs works fine, lists all devices, and obsoletes makedev.

That's my experience.

> udev needs patching for several issues, current sysfs only exports
> many but by far not all devices, and because of that makedev
> is still needed to create an initial /dev.
>
> in short: devfs works fine. udev has quite a way to go.
> so marking devfs obsolete was done too soon by far. but

Exactly my point.

I'd also like an explanation of the rationale behind the switch.
devfs works and is stable.  Why replace it with an incomplete fragile
userspace solution?  I recall reading something about the original
author not updating devfs recently, but I can't see why that requires
rewriting it from scratch.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs vs. udev

[Robert L. Harris]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

Thus spake M?ns Rullg?rd (mru@users.sourceforge.net):

> Andreas Jellinghaus <aj@dungeon.inka.de> writes:
> 
> >> I noticed this in the help text for devfs in 2.6.0-test6:
> >> 
> >> 	  Note that devfs has been obsoleted by udev,
> >
> > devfs works fine, lists all devices, and obsoletes makedev.
> 
> That's my experience.

Same here but read on.

> > udev needs patching for several issues, current sysfs only exports
> > many but by far not all devices, and because of that makedev
> > is still needed to create an initial /dev.
> >
> > in short: devfs works fine. udev has quite a way to go.
> > so marking devfs obsolete was done too soon by far. but
> 
> Exactly my point.
> 
> I'd also like an explanation of the rationale behind the switch.
> devfs works and is stable.  Why replace it with an incomplete fragile
> userspace solution?  I recall reading something about the original
> author not updating devfs recently, but I can't see why that requires
> rewriting it from scratch.

As a pro-devfs person I felt the same and hate to say it but "read the
archives".  Someone gave a good writeup on the problems with devfs and
how udev will (eventually) solve them.

I just hope udev can give a look/feel similar to devfs as I have quite a
few machines already in production configured for devfs and really like
the manageablility.

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Life is not a destination, it's a journey.
  Microsoft produces 15 car pileups on the highway.
    Don't stop traffic to stand and gawk at the tragedy.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: devfs vs. udev

[Måns Rullgård]

"Robert L. Harris" <Robert.L.Harris@rdlg.net> writes:

> As a pro-devfs person I felt the same and hate to say it but "read the
> archives".  Someone gave a good writeup on the problems with devfs and
> how udev will (eventually) solve them.

Does anyone have a more exact pointer?

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs vs. udev

[Andreas Jellinghaus]

On Tue, 07 Oct 2003 14:26:07 +0000, Robert L. Harris wrote:
> I just hope udev can give a look/feel similar to devfs as I have quite a
> few machines already in production configured for devfs and really like
> the manageablility.

I wonder: do you use the /dev/disc/* links, or the /dev/ide/... and
/dev/scsi/... constructs? I'm not sure how udev will be able to 
support both layouts.

Also: do you prefer a devs compatible layout, or maybe use the change
for a cleanup? a short list of obscurities: /dev/cdroms/cdrom0 but
/dev/printers/0 and /dev/tts/0 and /dev/floppy but /dev/discs etc. also
all floppy devices are in /dev/floopy, where each disc has is
/dev/discs/discN directory/symlink. I think it's a good opportunity
for a cleanup, but that wouldn't be compatible...

Regards, Andreas

Re: devfs vs. udev

[Måns Rullgård]

Andreas Jellinghaus <aj@dungeon.inka.de> writes:

>> I just hope udev can give a look/feel similar to devfs as I have quite a
>> few machines already in production configured for devfs and really like
>> the manageablility.
>
> I wonder: do you use the /dev/disc/* links, or the /dev/ide/... and
> /dev/scsi/... constructs? I'm not sure how udev will be able to 
> support both layouts.
>
> Also: do you prefer a devs compatible layout, or maybe use the change
> for a cleanup? a short list of obscurities: /dev/cdroms/cdrom0 but
> /dev/printers/0 and /dev/tts/0 and /dev/floppy but /dev/discs etc. also
> all floppy devices are in /dev/floopy, where each disc has is
> /dev/discs/discN directory/symlink. I think it's a good opportunity
> for a cleanup, but that wouldn't be compatible...

I'm all for a cleanup.  Changing things don't bother me, I just want a
good reason.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs vs. udev

[Robert L. Harris]

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]



I use /dev/ide and /dev/scsi currently.  I also like how I can use
"/dev/cdrom" which is a link to my IDE CDROM on one machine and my SCSI
CDROM on my file server.  Tack that in with /dev/md0 which appears of
it's own accord when I forget to make the dev but do make the raid
device.




Thus spake Andreas Jellinghaus (aj@dungeon.inka.de):

> On Tue, 07 Oct 2003 14:26:07 +0000, Robert L. Harris wrote:
> > I just hope udev can give a look/feel similar to devfs as I have quite a
> > few machines already in production configured for devfs and really like
> > the manageablility.
> 
> I wonder: do you use the /dev/disc/* links, or the /dev/ide/... and
> /dev/scsi/... constructs? I'm not sure how udev will be able to 
> support both layouts.
> 
> Also: do you prefer a devs compatible layout, or maybe use the change
> for a cleanup? a short list of obscurities: /dev/cdroms/cdrom0 but
> /dev/printers/0 and /dev/tts/0 and /dev/floppy but /dev/discs etc. also
> all floppy devices are in /dev/floopy, where each disc has is
> /dev/discs/discN directory/symlink. I think it's a good opportunity
> for a cleanup, but that wouldn't be compatible...
> 
> Regards, Andreas
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Life is not a destination, it's a journey.
  Microsoft produces 15 car pileups on the highway.
    Don't stop traffic to stand and gawk at the tragedy.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: devfs vs. udev

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On Tue, Oct 07, 2003 at 06:06:53PM +0200, Andreas Jellinghaus wrote:
> On Tue, 07 Oct 2003 14:26:07 +0000, Robert L. Harris wrote:
> > I just hope udev can give a look/feel similar to devfs as I have quite a
> > few machines already in production configured for devfs and really like
> > the manageablility.

   Seconded.

> I wonder: do you use the /dev/disc/* links, or the /dev/ide/... and
> /dev/scsi/... constructs? 

   I use /dev/scsi/ and /dev/ide/, because things tend to move around
less than with /dev/discs/. 

> I'm not sure how udev will be able to support both layouts.

   Surely udev needs the ability to make more than one device node or
symlink when a device is plugged in anyway, so I just see this as an
issue of writing the appropriate default configuration files.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
                 --- This year,  I'm giving up Lent. ---                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: devfs vs. udev

[Måns Rullgård]

Hugo Mills <hugo-lkml@carfax.org.uk> writes:

>    Surely udev needs the ability to make more than one device node or
> symlink when a device is plugged in anyway, so I just see this as an
> issue of writing the appropriate default configuration files.

Now you say "plug in".  How does udev deal with devices that don't
correspond something that can be plugged, physically or virtually
(PCI)?  I'm thinking of things like ttys, loopback devices, etc.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 07:19:04PM +0200, Måns Rullgård wrote:
> Hugo Mills <hugo-lkml@carfax.org.uk> writes:
> 
> >    Surely udev needs the ability to make more than one device node or
> > symlink when a device is plugged in anyway, so I just see this as an
> > issue of writing the appropriate default configuration files.
> 
> Now you say "plug in".  How does udev deal with devices that don't
> correspond something that can be plugged, physically or virtually
> (PCI)?  I'm thinking of things like ttys, loopback devices, etc.

Look at sysfs.  If it's in sysfs (like ttys and block devices) udev will
handle it.

thanks,

greg k-h

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 05:54:04PM +0100, Hugo Mills wrote:
> 
>    Surely udev needs the ability to make more than one device node or
> symlink when a device is plugged in anyway, so I just see this as an
> issue of writing the appropriate default configuration files.

More than one device node per device?  Why would you want that?

And sure, it's just software, it can be made to do that, if someone
sends me a patch... :)

thanks, 

greg k-h

Re: devfs vs. udev

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Tue, Oct 07, 2003 at 10:49:28AM -0700, Greg KH wrote:
> On Tue, Oct 07, 2003 at 05:54:04PM +0100, Hugo Mills wrote:
> > 
> >    Surely udev needs the ability to make more than one device node or
> > symlink when a device is plugged in anyway, so I just see this as an
> > issue of writing the appropriate default configuration files.
> 
> More than one device node per device?  Why would you want that?

   OK, more than one actual node per device (i.e. per major:minor
pair) may not necessarily be required, but in devfs there are, for
example device nodes created in /dev/scsi/host0/bus0/device0/lun0/...
etc, and links to those device nodes created in /dev/discs/disc0/...
It can occasionally be useful to have the two distinct namespaces
available.

> And sure, it's just software, it can be made to do that, if someone
> sends me a patch... :)

   If it doesn't do it when I want it to do that, I'll send you the
patch. :)

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
                 --- This year,  I'm giving up Lent. ---                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 06:58:17PM +0100, Hugo Mills wrote:
> On Tue, Oct 07, 2003 at 10:49:28AM -0700, Greg KH wrote:
> > On Tue, Oct 07, 2003 at 05:54:04PM +0100, Hugo Mills wrote:
> > > 
> > >    Surely udev needs the ability to make more than one device node or
> > > symlink when a device is plugged in anyway, so I just see this as an
> > > issue of writing the appropriate default configuration files.
> > 
> > More than one device node per device?  Why would you want that?
> 
>    OK, more than one actual node per device (i.e. per major:minor
> pair) may not necessarily be required, but in devfs there are, for
> example device nodes created in /dev/scsi/host0/bus0/device0/lun0/...
> etc, and links to those device nodes created in /dev/discs/disc0/...
> It can occasionally be useful to have the two distinct namespaces
> available.

Yes, symlinks are on the TODO list, as lots of people want them
/dev/cdrom, /dev/pilot, etc.

thanks,

greg k-h

Re: devfs vs. udev

[Ian Kent]

On Wed, 2003-10-08 at 01:49, Greg KH wrote:
> On Tue, Oct 07, 2003 at 05:54:04PM +0100, Hugo Mills wrote:
> > 
> >    Surely udev needs the ability to make more than one device node or
> > symlink when a device is plugged in anyway, so I just see this as an
> > issue of writing the appropriate default configuration files.
> 
> More than one device node per device?  Why would you want that?
> 
> And sure, it's just software, it can be made to do that, if someone
> sends me a patch... :)
> 

Will udev remove the limit on the number of anonymous devices?

Re: devfs vs. udev

[Greg KH]

On Thu, Oct 09, 2003 at 09:43:10PM +0800, Ian Kent wrote:
> On Wed, 2003-10-08 at 01:49, Greg KH wrote:
> > On Tue, Oct 07, 2003 at 05:54:04PM +0100, Hugo Mills wrote:
> > > 
> > >    Surely udev needs the ability to make more than one device node or
> > > symlink when a device is plugged in anyway, so I just see this as an
> > > issue of writing the appropriate default configuration files.
> > 
> > More than one device node per device?  Why would you want that?
> > 
> > And sure, it's just software, it can be made to do that, if someone
> > sends me a patch... :)
> > 
> 
> Will udev remove the limit on the number of anonymous devices?

udev is a userspace program, it doesn't extend the capability of the
kernel in any manner.  If the kernel has such a limit, there's nothing
that udev can do about it.

thanks,

greg k-h

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 04:07:25PM +0200, Måns Rullgård wrote:
> 
> I'd also like an explanation of the rationale behind the switch.
> devfs works and is stable.  Why replace it with an incomplete fragile
> userspace solution?  I recall reading something about the original
> author not updating devfs recently, but I can't see why that requires
> rewriting it from scratch.

There's no "rewriting from scratch" happening here.  Although
Christoph's devfs changes in the 2.6 kernel tree were a major
improvement on the quality of the devfs interface (within the kernel
code), there are still unfixable devfs bugs in the code.

thanks,

greg k-h

Re: devfs vs. udev

[Ian Kent]

On Tue, 7 Oct 2003, Måns Rullgård wrote:

> Andreas Jellinghaus <aj@dungeon.inka.de> writes:
> 
> >> I noticed this in the help text for devfs in 2.6.0-test6:
> >> 
> >> 	  Note that devfs has been obsoleted by udev,
> >
> > devfs works fine, lists all devices, and obsoletes makedev.
> 
> That's my experience.
> 
> > udev needs patching for several issues, current sysfs only exports
> > many but by far not all devices, and because of that makedev
> > is still needed to create an initial /dev.
> >
> > in short: devfs works fine. udev has quite a way to go.
> > so marking devfs obsolete was done too soon by far. but
> 
> Exactly my point.
> 
> I'd also like an explanation of the rationale behind the switch.
> devfs works and is stable.  Why replace it with an incomplete fragile
> userspace solution?  I recall reading something about the original
> author not updating devfs recently, but I can't see why that requires
> rewriting it from scratch.

Sorry to interrupt.

I have had a look at the code and looked around a bit and I'm left with 
two questions.

1) What are the problems with devfs. I can't seem to find anything 
specific?

2) I believe udev does not support for an increased number of anonymous 
devices for such things as NFS and autofs mounts. I can't see anything in 
the kernel (2.6) to improve this either. Can devfs provide improvements 
for this without to much pain?


-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 14, 2003 at 09:51:43PM +0800, Ian Kent wrote:
> 
> 2) I believe udev does not support for an increased number of anonymous 
> devices for such things as NFS and autofs mounts. I can't see anything in 
> the kernel (2.6) to improve this either. Can devfs provide improvements 
> for this without to much pain?

udev has no control over this.  If the kernel supports an increased
number, udev will support it.  The number of raw devices has recently
been increased, due to the new major/minor increase.  Such a patch for
anonymous devices could probably be easily created.

Hope this helps,

greg k-h

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 03:41:24PM +0200, Andreas Jellinghaus wrote:
> 
> maybe someone wants to remove the text about devfs being obsolete
> till udev is actually ready for use?

Why?  devfs is still obsolete no matter if udev is "production ready" or
not :)

thanks,

greg k-h

Re: devfs vs. udev

[tabris]

On Tuesday 07 October 2003 08:38 am, Måns Rullgård wrote:
> I noticed this in the help text for devfs in 2.6.0-test6:
>
> 	  Note that devfs has been obsoleted by udev,
> 	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
> 	  It has been stripped down to a bare minimum and is only provided for
> 	  legacy installations that use its naming scheme which is
> 	  unfortunately different from the names normal Linux installations
> 	  use.
>
> Now, this puzzles me, for a few of reasons.  Firstly, not long ago,
> devfs was spoken of as the way to go, and all drivers were rewritten
> to support it.  Why this sudden change?  Secondly, that link only
> leads me to a package describing itself as an experimental
> proof-of-concept thing, not to be used for anything serious.  How can
> something that incomplete obsolete a working system like devfs?
> Thirdly, udev appears to respond to hotplug events only.  How is it
> supposed to handle device files not corresponding to any physical
> device?  Finally, I quite liked the idea of a virtual filesystem for
> /dev.  It reduced the clutter quite a bit.  As for the naming scheme,
> it could easily be changed.
My word is hardly authoritative, but istr hearing that the original 
devfs-maintainer has abandoned this code (probably after multiple 
complaints about it being badly implemented, full of bugs, locking 
issues/races, etc).

Not having used it with 2.6 yet, I don't know much about it's status in 
that tree.

So, although devfs may still work, and even be in a better condition than 
udev (at present); no longer maintained (and little intention of 
changing) may be considered equivalent to obsolete.
--
tabris
-
	Max told his friend that he'd just as soon not go hiking in the hills.
Said he, "I'm an anti-climb Max."
	[So is that punchline.]

Re: devfs vs. udev

[Greg KH]

On Tue, Oct 07, 2003 at 02:38:27PM +0200, Måns Rullgård wrote:
> 
> I noticed this in the help text for devfs in 2.6.0-test6:
> 
> 	  Note that devfs has been obsoleted by udev,
> 	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
> 	  It has been stripped down to a bare minimum and is only provided for
> 	  legacy installations that use its naming scheme which is
> 	  unfortunately different from the names normal Linux installations
> 	  use.
> 
> Now, this puzzles me, for a few of reasons.  Firstly, not long ago,
> devfs was spoken of as the way to go, and all drivers were rewritten
> to support it.  Why this sudden change?

A few things happened:
	- the devfs maintainer/author disappeared and stoped maintaining
	  the code.
	- devfs was found to have unfixable bugs
	- it was determined that the same thing could be done in
	  userspace (like udev.)
	  
> Secondly, that link only leads me to a package describing itself as an
> experimental proof-of-concept thing, not to be used for anything
> serious.  How can something that incomplete obsolete a working system
> like devfs?

I didn't send that patch to the kernel to mark devfs as such.

Actually devfs is still very much "experimental" and "proof-of-concept"
if you have ever looked at it's code :)

> Thirdly, udev appears to respond to hotplug events only.  How is it
> supposed to handle device files not corresponding to any physical
> device?

Like what?  Anything that shows up in sysfs, udev will handle.  It's
only a matter of getting everything to show up in sysfs now...  It's
almost all there.

> Finally, I quite liked the idea of a virtual filesystem for /dev.  It
> reduced the clutter quite a bit.  As for the naming scheme, it could
> easily be changed.

devfs's naming scheme could easily be changed?  Hahaha...

udev will be a major factor of improvement for changable naming schemes.
Please read the OLS paper for more details.

thanks,

greg k-h

Re: devfs vs. udev

[viro]

On Tue, Oct 07, 2003 at 10:53:10AM -0700, Greg KH wrote:
 
> A few things happened:
> 	- the devfs maintainer/author disappeared and stoped maintaining
> 	  the code.
> 	- devfs was found to have unfixable bugs
> 	- it was determined that the same thing could be done in
> 	  userspace (like udev.)

It went more like
	
	- it was determined that the same thing could be done in
	  userspace
	- devfs had been shoved into the tree in hope that its quality will
	  catch up
	- devfs was found to have fixable and unfixable bugs
	- the former had stayed around for many months with maintainer claiming
	  that everything works fine
	- the latter had stayed, period.
	- the devfs maintainer/author disappeared and stoped maintaining
	  the code.

Re: DevFS vs. udev

[Bradley W. Allen]

DevFS was written by an articulate person who solved a lot of
problems.  udev sounds more like a thug who's smug about winning,
not explaining himself, saying things like "oh, the other guy
disappeared, so who cares, you have to use my code, too bad it sucks".

Just by what the udev people have said I have decided never to use it,
and to return to DevFS.  Thank god for linux-kernel archives.

A few points:

*  User space is slow, causing all sorts of extra work for device
   accesses.
*  Another layer of filesystem for udev to have to interact with
   is also slow, especially if it has to be disk based with all sorts
   of extra caches, and also if it's with buggy tmpfs code and layers.
*  Most of the interesting devices I have now are character devices,
   and have multiple potential /dev entries per device.  I've heard
   that udev can't even handle that requirement!
   Udev has lots of other problems, like something called an anonymous
   device, and it not being fully implemented, however, that's OK for
   development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
   solid for over half a decade, so it belongs in stable kernels.
*  Many times a broken record comes out with claims.  Here are a few:
   "... there are still unfixable devfs bugs in the code." without
   any examples, so I don't believe him (Greg K-H).  Others have looked
   and not found that.
*  Userspace is not the proper place for kernel device drivers or
   anything they need to work.
*  We do not need the same old maintainer for devfs.  We can create
   new code, and maintain old code, as a group, ourselves.
*  Greg K-H (what that dash is for I can't imagine) claims that DevFS
   is experimental and proof of concept; well, it has been in production
   use for over half a decade, which in the life of Linux is pretty long.
   It's certainly not just some experiment any more.
*  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
   things that most Linux kernel compilers, linux-kernel readers, and
   DevFS users (including lots of admins) have probably never ever
   heard of except the bad attitude of the hahaha part.
*  Someone named viro said "the latter had stayed, period" refering to
   udev, which means absolutely nothing, but expected it to mean
   something.
*  Viro also said that devfs had been "shoved" into the tree, and
   that it "had stayed around for many months".  It's been stable for
   many *YEARS*, for most of a *DECADE*.

I've spent two hours on this problem, and that's absurd; stable shouldn't
be doing this sort of thing to us.  Yes, we know there are things that
happen during transition from development to stable, but to have some
terrorist hijack part of the kernel and destroy it right at the begin-
ing of stable is simply criminal thinking.  Luckily, this is just
software, so we can do what we want with it, but organizationally it
is conceptually just as bad.

Re: DevFS vs. udev

[Duncan Sands]

On Tuesday 23 December 2003 12:51, Bradley W. Allen wrote:
> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".

I've heard that around here it's the code that does the talking... :)

Ciao,

Duncan.

Re: DevFS vs. udev

[Xavier Bestel]

Le mar 23/12/2003 à 12:51, Bradley W. Allen a écrit :
> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".
[...]
> I've spent two hours on this problem, and that's absurd; 

Man, you've convinced me ! 
You've spent *two* hours on this problem ?  Woah, these K-H and Viro
guys must be dorks if they don't subscribe to your theories. Who are
they to think their opinion matters more than yours, who spent *two*
hours on this problem ?

Are you the new DevFS's maintainer ?

Re: DevFS vs. udev

[Marcelo Bezerra]

On Tue, 2003-12-23 at 09:12, Xavier Bestel wrote:
> Le mar 23/12/2003 à 12:51, Bradley W. Allen a écrit :
> > DevFS was written by an articulate person who solved a lot of
> > problems.  udev sounds more like a thug who's smug about winning,
> > not explaining himself, saying things like "oh, the other guy
> > disappeared, so who cares, you have to use my code, too bad it sucks".
> [...]
> > I've spent two hours on this problem, and that's absurd; 
> 
> Man, you've convinced me ! 
> You've spent *two* hours on this problem ?  Woah, these K-H and Viro
> guys must be dorks if they don't subscribe to your theories. Who are
> they to think their opinion matters more than yours, who spent *two*
> hours on this problem ?
> 
> Are you the new DevFS's maintainer ?
In spite you trying to make him sound foolish, I still think he has some
good points. DevFS works great and it never did something that was
broken for me, so I see no point in replacing it. Maybe Greg K-H and Al
Viro can step in an enlighten us once and for all.

Re: DevFS vs. udev

[Ed Tomlinson]

On December 23, 2003 07:37 am, Marcelo Bezerra wrote:
> On Tue, 2003-12-23 at 09:12, Xavier Bestel wrote:
>
> > Le mar 23/12/2003 à 12:51, Bradley W. Allen a écrit :
> >
> > > DevFS was written by an articulate person who solved a lot of
> > > problems.  udev sounds more like a thug who's smug about winning,
> > > not explaining himself, saying things like "oh, the other guy
> > > disappeared, so who cares, you have to use my code, too bad it sucks".
> >
> > [...]
> >
> > > I've spent two hours on this problem, and that's absurd; 
> >
> > 
> > Man, you've convinced me ! 
> > You've spent *two* hours on this problem ?  Woah, these K-H and Viro
> > guys must be dorks if they don't subscribe to your theories. Who are
> > they to think their opinion matters more than yours, who spent *two*
> > hours on this problem ?
> > 
> > Are you the new DevFS's maintainer ?
>
> In spite you trying to make him sound foolish, I still think he has some
> good points. DevFS works great and it never did something that was
> broken for me, so I see no point in replacing it. Maybe Greg K-H and Al
> Viro can step in an enlighten us once and for all.

They have.  There are technical reasons.  From a technical point of view devfs
is _broken_ and cannot be fixed without major efforts.  It has be discovered 
that things can be done in user space (udev 10 had to be slowed down - it
was too fast and the kernel was not keeping up...).  So devfs was made
obsolete.

Not listening or like the reasons does not change them.

Ed Tomlinson

Re: DevFS vs. udev

[Kai Henningsen]

mosca@mosca.yi.org (Marcelo Bezerra)  wrote on 23.12.03 in <1072183068.1204.2.camel@ham>:

> On Tue, 2003-12-23 at 09:12, Xavier Bestel wrote:
> > Le mar 23/12/2003 à 12:51, Bradley W. Allen a écrit :
> > > DevFS was written by an articulate person who solved a lot of
> > > problems.  udev sounds more like a thug who's smug about winning,
> > > not explaining himself, saying things like "oh, the other guy
> > > disappeared, so who cares, you have to use my code, too bad it sucks".
> > [...]
> > > I've spent two hours on this problem, and that's absurd;
> >
> > Man, you've convinced me !
> > You've spent *two* hours on this problem ?  Woah, these K-H and Viro
> > guys must be dorks if they don't subscribe to your theories. Who are
> > they to think their opinion matters more than yours, who spent *two*
> > hours on this problem ?
> >
> > Are you the new DevFS's maintainer ?
> In spite you trying to make him sound foolish,

No need whatsoever, he managed that fine all by himself. It's rare to see  
such a concentrated amount of stupidity-by-being-too-lazy-to-do-trivial- 
research on a technical mailing list.

Of course, whoever thinks Bradley made some profound point must be asked  
the same question - what made it impossible for you to do a trivial amount  
of research so you would not utter so incredibly embarassing stupidity?

MfG Kai

Re: DevFS vs. udev

[Paul Dickson]

On Tue, 23 Dec 2003 03:51:58 -0800, Bradley W. Allen wrote:

> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".
> 
> Just by what the udev people have said I have decided never to use it,
> and to return to DevFS.  Thank god for linux-kernel archives.

Nice piece of FUD you've written without really understanding what devfs
and udev do.  This devfs vs udev issue has become emotional, and it's
starting to slip into name calling.

Devfs had reached its design limits and the maintainer gave up on it,
mostly because the support was too painful for other kernel developers.
It's still in 2.6, just don't expect fixes for areas that don't (and
can't) work.

I use devfs for my router I threw together, but I fully expect to switch
to udev once all the missing /dev support is added in 2.6.1 or 2.6.2.

Devfs is deprecated.  This means it's still available but you should
consider moving to other options when available.  Obsolete means it
shouldn't be used.  Some 2.6 docs have confused these two terms WRT devfs.


> A few points:
> 
> *  User space is slow, causing all sorts of extra work for device
>    accesses.
> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

udev is not used for device access.  The /dev devices are no slower than a
static /dev directory or a devfs /dev directory.


> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!
>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
>    solid for over half a decade, so it belongs in stable kernels.

Udev is not a finished or fully functional project in 2.6.0, but neither
is devfs (and, as you mentioned, devfs has had five years).


> *  Many times a broken record comes out with claims.  Here are a few:
>    "... there are still unfixable devfs bugs in the code." without
>    any examples, so I don't believe him (Greg K-H).  Others have looked
>    and not found that.

A large chunk of devfs code was removed during 2.5 development if I recall
correctly.  I believe is was mostly unused so I haven't missed it.

Perhaps you should depend on the hearsay of others.  Either listen to the
kernel developers or figure out the locking code within the kernel
yourself.


> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

Device drivers do not need /dev to function, only userspace needs these. 
Configuring userspace should be done in userspace, IMHO.


> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

As I mentioned, devfs had reach limits in it's design and to push past
this would require added complexity to other areas of the kernel. 
Complexity that would make maintainability harder.

Designs that don't work are eventually replaced with those that do.


> *  Greg K-H (what that dash is for I can't imagine) claims that DevFS
>    is experimental and proof of concept; well, it has been in production
>    use for over half a decade, which in the life of Linux is pretty long.
>    It's certainly not just some experiment any more.

Careful, you're starting to drop into name calling.

Devfs has problems.  It's being replace during the life of the 2.6 kernel
with something that hopefully won't have as many problems.  This is the
norm for software development.


> *  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
>    things that most Linux kernel compilers, linux-kernel readers, and
>    DevFS users (including lots of admins) have probably never ever
>    heard of except the bad attitude of the hahaha part.

So udev documentation is a bit scarce.  So don't use it.  Continue to use
devfs or a static /dev until you find documentation good enough for you to
understand or you find some else's example to copy.


> *  Someone named viro said "the latter had stayed, period" refering to
>    udev, which means absolutely nothing, but expected it to mean
>    something.

Reading http://kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ, I take
the part you quote as meaning: the unfixable bugs in devfs, since the
section was about devfs.


> *  Viro also said that devfs had been "shoved" into the tree, and
>    that it "had stayed around for many months".  It's been stable for
>    many *YEARS*, for most of a *DECADE*.
>
> I've spent two hours on this problem, and that's absurd; stable shouldn't
> be doing this sort of thing to us.  Yes, we know there are things that
> happen during transition from development to stable, but to have some
> terrorist hijack part of the kernel and destroy it right at the begin-
> ing of stable is simply criminal thinking.  Luckily, this is just
> software, so we can do what we want with it, but organizationally it
> is conceptually just as bad.

Getting closer and closer to name calling...

If you don't like udev, don't use it.  It's as simple as that for the
moment.  Since 2.6.0 shipped with devfs deprecated, it's conceivable,
although unlikely, that devfs could be removed once a udev-like project is
fully functional.

You did not mention how you're using devfs.  Your comments don't suggest a
lot of experience with it either.

	-Paul Dickson

Re: DevFS vs. udev

[Bradley W. Allen]

Thank you for the cogent reply.  I think all your substantiated
points are valid.  I'll have to see what I can do about the rest,
as you said.

I'm glad others responded to what seems like an inaccurate post of
mine.  At least I, if not others, can persue it as was suggested
by you and Greg KH <greg@kroah.com> for now.

I am not volunteering at this time to work on DevFS.

The main problem is documentation, as you pointed out.  I went to
"make menuconfig" in the new stable kernel, and ran into this problem
head-on:  help for that option says that it is either depracated
or obsolete, and after using it without big problems for a long
time, I wanted to know why.  Everything I saw after that smelled
bad, and I'm saying so, but that may not mean that it is.  It was
so bad I didn't even read the "paper" about why on one of the
referenced web sites.  Also, my old 3 year archive via USENET
of linux-kernel no longer exists within my grasp (not any fault of
mine), so I'm forced to use web archive access, and it's hard to
navigate in those.

To respond to Greg KH, my uses are not for a highly production
oriented mission critical corporate system or anything, but they
are timing critical.  If it takes more CPU, RAM, and time to open
/dev/null and all the other hundreds of devices in /dev that get
opened every time some programs start, that is not only bloat, but
more trouble.  Moving kernel functions into user space has always
been a pet peeve of mine:  why do it, when it just means shuffling
back and forth between system calls and user processes ... if that's
what is actually happening ... unless that's not what's happening
...  I'll have to research this myself at some other time.

okay.  So I don't know what I'm talking about within /dev internals
in the kernel.  It's just not well documented.  I can read the
documents, then know what I'm talking about there, but all I'm
trying to do is install 2.6.  Ok, so I could have taken the word
of the help system.  Meanwhile, I've had to spend at least half
a day re-configuring a non-DevFS /dev for the first time in half
a decade in preparation for this big depracation, and I am upset
about it.

Sure, I could continue to use DevFS, but if as you said, it's not
going to be around long, then I could be in trouble for depending
on it.

I'm going to use disk /dev for now, until I have time to understand
this better, which will probably be around halfway through next year.

Already, I'm living the old pain I thought was left way behind of
archiving and moving around /dev subdirectories, and having to
consider the differences between systems, kernels, distributions,
and versions of backup, something I thought I didn't have to worry
about.  If udev gets OK or DevFS doesn't break, I may go back to
that someday.

For now, if whatever I do doesn't slow the system down more
than about .1 seconds per access of *all* the /dev/ devices
necessary for a complete program transition (in a swapping
Pentium III), then I should be OK.  Perhaps that was
unconsciously nagging me:  userspace =? swap; swap every time
/dev gets accessed?  If indeed this is just an undocumented
transition, then my confidence is higher that you've made
sure this isn't a problem, and I just didn't read about it.
In one of my uses, /dev doesn't get accessed very often,
perhaps once every half hour (giving it plenty of chance to swap
if it has that ability, which I don't want it to), but when it
does, it expects sub-second turnaround on the entire lot.
If udev doesn't actually get used during device opens and closes,
then that will fix that problem.  Too many unanswered questions.

Sorry for the "emotional" fuss.  (Perhaps my personal environment
needs less of that pressure, too :? )

Re: DevFS vs. udev

[Brett]

On Tue, 23 Dec 2003, Bradley W. Allen wrote:

<snip>
> 
> Sure, I could continue to use DevFS, but if as you said, it's not
> going to be around long, then I could be in trouble for depending
> on it.
> 
<snip>

It's marked as deprecated.  This means it will (probably) be removed for 
the next stable kernel (2.8) ... This will be at least 2 years away, 
probably.

Saying devfs is not going to be around for long is hardly accurate.

	/ Brett

Re: DevFS vs. udev

[alex.g.goddard.1]

On Tue, 23 Dec 2003, Bradley W. Allen wrote:

> The main problem is documentation, as you pointed out.  I went to
> "make menuconfig" in the new stable kernel, and ran into this problem
> head-on:  help for that option says that it is either depracated
> or obsolete, and after using it without big problems for a long
> time, I wanted to know why.  Everything I saw after that smelled
> bad, and I'm saying so, but that may not mean that it is.  It was
> so bad I didn't even read the "paper" about why on one of the
> referenced web sites.  Also, my old 3 year archive via USENET
> of linux-kernel no longer exists within my grasp (not any fault of
> mine), so I'm forced to use web archive access, and it's hard to
> navigate in those.

http://marc.theaimsgroup.com/?l=linux-kernel&m=105851630726585&w=2

>From the first page of results for 'devfs deadlock'.  That you didn't read
the udev paper (what?  Can't Google for 'udev OLS 2003'?  Or snag the URL
from the udev FAQ?) is just laziness.  It "smelled bad"?  I don't see much
evidence of you attempting to see if your instinct regarding udev's odor
was correct or not.

Not that saying this will help much, but can we please avoid any more
baseless, unresearched "udev is teh suck!" threads for a while?  I'm sure
Greg would welcome well thought out, researched criticism, but there's
been quite a rash of the unresearched, thoughtless kind of late.

> Moving kernel functions into user space has always been a pet peeve of
> mine:  why do it, when it just means shuffling back and forth between
> system calls and user processes ... if that's what is actually happening
> ... unless that's not what's happening ...  I'll have to research this
> myself at some other time.

You can respond to this off-list (in fact, I'd rather you do so), but out
of curiosity where do you draw the line between things that should be in
the kernel and things that shouldn't be?  Should we shove the GUI down
into the kernel?

[snip]

> Sure, I could continue to use DevFS, but if as you said, it's not
> going to be around long, then I could be in trouble for depending
> on it.

As someone else pointed out, deprecation doesn't mean it's going away in
the next few months, or even any time this year or during 2004.  In fact,
you can still use devfs.  Read up on the problems with it, and be prepared
for what that might mean for your system.

Please, please, please in the future see if your instincts are
well-founded before launching another thread like this (whether it's about
udev or anything else).  Not that my saying this here and now is going to
help much when the next person who can't be bothered to find out whether
his criticism is well-founded comes along...

-- 
Alex Goddard
agoddard at purdue dot edu
Another one of the sane Gentoo users

Re: DevFS vs. udev

[Ian Kent]

On Tue, 23 Dec 2003, Bradley W. Allen wrote:

> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".
> 

Well, this issue has certainly attracted a lot of debate.

I have barely used devfs, but I like much of the implementation. I'm not 
familiar with udev either and so won't comment on it.

When this thread first started I had a look at the code and, I must admit, 
it is a little untidy (ugly actually). I think it would require a 
considerable amount of effort just to make it maintainable. Maybe then 
some of the problems (whatever they are) would present themselves.

So it's deprecated in 2.6. Is this only because no one is willing to take 
on maintenance of it or is it to late?

Ian

Re: DevFS vs. udev

[Mark Mielke]

On Wed, Dec 24, 2003 at 12:19:00AM +0800, Ian Kent wrote:
> When this thread first started I had a look at the code and, I must admit, 
> it is a little untidy (ugly actually). I think it would require a 
> considerable amount of effort just to make it maintainable. Maybe then 
> some of the problems (whatever they are) would present themselves.
> So it's deprecated in 2.6. Is this only because no one is willing to take 
> on maintenance of it or is it to late?

In true open source style, it is never too late.

All you need to do is convince enough influential people to include *your*
fixes into the tree. At this point in time, it looks like you would need
to improve the devfs code quite a bit to change their minds. udev, once
implemented, will be elegant (interface-wise) competition.

The arguments against udev that I have seen to date are:

    1) Device metadata does not belong in user space. To this, I say 'why'?
       For *decades*, /dev has existed as a file system without *any* kernel
       support. udev follows in these steps. devfs is the drastically
       different model that has been difficult to make work right in all
       circumstances. /dev has a file system only had problems of capacity.

    2) udev is slow. To this, I say 'prove it'. Why should it be slow?
       As a tmpfs file system, I *assume* that the vfs name lookup routines
       are implemented quite efficiently. What would make udev be slow?
       How often are devices added and removed from the kernel? Does anybody
       have a real life scenario where a kernel model is added and removed
       hundreds of times a second?

    3) udev takes up more memory. Why should this be the case? It is in
       user space, meaning that for a running system, it, and it's
       configuration file don't even need to take up swap space. The only
       space requirements are those dictated by the file system. For tmpfs
       I doubt the space is that much more than devfs (both need kernel
       data structures to be initialized and in existence). For a regular
       file system, it isn't a fair comparison, but the cost should be
       quite minimal. They're device files. They don't have data outside
       their inode structure.

I blame the udev people for this thread. :-) They should have their beast
*finished* already, and their sales skills need to be improved. Volunteer
techies! Hehe...

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: DevFS vs. udev

[Greg KH]

On Tue, Dec 23, 2003 at 12:34:29PM -0500, Mark Mielke wrote:
> 
> I blame the udev people for this thread. :-)

I blame all of the Gentoo users for this thread, and the ability for
them to constantly dig up old threads that have been hashed out many
times in the past without ever checking the archives.

I need more egg-nog...

greg k-h

(yeah, it's probably not _all_ gentoo people, but it sure seems like the
 majority of them sure are wed to devfs for some strange reason...)

Re: DevFS vs. udev

[Tomasz Torcz]

On Tue, Dec 23, 2003 at 02:02:09PM -0800, Greg KH wrote:
> (yeah, it's probably not _all_ gentoo people, but it sure seems like the
>  majority of them sure are wed to devfs for some strange reason...)

Heh, I'm happily using devfs on Slackware ;-)
Also, it's interesting that other OSes have devfs-like
functionality, but somehow done right and not suffering from
linux' devfs illness. FreeBSD5 even mount devfs by default.

-- 
Tomasz Torcz                 Morality must always be based on practicality.
zdzichu@irc.-nie.spam-.pl                -- Baron Vladimir Harkonnen

Re: DevFS vs. udev

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Wed, 2003-12-24 at 00:02, Greg KH wrote:
> On Tue, Dec 23, 2003 at 12:34:29PM -0500, Mark Mielke wrote:
> > 
> > I blame the udev people for this thread. :-)
> 
> I blame all of the Gentoo users for this thread, and the ability for
> them to constantly dig up old threads that have been hashed out many
> times in the past without ever checking the archives.
> 

Did they actually say that use Gentoo ? :/  I might have missed a
few posts, as these do tend to stretch (actually, a quick search of
udev and gentoo in the same message only result in me asking
questions or posting bugs, and then of course your prev post) ...

As for us (Gentoo), I might be finger-slapped later on, but official
standing (and to what I am working) is that we will support udev instead
of devfs by default when 2.6 goes mainline as default distro kernel
(heck, current unstable *will* use udev with 2.6 kernel if installed
instead of devfs, given that /dev is not mounted devfs).

In general it was the easier path to go devfs, and at the stage where
Gentoo arose from another distro, devfs was the 'in thing', so naturally
what we supported (as we do try to cover the more advance/experimenting
users).  NOTE that Gentoo _can_ work 100% without devsfs, and without
hacking things to pieces (just kernel boot param needed).

Alas for me, you should have realized that I was on the udev boat pretty
soon, and if it seems that our users do tend to start these threads,
well, we can only hope that they catch on (if they do need that) ;)

Lastly, a small nit with udev currently - how long will it be for in
kernel changes to be in place so that we do not need the 1sec delay?
It really sucks when you use a script/whatever to populate /dev, and
reboot quite frequent for new kernel/rc-script testing :)


Thanks,

-- 

Martin Schlemmer




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: DevFS vs. udev

[Greg KH]

On Wed, Dec 24, 2003 at 02:45:15AM +0200, Martin Schlemmer wrote:
> Lastly, a small nit with udev currently - how long will it be for in
> kernel changes to be in place so that we do not need the 1sec delay?
> It really sucks when you use a script/whatever to populate /dev, and
> reboot quite frequent for new kernel/rc-script testing :)

It's not a kernel change needed, it's a udev/libsysfs change needed.  If
I didn't have to deal with devfs emails I would get a chance to work on
the issue some more :)

And yes, I have gotten tired of the boot issue too, just add a '&' after
the udev call in your init scripts and then everything seems to work
just fine (as far as speed of boot goes.)

And sorry for the Gentoo comment, it wasn't aimed at the developers at
all.  You have helped out a bunch with udev development, and I
appreciate it.  I also appreciate the chore you are undertaking in
moving away from devfs, that's a great step.

But you do have to admit, Gentoo seems to have some pretty rabid users :)

thanks,

greg k-h

Re: DevFS vs. udev

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Wed, 2003-12-24 at 03:07, Greg KH wrote:
> On Wed, Dec 24, 2003 at 02:45:15AM +0200, Martin Schlemmer wrote:
> > Lastly, a small nit with udev currently - how long will it be for in
> > kernel changes to be in place so that we do not need the 1sec delay?
> > It really sucks when you use a script/whatever to populate /dev, and
> > reboot quite frequent for new kernel/rc-script testing :)
> 
> It's not a kernel change needed, it's a udev/libsysfs change needed.  If
> I didn't have to deal with devfs emails I would get a chance to work on
> the issue some more :)
> 

Ah, cool - please post if you have something a bit before next udev
release (no pressure), as we might get some extra testing done for you.

> And yes, I have gotten tired of the boot issue too, just add a '&' after
> the udev call in your init scripts and then everything seems to work
> just fine (as far as speed of boot goes.)
> 

Right, but things needs to be synced for a lot of users, and I'll
rather patch the 1sec out or wait with 010 then get 200 bug reports :)

> But you do have to admit, Gentoo seems to have some pretty rabid users :)
> 

Same as the other guys (distro's) - they help us keep the rest in
check :)  But I still say its not us that started this *g*


Cheers,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: DevFS vs. udev

[Greg KH]

On Tue, Dec 23, 2003 at 03:51:58AM -0800, Bradley W. Allen wrote:
> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".

Huh?  I sound like a thug?  I might look like one at times, smell like
one lots of times, but I didn't think I typed like one...

> Just by what the udev people have said I have decided never to use it,
> and to return to DevFS.  Thank god for linux-kernel archives.
> 
> A few points:
> 
> *  User space is slow, causing all sorts of extra work for device
>    accesses.

What do you mean by this.  What is too slow for you?  Have you timed
udev vs. devfs?  Yes, udev-010 now takes a whole second to band-aid over
a race condition in the udev code, but that will be fixed up...

And that's only 1 second from inserting a device into the system.  Is
this a problem with some kind of hardware or real-time devices that you
are using?  Do you have to be able to access the device in the least
possible amount of time?  If so, what's your timing constraints you are
working with?

> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

What "extra layer of filesystem" are you talking about?  sysfs?  Hey,
sysfs isn't going away at all.  Reading from a ramfs filesystem is
_fast_, no disk accesses at all.

What do you mean by "buggy tmpfs code and layers"?  sysfs uses libfs and
is a ramfs-like filesystem.  It isn't tmpfs.  And if you've found some
bugs, people are interested in finding them.

> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!

Where did you hear this?  It isn't true.  I have a multi-port usb serial
device with 16 /dev entries for a single device.  Works just fine.

>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.

What kind of device exactly are you talking about?

>    DevFS has been solid for over half a decade, so it belongs in
>    stable kernels.

5 years stability?  Hm, oh well, please check the lkml archives and the
udev FAQ for the reasons why devfs is broken and can not be fixed.

> *  Many times a broken record comes out with claims.  Here are a few:
>    "... there are still unfixable devfs bugs in the code." without
>    any examples, so I don't believe him (Greg K-H).  Others have looked
>    and not found that.

Heh, see the archives for where these claims were made by Al Viro and
backed up with real examples.

> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

What do you mean by this?  Userspace is where the device node lives, on
a filesystem, that's it.

> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

Are you volunteering?

> *  Greg K-H (what that dash is for I can't imagine) claims that DevFS
>    is experimental and proof of concept; well, it has been in production
>    use for over half a decade, which in the life of Linux is pretty long.
>    It's certainly not just some experiment any more.

Where did I claim this?  And the '-' is part of my name, if you want you
can spell the whole thing out every time.

> *  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
>    things that most Linux kernel compilers, linux-kernel readers, and
>    DevFS users (including lots of admins) have probably never ever
>    heard of except the bad attitude of the hahaha part.

Hm, sorry for trying to lend a bit of humor at times.  My 2003 udev
paper is well documented (try googling for it) and is contained in the
udev tarball.  sysfs is also well documented in a linux.conf.au paper by
it's author, Pat Mochel.

> I've spent two hours on this problem, and that's absurd; stable shouldn't
> be doing this sort of thing to us.

What problem is this?  Have you posted with questions on how to set up
udev properly for you?

> Yes, we know there are things that happen during transition from
> development to stable, but to have some terrorist hijack part of the
> kernel and destroy it right at the begin- ing of stable is simply
> criminal thinking.  Luckily, this is just software, so we can do what
> we want with it, but organizationally it is conceptually just as bad.

I welcome you as the new devfs maintainer.  I'm not forcing anyone to
not use devfs, just realize that there are problems with it, and it will
probably go away in the future.

thanks,

greg k-h

/me sighs...

Re: DevFS vs. udev

[Ian Kent]

On Tue, 23 Dec 2003, Greg KH wrote:

>
> Are you volunteering?

Well I was. That was the point of my post which started this again. Sorry.

Seems to me that the best way to remedy this unrest is to have someone
accept maintenance of devfs and when/if it is not used to remove it
from the kernel then.

It certainly seems like a good project for a someone, such as myself, that
is new to kernel development.

However, if Andrew wants it gone from the kernel there is no point.

Ian

Re: DevFS vs. udev

[Rob Love]

On Tue, 2003-12-23 at 20:52, Ian Kent wrote:

> It certainly seems like a good project for a someone, such as myself, that
> is new to kernel development.

Please take no offense to this, but it is an awful project for someone
new to kernel development.  Plenty of knowledgeable/semi-knowledgeable
kernel hackers looked at devfs and given up on it.  Despite what some
people say about Richard, he is a good guy, and he did not succeed
either.

devfs is hard to get right and, worse, you will be starting with a bad
base of code that I would not want to touch with an 18.72 foot pole.

Greg, via udev, has made it so easy to just back up, slowly, and walk
away from devfs.  devfs is not going anywhere in 2.6, I do not think,
but let sleeping piles of crap sleep and let's just jettison this thing
as soon as we can.

Just my two cents - I am warning you ;)

	Rob Love

Re: DevFS vs. udev

[Ian Kent]

On Tue, 23 Dec 2003, Rob Love wrote:

> On Tue, 2003-12-23 at 20:52, Ian Kent wrote:
>
> > It certainly seems like a good project for a someone, such as myself, that
> > is new to kernel development.
>
> Please take no offense to this, but it is an awful project for someone
> new to kernel development.  Plenty of knowledgeable/semi-knowledgeable
> kernel hackers looked at devfs and given up on it.  Despite what some
> people say about Richard, he is a good guy, and he did not succeed
> either.

None taken.

I understand your view but my point here (at this stage) is not
necessarily to revive devfs development but to provide some maintenance
only support for those that need it during the (what appears to be
inevitable) transition. In particular, keeping it around while people
still need it.

>
> devfs is hard to get right and, worse, you will be starting with a bad
> base of code that I would not want to touch with an 18.72 foot pole.
>
> Greg, via udev, has made it so easy to just back up, slowly, and walk
> away from devfs.  devfs is not going anywhere in 2.6, I do not think,
> but let sleeping piles of crap sleep and let's just jettison this thing
> as soon as we can.

Ohh! Nasty pastie.

>
> Just my two cents - I am warning you ;)

My mother always said I was deaf.

Ian

Re: DevFS vs. udev

[Rob Love]

On Tue, 2003-12-23 at 21:21, Ian Kent wrote:

> I understand your view but my point here (at this stage) is not
> necessarily to revive devfs development but to provide some maintenance
> only support for those that need it during the (what appears to be
> inevitable) transition. In particular, keeping it around while people
> still need it.
> 
> My mother always said I was deaf.

Well, good luck to you :)

Do not say no one warned you!

	Rob Love

Re: DevFS vs. udev

[Stan Bubrouski]

On Tue, 2003-12-23 at 21:22, Rob Love wrote:
> On Tue, 2003-12-23 at 21:21, Ian Kent wrote:
> 
> > I understand your view but my point here (at this stage) is not
> > necessarily to revive devfs development but to provide some maintenance
> > only support for those that need it during the (what appears to be
> > inevitable) transition. In particular, keeping it around while people
> > still need it.
> > 
> > My mother always said I was deaf.
> 
> Well, good luck to you :)
> 
> Do not say no one warned you!
> 

Do you think Linus would even accept patches for this?  I'm just
curious, are bugfixes still going into it at all?

-sb

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

Re: DevFS vs. udev

[Rob Love]

On Tue, 2003-12-23 at 21:32, Stan Bubrouski wrote:

> Do you think Linus would even accept patches for this?  I'm just
> curious, are bugfixes still going into it at all?

I am sure that Andrew would take patches.

But I also suspect that devfs won't be around forever.  While it is,
though, there seems no reason not to take patches that fix bugs.

	Rob Love

Re: DevFS vs. udev

[Andrew Morton]

Ian Kent <raven@themaw.net> wrote:
>
> However, if Andrew wants it gone from the kernel there is no point.

I do not.  devfs shall remain in 2.6 and shall continue to be supported.

Richard has disappeared but Andrey Borzenkov understands devfs well and
performed valuable work on it during 2.5 development.


Nor would I recommend that devfs be removed early from 2.7.x.  We should
wait until the proposed udev/sysfs solutions have matured in 2.6 and have
proven themselves in the field.  Only then will we be in a position to
confirm that devfs can be removed without causing some people unacceptable
levels of grief.    There is no rush.


And yes, there are architectural/cleanliness issues with devfs.  In 2.5
Adam Richter totally reinventing devfs's internals, basing it around the
ramfs infrastructure.  If we elect to retain devfs in 2.8 then that effort
should be resurrected.


Now would be a good time for someone to feed the whole thing through indent
though.

Re: DevFS vs. udev

[viro]

On Tue, Dec 23, 2003 at 06:38:20PM -0800, Andrew Morton wrote:
 
> And yes, there are architectural/cleanliness issues with devfs.  In 2.5
> Adam Richter totally reinventing devfs's internals, basing it around the
> ramfs infrastructure.  If we elect to retain devfs in 2.8 then that effort
> should be resurrected.

Switching internals to ramfs won't be enough, though.  There are problems
with devfs API that can't be solved by work on internals - lifetime rules
for devfs nodes make no sense.  Take a look at the insertion/removal
primitives and think of the lifetime rules they create for directories and
user-created nodes.  _That_ is independent from the way you implement
the internals (and sanitized version of the interface won't fit into
use of ramfs, BTW).

Re: DevFS vs. udev

[Witukind]

On Wed, 24 Dec 2003 03:41:21 +0000
viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Tue, Dec 23, 2003 at 06:38:20PM -0800, Andrew Morton wrote:
>  
> > And yes, there are architectural/cleanliness issues with devfs.  In
> > 2.5 Adam Richter totally reinventing devfs's internals, basing it
> > around the ramfs infrastructure.  If we elect to retain devfs in 2.8
> > then that effort should be resurrected.
> 
> Switching internals to ramfs won't be enough, though.  There are
> problems with devfs API that can't be solved by work on internals -
> lifetime rules for devfs nodes make no sense.  Take a look at the
> insertion/removal primitives and think of the lifetime rules they
> create for directories and user-created nodes.  _That_ is independent
> from the way you implement the internals (and sanitized version of the
> interface won't fit into use of ramfs, BTW).

What's the difference that prevents Linux from having a "good" devfs since
FreeBSD is happy with this feature? 

-- 
Jabber: heimdal@jabber.org

Re: DevFS vs. udev

[Rusty Russell]

On Tue, 23 Dec 2003 03:51:58 -0800
"Bradley W. Allen" <ULMO@Q.NET> wrote:

> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".

Badley, you've made an unvaluable contribution today.  The least I can
do is punctuate your words with my own thoughts, below:

> *  User space is slow, causing all sorts of extra work for device
>    accesses.

Hey, I didn't realize that!  It seems so unlikely.

> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

I hear you: if it were slow and buggy, it *would* be slow and buggy.
I had never really thought of it in that way before.

> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!

Now, I've heard that too!

>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
>    solid for over half a decade, so it belongs in stable kernels.

And who's thinking about the poor users?  Their upturned faces, full of
trust and love: their shining lack of experience, unstained by harsh
knowledge of programming realities.  These people have needed a voice:
a hero if you will.

> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

Agreed.  Not to put it too harshly, these "kernel hackers" are cruel
overlords, jealously guarding their free code from the users who need it.

It's time for the USERS to rise up and speak.  But who will speak for
them?  Who?

> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

You're right: WE know what we want!  All we need is someone like US:
close to the users, NOT close to the code!

> *  Viro also said that devfs had been "shoved" into the tree, and
>    that it "had stayed around for many months".  It's been stable for
>    many *YEARS*, for most of a *DECADE*.

This Viro, he's another one of these oppressive "coders", right?
It seems pretty clear that we need LESS coders making technical
decisions which effect users, an MORE users making technical
decisions!

> I've spent two hours on this problem, and that's absurd

After reading the precision and sophistication of your prose, your
grasp of technical content is clear.  Finding out that you'd spent two
hours on *anything* technical is shocking to me.

> Luckily, this is just software, so we can do what we want with it, but
> organizationally it is conceptually just as bad.

Reading this last sentence brought tears to my eyes.  Really.

I think I speak for most people on this list when I say that the kernel
NEEDS people like you like we need devfs itself.  I remember in 2.3, when
we all needed devfs badly, and that's how we got it: we needed it, and
it went in.  Now those same people who didn't want it in the first place
want it removed.

Badley, I ask you in all seriousness: will you take up the challenge,
and fill the gaping hole which we've all felt for so long in the Linux
community?  To give raw, unvarnished feedback, unconfused by the
complexities of code?

I, for one, see the future lies in your posts.
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Re: DevFS vs. udev

[Stan Bubrouski]

On Tue, 2003-12-23 at 23:13, Rusty Russell wrote:
<SNIP some hilarity>
> Badley, I ask you in all seriousness: will you take up the challenge,
> and fill the gaping hole which we've all felt for so long in the Linux
> community?  To give raw, unvarnished feedback, unconfused by the
> complexities of code?
> 
> I, for one, see the future lies in your posts.
> Rusty.

Umm well said?  For the sake of completeness, I direct 'Badley' to the
UDEV FAQ for further info on his future crusade. LOL.

http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

And umm, can we kill this thread, I foresee a flamefest in the works.

-sb

Re: DevFS vs. udev

[Xavier Bestel]

Le mer 24/12/2003 à 05:38, Stan Bubrouski a écrit :

> And umm, can we kill this thread, I foresee a flamefest in the works.


I have to admit that devfs is the best, hands down, at a crucial lkml
exercise: the flamefest. It seems even after it'll die, it will continue
to attract devotees and flames.

Re: DevFS vs. udev

[Ian Soboroff]

Xavier Bestel <xavier.bestel@free.fr> writes:

> I have to admit that devfs is the best, hands down, at a crucial lkml
> exercise: the flamefest. It seems even after it'll die, it will continue
> to attract devotees and flames.

Perhaps the devfs devotees will maintain their code in BK, and we can
merge two perennial lkml flamewars into one.

Ian

Re: DevFS vs. udev

[Xavier Bestel]

Le mer 24/12/2003 à 14:44, Ian Soboroff a écrit :
> Xavier Bestel <xavier.bestel@free.fr> writes:
> 
> > I have to admit that devfs is the best, hands down, at a crucial lkml
> > exercise: the flamefest. It seems even after it'll die, it will continue
> > to attract devotees and flames.
> 
> Perhaps the devfs devotees will maintain their code in BK, and we can
> merge two perennial lkml flamewars into one.

BK flames seem so passé to me. Throw in a new durable API to enable
binary-only device drivers, and you just built the perfect flamethrower.