devfs and udev
Mr. Rullgard,
Quoted 9 lines
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.
I think the two things which really prevented devfs from working were:
1. The namespace was too different from the original and required additional configuration to maintain compatibility (devfsd and changes to core /etc files.)
2. Devfs was not immediately picked up my the major distros, which meant that any moderate end-user who wanted to use it would have to be careful when setting it up or risk massive core breakage due to the changed device nodes (initscripts failing and the like).
I used it for a very long time, personally; it was a good idea, and it had potential. If the namespace that had been used was the same flat namespace as the original /dev, it would have probably taken off. As it is, I think udev is the new way of doing this (I haven't used it yet).
Brad
=====
Brad Chapman
Permanent e-mail: [email protected]
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Quoted 1 line · Bradley Chapman
I think the two things which really prevented devfs from working were:
It's always worked just fine for me.
Quoted 3 lines
1. The namespace was too different from the original and required additional configuration to maintain compatibility (devfsd and changes to core /etc files.)
Since when do Linux developers resist changes?
Quoted 4 lines
2. Devfs was not immediately picked up my the major distros, which meant that any moderate end-user who wanted to use it would have to be careful when setting it up or risk massive core breakage due to the changed device nodes (initscripts failing and the like).
Had it been pushed harder, they probably would have done it.
Quoted 4 lines
I used it for a very long time, personally; it was a good idea, and it had potential. If the namespace that had been used was the same flat namespace as the original /dev, it would have probably taken off. As it is, I think udev is the new way of doing this (I haven't used it yet).
The different naming was one thing i liked about devfs. Go read the archives from a couple of years ago, and see that the exact same arguments that were used to promote devfs, are now said to be bad things. This sudden change is what I don't understand, and how the not-working udev is supposed to be able to replace devfs.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 23 lines · Måns Rullgård
Quoted 1 line · Bradley Chapman
I think the two things which really prevented devfs from working were:
It's always worked just fine for me.
Quoted 3 lines
1. The namespace was too different from the original and required additional configuration to maintain compatibility (devfsd and changes to core /etc files.)
Since when do Linux developers resist changes?
Quoted 4 lines
2. Devfs was not immediately picked up my the major distros, which meant that any moderate end-user who wanted to use it would have to be careful when setting it up or risk massive core breakage due to the changed device nodes (initscripts failing and the like).
Had it been pushed harder, they probably would have done it.
Quoted 4 lines
I used it for a very long time, personally; it was a good idea, and it had potential. If the namespace that had been used was the same flat namespace as the original /dev, it would have probably taken off. As it is, I think udev is the new way of doing this (I haven't used it yet).
Quoted 5 lines
The different naming was one thing i liked about devfs. Go read the archives from a couple of years ago, and see that the exact same arguments that were used to promote devfs, are now said to be bad things. This sudden change is what I don't understand, and how the not-working udev is supposed to be able to replace devfs.
I am pro-devfs guy too.
If its internals are bad in some way or other, internals may be fixed. But devfs userspace-visible interface was not flawed (IMO).
What am I supposed to do, starting to use mknod again? Uggggh... --
vda
Quoted 6 lines · insecure
I am pro-devfs guy too.
If its internals are bad in some way or other, internals may be fixed. But devfs userspace-visible interface was not flawed (IMO).What am I supposed to do, starting to use mknod again? Uggggh...
Feel free to try and redesign the internals until they become
acceptable. Since *nobody* had achieved that and those who'd tried had generally come to conclusion that things is FUBAR... Good luck, but I'm not holding my breath.
Quoted 2 lines · insecure
What am I supposed to do, starting to use mknod again? Uggggh...
Provide me with a kernel name to devfs name mapping file so that I can create a "devfs like" udev config file for people who happen to like that naming scheme.
thanks,
greg k-h
Quoted 6 lines · Greg KH
Quoted 1 line · insecure
What am I supposed to do, starting to use mknod again? Uggggh...
Provide me with a kernel name to devfs name mapping file so that I can create a "devfs like" udev config file for people who happen to like that naming scheme.
It seems that we have a bit of misunderstanding here.
I just don't want to go back to /dev being actually placed on real, on-disk fs.
I won't mind if naming scheme will change as long as device names start with '/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.
Signature · 1 line
vda
Quoted 10 lines · insecure
Quoted 6 lines · Greg KH
Quoted 1 line · insecure
What am I supposed to do, starting to use mknod again? Uggggh...
Provide me with a kernel name to devfs name mapping file so that I can create a "devfs like" udev config file for people who happen to like that naming scheme.
It seems that we have a bit of misunderstanding here.
Quoted 7 lines
I just don't want to go back to /dev being actually placed on real, on-disk fs.
I won't mind if naming scheme will change as long as device names start with '
/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.
udev can do this. Is there some documentation that you read that has suggested otherwise?
greg k-h
Quoted 6 lines · Greg KH
Quoted 5 lines · insecure
It seems that we have a bit of misunderstanding here.
I just don't want to go back to /dev being actually placed on real, on-disk fs.
Quoted 7 lines
Quoted 4 lines
I won't mind if naming scheme will change as long as device names start with '
/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.udev can do this. Is there some documentation that you read that has suggested otherwise?
Lets see if I can make this clear, devfs is a virtual file system. If I mount my root drive without mounting devfs, the /dev directory is empty. udev is not like this, it is like the normal /dev that can be built with mknod, special files in a real filesystem. But udev is told by the kernel what files to make and remove. So it is still a dynamic filesystem, just in userland with kernel notifications rather than a filesystem that is entirely in kernel space.
devfsd could use a "/dev-state" (or similar) directory to preserve the state of any changes made to the virtual filesystem using normal userland tools are mirrored in that directory.
I am also a huge devfs fan. I was building 2.2.x kernels with Richard's patches before 2.4.0 was released. I like just having an empty /dev and knowing the kernel will take care of everything I need at boot.
I'm thinking this will not exactly work with udev, as you will need a few seed nodes to get to userland so udev can be started. Then udev will create the entries for devices that actually exist on the machine, and then these entries will still be present at the next boot. So it will just be a problem for initial installs.
Right?
I can handle all of this. I'm flexible. Just make it work. :)
Signature · 1 line
Chris
Quoted 12 lines · Chris Meadors
Quoted 11 lines · Greg KH
Quoted 9 lines · insecure
It seems that we have a bit of misunderstanding here.
I just don't want to go back to /dev being actually placed on real, on-disk fs.
I won't mind if naming scheme will change as long as device names start with '
/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.
Quoted 4 lines
Quoted 2 lines
udev can do this. Is there some documentation that you read that has suggested otherwise?
Lets see if I can make this clear, devfs is a virtual file system.
I know that, please give me some credit here. I've used devfs before, and rutted around in all of it's dirt for a long time. It's not like I'm suddenly creating some wild, hair brained scheme out of thin air here. I've been working toward this solution for a number of years now (see the proposal from Pat Mochel and myself at the kernel summit two years ago, and my 5 minute talk this year), and it hasn't exactly been in private. There have been a number of discussions in public places (two different kernel summits, OLS papers, and lots of linux-kernel and linux-hotplug-devel mail traffic), so this shouldn't be that much of a shock to the devfs lovers out there.
And remember, _I_ did not submit that patch to the kernel marking devfs obsolete. Other kernel developers did. And for good reasons, which have all been explained before. Even if udev wasn't even written yet, it would have been done.
Quoted 6 lines
If I mount my root drive without mounting devfs, the /dev directory is empty. udev is not like this, it is like the normal /dev that can be built with mknod, special files in a real filesystem. But udev is told by the kernel what files to make and remove. So it is still a dynamic filesystem, just in userland with kernel notifications rather than a filesystem that is entirely in kernel space.
Again:
mount -t ramfs none /dev
There, empty filesystem. No persistance. Happy?
Quoted 3 lines
devfsd could use a "/dev-state" (or similar) directory to preserve the state of any changes made to the virtual filesystem using normal userland tools are mirrored in that directory.
See the OLS paper for how this will be handled.
Quoted 3 lines
I am also a huge devfs fan. I was building 2.2.x kernels with Richard's patches before 2.4.0 was released. I like just having an empty /dev and knowing the kernel will take care of everything I need at boot.
Great. I hope you have enjoyed your security problems, and race conditions too. :)
Quoted 7 lines
I'm thinking this will not exactly work with udev, as you will need a few seed nodes to get to userland so udev can be started. Then udev will create the entries for devices that actually exist on the machine, and then these entries will still be present at the next boot. So it will just be a problem for initial installs.
Right?
Look at the boot process today. We "seed" a ramfs with some initial /dev entries in order to boot the kernel from initramfs. udev will take off from there and keep creating new entries as devices are discovered, long before init and the rest of userspace starts up.
Quoted 1 line
I can handle all of this. I'm flexible. Just make it work. :)
Patches are always gladly accepted.
People, come on, please read the existing documentation before coming up with some half-baked ideas about what udev is. Yes, there is a gap with the existing documentation, and some people have very nicely pointed this out. But if I have to spend my time answering questions that are already answered, I'll never have the time to flush out these gaps, and actually do some udev programming...
greg k-h
Quoted 4 lines · Greg KH
And remember, _I_ did not submit that patch to the kernel marking devfs obsolete. Other kernel developers did. And for good reasons, which have all been explained before. Even if udev wasn't even written yet, it would have been done.
"Note that devfs has been obsoleted by udev,"
Most people expect after reading that sentence, that udev can do the work devfs did for them. But udev is not ready to do that, even by far. Thats why people complain.
Also all the documentation you mention doesn't help very much:
if someone wants to sit down, use devfs, even improve some parts of the kernel with sysfs support, so sysfs will show all devices - there is no documentation or example how to do that. The whole kobject / sysfs / driver model code is by far not as easy to understand as those devfs function calls are.
Quoted 1 line
Patches are always gladly accepted.
How can we patch udev, if sysfs doesn't seem to have the necessary information. for example devfs has disc, floppy, cdrom. sysfs has only /sys/block/hd*. Sorry, but I don't see how udev can create a result like devfs did, without the necessary information in /sys. And the kernel code isn't easy.
Quoted 1 line
People, come on, please read the existing documentation
show me that I'm wrong, and those questions I asked are documented, and I will be happy and appologize. But I'm very sorry: even reading your papers a hundred times doesn't show how drivers are supposed to create custom entries for more devices. With devfs it's a five minute look at a few drivers like floppy.c and printers.c and you get the idea.
Also the documentation is actualy confusing: why is a usb printer put into class "usb" and not class printer? Why does udev decide the type of device by matching /sys/block, why not export that data explicit? Why not export default permissions, like devfs does?
With some answers, we might understand udev and sysfs better and might be able to help. But asking for patches is not going to work, if basic questions are left without answers.
Regards, Andreas
PATCH 1/1 document that udev isn't yet ready
Quoted 6 lines · Andreas Jellinghaus
Quoted 4 lines · Greg KH
And remember, _I_ did not submit that patch to the kernel marking devfs obsolete. Other kernel developers did. And for good reasons, which have all been explained before. Even if udev wasn't even written yet, it would have been done.
Quoted 6 lines
"Note that devfs has been obsoleted by udev,"
Most people expect after reading that sentence, that udev can do the work devfs did for them. But udev is not ready to do that, even by far. Thats why people complain.
...
The following trivial change to te help text should clarify it:
fs/Kconfig renamed from fs/Kconfig.old +1 -1
@@ -784,7 +784,7 @@ ptys, you will also need to enable (and mount) the /dev/pts filesystem (CONFIG_DEVPTS_FS). - Note that devfs has been obsoleted by udev, + Note that devfs will be 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
Quoted 1 line
Regards, Andreas
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 11 lines · Greg KH
Quoted 11 lines
Quoted 5 lines
Quoted 1 line
What am I supposed to do, starting to use mknod again? Uggggh...
Provide me with a kernel name to devfs name mapping file so that I can create a "devfs like" udev config file for people who happen to like that naming scheme.
It seems that we have a bit of misunderstanding here.
I just don't want to go back to /dev being actually placed on real, on-disk fs.
Quoted 7 lines
Quoted 4 lines
I won't mind if naming scheme will change as long as device names start with '
/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.udev can do this. Is there some documentation that you read that has suggested otherwise?
It's been my understanding that udev creates device nodes in a regular filesystem. If this is the case, things like unclean reboots will leave stale files behind. It will also not be easy to bootstrap. Correct me if am wrong.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 18 lines · Måns Rullgård
Quoted 16 lines · Greg KH
Quoted 15 lines
Quoted 5 lines
Quoted 1 line
What am I supposed to do, starting to use mknod again? Uggggh...
Provide me with a kernel name to devfs name mapping file so that I can create a "devfs like" udev config file for people who happen to like that naming scheme.
It seems that we have a bit of misunderstanding here.
I just don't want to go back to /dev being actually placed on real, on-disk fs.
I won't mind if naming scheme will change as long as device names start with '
/dev/' and appear there (semi-)automagically. That's what I call devfs. If udev can do this, I am all for that.
Quoted 7 lines
Quoted 2 lines
udev can do this. Is there some documentation that you read that has suggested otherwise?
It's been my understanding that udev creates device nodes in a regular filesystem. If this is the case, things like unclean reboots will leave stale files behind. It will also not be easy to bootstrap. Correct me if am wrong.
mount -t ramfs none /dev
That is what udev will run off of :)
Again, can you point me to any documentation that states that udev will do this on a persistant filesystem?
thanks,
greg k-h
Quoted 8 lines · Greg KH
Quoted 4 lines
It's been my understanding that udev creates device nodes in a regular filesystem. If this is the case, things like unclean reboots will leave stale files behind. It will also not be easy to bootstrap. Correct me if am wrong.
mount -t ramfs none /dev
That is what udev will run off of :)
There will still have to be some static device files to get the system booted, right? init usually is rather unhappy if it can't find /dev/console.
Quoted 2 lines
Again, can you point me to any documentation that states that udev will do this on a persistant filesystem?
Can you point me to any documentation at all?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 3 lines · Måns Rullgård
There will still have to be some static device files to get the system booted, right? init usually is rather unhappy if it can't find
/dev/console.
There are the necessary few in initramfs already.
Quoted 1 line
Can you point me to any documentation at all?
Really, I don't know why Greg is bothering to answer your questions.
This stuff is all readily accessible via (a) getting off your nethers and doing a Google search for "linux udev" and (b) reading what you find. It's trivial to find, and it's utterly obvious how it works.
Sheesh.
<b
Quoted 7 lines · Bryan O'Sullivan
Quoted 1 line
Can you point me to any documentation at all?
Really, I don't know why Greg is bothering to answer your questions.
This stuff is all readily accessible via (a) getting off your nethers and doing a Google search for "linux udev" and (b) reading what you find. It's trivial to find, and it's utterly obvious how it works.
I followed the link provided in the Kconfig, and downloaded the files that seemed reasonable. The only documentation I found there warned me against using it.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · Måns Rullgård
Quoted 4 lines · Bryan O'Sullivan
Quoted 1 line
Can you point me to any documentation at all?
Really, I don't know why Greg is bothering to answer your questions.
Quoted 7 lines
Quoted 3 lines
This stuff is all readily accessible via (a) getting off your nethers and doing a Google search for "linux udev" and (b) reading what you find. It's trivial to find, and it's utterly obvious how it works.
I followed the link provided in the
Kconfig, and downloaded the files that seemed reasonable. The only documentation I found there warned me against using it.
Then don't use it, no one is forcing you to.
But if you do, wow, look at the second Google link for "linux udev":
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0495.html
Hey look, documentation, a presentation, and wow, a statement saying that the code sucks, and is merely a proof of concept, and that it will get better over time. That's a zillion lines more of text than most open source projects ever generate.
{sigh}
greg k-h
Quoted 2 lines · Greg KH
Hey look, documentation, a presentation, and wow, a statement saying that the code sucks, and is merely a proof of concept, and that it will
I never meant to say that udev never will be a viable solution. I also understand now that devfs has problems that nobody is willing solve. Thus the marking as obsolete may be justified. However, the statement that it has been obsoleted *by* udev, is, IMHO, a little bold.
Signature · 2 lines
Måns Rullgård [email protected]
In article <[email protected]>,
Greg KH <[email protected]> wrote:
| mount -t ramfs none /dev | | That is what udev will run off of :) | | Again, can you point me to any documentation that states that udev will | do this on a persistant filesystem?
I'm going back to look again, but I don't recall that it won't, either. If it wants a ramfs on /dev, why doesn't it just create one? That's a question, not an argument! I had assumed it would run on a persistent f/s if present.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 10 lines · bill davidsen
In article <[email protected]>,
Greg KH <[email protected]> wrote:| mount -t ramfs none /dev | | That is what udev will run off of :) | | Again, can you point me to any documentation that states that udev will | do this on a persistant filesystem?
Quoted 4 lines
I'm going back to look again, but I don't recall that it won't, either. If it wants a ramfs on /dev, why doesn't it just create one? That's a question, not an argument! I had assumed it would run on a persistent f/s if present.
Whatever f/s udev runs on is independant of udev, it just runs. Ideally distros / packagers should set things up so that it runs on ramfs.
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Quoted 29 lines · Bradley Chapman
Date: Tue, 7 Oct 2003 06:17:19 -0700 (PDT)
From: Bradley Chapman <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: devfs and udevMr. Rullgard,
Quoted 9 lines
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.
Quoted 5 lines
I think the two things which really prevented devfs from working were:
1. The namespace was too different from the original and required additional configuration to maintain compatibility (devfsd and changes to core /etc files.)
the namespace was different becouse Linus demanded that it be different, origionally it had a mode where it would generate all the same names (and another mode that generated sun style names) one of the requirements before it was put in was to change it to the existing devfs-only names.
blame devfs for a lot of things (bugs, etc) but not the names.
David Lang
Quoted 27 lines
2. Devfs was not immediately picked up my the major distros, which meant that any moderate end-user who wanted to use it would have to be careful when setting it up or risk massive core breakage due to the changed device nodes (initscripts failing and the like).
I used it for a very long time, personally; it was a good idea, and it had potential. If the namespace that had been used was the same flat namespace as the original /dev, it would have probably taken off. As it is, I think udev is the new way of doing this (I haven't used it yet).
Brad
=====
Brad ChapmanPermanent e-mail: [email protected]
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
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/
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Followup to: <[email protected]> By author: David Lang <[email protected]> In newsgroup: linux.dev.kernel
Quoted 8 lines
the namespace was different becouse Linus demanded that it be different, origionally it had a mode where it would generate all the same names (and another mode that generated sun style names) one of the requirements before it was put in was to change it to the existing devfs-only names.
blame devfs for a lot of things (bugs, etc) but not the names.
Actually, this is bullshit. If you go back and look what Linus actually said, it was:
- One namespace only. If you're going to a new namespace, then that's going to be it. You're not going to put two namespaces in the kernel.
- If you're going hierarcial, do it right, not the Sun-like halfassed thing.
-hpa
Signature · 4 lines
<[email protected]> at work, <[email protected]> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64