devfs vs. udev
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.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 3 lines · 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,
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
Quoted 5 lines · Andreas Jellinghaus
Quoted 3 lines
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.
Quoted 6 lines
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.
Signature · 2 lines
Måns Rullgård [email protected]
Thus spake M?ns Rullg?rd ([email protected]):
Quoted 9 lines
Quoted 5 lines · Andreas Jellinghaus
Quoted 3 lines
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.
Quoted 7 lines
Quoted 6 lines
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
Quoted 7 lines
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.
Quoted 3 lines · Robert L. Harris
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?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 3 lines · Robert L. Harris
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
Quoted 8 lines · Andreas Jellinghaus
Quoted 3 lines
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.
Quoted 6 lines
Also: do you prefer a devs compatible layout, or maybe use the change for a cleanup? a short list of obscurities:
/dev/cdroms/cdrom0but/dev/printers/0and/dev/tts/0and/dev/floppybut/dev/discsetc. also all floppy devices are in/dev/floopy, where each disc has is/dev/discs/discNdirectory/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.
Signature · 2 lines
Måns Rullgård [email protected]
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 ([email protected]):
Quoted 16 lines · Robert L. Harris
Quoted 3 lines
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/cdrom0but/dev/printers/0and/dev/tts/0and/dev/floppybut/dev/discsetc. also all floppy devices are in/dev/floopy, where each disc has is/dev/discs/discNdirectory/symlink. I think it's a good opportunity for a cleanup, but that wouldn't be compatible...
Quoted 7 lines
Regards, Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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.
Quoted 4 lines · Andreas Jellinghaus
Quoted 3 lines · Robert L. Harris
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.
Quoted 2 lines
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/.
Quoted 1 line
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.
Signature · 3 lines
=== 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. --- Quoted 3 lines · Hugo Mills
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.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 9 lines · Måns Rullgård
Quoted 3 lines · Hugo Mills
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
Quoted 4 lines · Hugo Mills
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
Quoted 7 lines · Greg KH
Quoted 4 lines · Hugo Mills
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.
Quoted 2 lines
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.
Signature · 3 lines
=== 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. --- Quoted 7 lines · Hugo Mills
Quoted 6 lines · Greg KH
Quoted 4 lines · Hugo Mills
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 11 lines · Greg KH
Quoted 4 lines · Hugo Mills
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?
Quoted 7 lines · Ian Kent
Quoted 6 lines · Greg KH
Quoted 4 lines · Hugo Mills
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.
Quoted 7 lines
Quoted 5 lines
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
Quoted 6 lines · Måns Rullgård
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
Quoted 17 lines · Måns Rullgård
Quoted 5 lines · Andreas Jellinghaus
Quoted 3 lines
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.
Quoted 6 lines
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
Quoted 7 lines
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?
Signature · 4 lines
,-._|\ Ian Kent / \ Perth, Western Australia *_.--._/ E-mail: [email protected] v Web: http://themaw.net/
Quoted 5 lines · Ian Kent
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
Quoted 3 lines · Andreas Jellinghaus
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
Quoted 9 lines · 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.
Quoted 11 lines
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.]
Quoted 10 lines · 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.
Quoted 3 lines
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.)
Quoted 4 lines
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 :)
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 6 lines · Greg KH
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.