devfs vs udev, thoughts from a devfs user

devfs vs udev, thoughts from a devfs user

[Mike Bell]

I've been reading a lot lately about udev and how it's both very
different to and much better than devfs, and with _most_ of the reasons
given, I can't see how either is the case. I'd like to lay out why I
think that is.

I keep hearing about how udev has no naming policy in the kenel, while
devfs has a fixed one and if you don't like it tough. But udev relies on
sysfs, which IS naming policy in the kernel. And devfs has devfsd, which
is a userspace daemon that listens to a kernel-exported filesystem (just
like udev) and can create whatever /dev layout you want from that, in
userspace (just like udev). Basically, udev relies on sysfs exporting
device numbers. Well, imagine for a moment sysfs exported actual device
files instead of just the numbers you'd need to make a device file (a
pretty minor change, though not one I'm advocating). What you've got
there is basically devfs and devfsd, right? Not the same
implementation-wise, obviously, but essentially IDENTICAL concepts.
Kernel exports device files to a kernel-generated filesystem, user-space
daemon creates /dev from those with a layout according to your liking.

Meanwhile, devfs (or a devfs-like solution) offer several things which
udev just can't. Having a special kernel-exported filesystem just for
/dev means your user-space daemon can see when a program is trying to
access a device file that doesn't exist yet, you can't do that with
udev and tmpfs. Moreover, it means you've got a functional /dev that
accurately represents the system regardless of whether the user-space
daemon is running yet. With udev, you're stuck with a static /dev unless
udev is running. This can happen when broken system or doing a fresh
installation, or if you accidentally break your udev binary. And heavens
help you if linux ever moves to dynamic device files, that would make a
static /dev completely unusable. Which would in turn mean that your
system is unusable unless udev is running. It's not a big problem, but
myself I find myself using devfs without devfsd for those two reasons
every once in a while, and in those instances devfs is really nice.

So the question is, is a devfs-like implementation really unfixable? And
if not, is it worth whatever disadvantages can't be avoided? On the
matter of memory usage, I'm really not sure why a new devfs couldn't be
tied to the new device model. As I said earlier, it's only a subtle
change from exporting a major and minor in sysfs to exporting a device
file (in newdevfs or wherever). And I haven't heard anyone say devfs's
race conditions are inherent to the idea, just that devfs's
implementation has them.

Finally, from /my/ experience, the one thing people disliked most about
devfs was the long names for hard drive partitions. But isn't one of the
first things on the agenda for 2.7 taking the partition detection code
out of the kernel and replacing it with device-mapper? If you do that,
then the block devices you actually USE are all device mapper created.
They're already controlled by a user-space daemon. The real block
devices are only used when you're partitioning (or LVMing, or EVMSing,
or whatever). The rest of the time, in /etc/fstab or passing to mkfs or
whatever else, you're using the dm devices. Now there's no reason
a new devfs would HAVE to export long and unwieldy names for block
devices, but if the only time you're actually using those names is for
repartitioning, I really wouldn't care if they were long and unwieldy.
It wouldn't show up in fstab, or df, or anywhere else the devfs style
names have made a nuicance of themselves, so who cares?

Sorry if any of these points has already been discussed on
linux-kernel, I don't have time to read the list so I'm going based on
what's been reported in things like kernel-traffic.

Re: devfs vs udev, thoughts from a devfs user

[Helge Hafting]

Mike Bell wrote:
> I've been reading a lot lately about udev and how it's both very
> different to and much better than devfs, and with _most_ of the reasons
> given, I can't see how either is the case. I'd like to lay out why I
> think that is.
> 
> I keep hearing about how udev has no naming policy in the kenel, while
> devfs has a fixed one and if you don't like it tough. 

One of the weakest arguments - who really cares if the kernel sets some
device names?  Makedev users rarely change those names either, although
they can.  Those rare cases where you need to rename a device so some
stupid binary-only thing can find it is solvable by symlinks.

Devfs is dying because nobody bothers fixing it (and it is believed
to be a big job).  Those who can seems to like udev.  No matter what
virtues devfs may have - arguments are useless unless someone volunteers
to maintain it.  I don't think it will disappear if someone does that and
does it well, but I am sure it _will_ go if nobody does.
A nice concept not yet implemented properly doesn't cut it.

> But udev relies on
> sysfs, which IS naming policy in the kernel. And devfs has devfsd, which
> is a userspace daemon that listens to a kernel-exported filesystem (just
> like udev) and can create whatever /dev layout you want from that, in
> userspace (just like udev). Basically, udev relies on sysfs exporting
> device numbers. Well, imagine for a moment sysfs exported actual device
> files instead of just the numbers you'd need to make a device file (a
> pretty minor change, though not one I'm advocating). What you've got
> there is basically devfs and devfsd, right? Not the same

Interesting idea.

> implementation-wise, obviously, but essentially IDENTICAL concepts.
> Kernel exports device files to a kernel-generated filesystem, user-space
> daemon creates /dev from those with a layout according to your liking.
> 
> Meanwhile, devfs (or a devfs-like solution) offer several things which
> udev just can't. Having a special kernel-exported filesystem just for
> /dev means your user-space daemon can see when a program is trying to
> access a device file that doesn't exist yet, 

Devfs can do this, but it is not necessarily a good thing.
I tried it - and it only works if someone tries to look up
a particluar name, such as /dev/dsp.  It doesn't work when someone
does a "ls /dev" to see what devices is there.
A "ls /dev/dsp*" didn't find the multiple soundcards for which
modules weren't yet loaded.

So you can list and see nothing, and still have stuff magically
appear _if_ you know what the name ought to be.  A hairy concept.
Do you know the device name for the second sound device?

The point of this is module users - they can delay module loading
till the module is needed.  Supporting opening of "nonexisting" devices
required a trigger mechanism though - devfsd had to know what module
to load at lookup time.

Non-devfs setups (with or without udev) support a similiar trigger
mechanism for module loading, that is simpler to set up and understand.
And that is a persistend device node.  Plain, simple, and ls sees it too.
Open it and the device is loaded as needed.  And at open time, not
at lookup time.  Load at lookup time might not be necessary, after all.

devfs gave us a /dev uncluttered by nonexisting hardware - now
udev can do that part and some persistent nodes can do the module 
loading part. 

> you can't do that with
> udev and tmpfs. Moreover, it means you've got a functional /dev that
> accurately represents the system regardless of whether the user-space
> daemon is running yet. With udev, you're stuck with a static /dev unless
> udev is running. 

I worried about this too, but notice which way the kernel is going.
"Essential" stuff like parsing the disk partition tables (or getting
a nfs root via dhcp) is being moved out of the kernel and into a
early userspace in initramfs.  Such a thing _must not_ break, so it
is the perfect place to put udev too.  It won't break from mere
misconfiguration because the initramfs isn't on disk but stuffed into
the kernel image where it is safe.  Someone who actually disrupts the kernel
loose anyway.

> This can happen when broken system or doing a fresh
> installation, or if you accidentally break your udev binary. 

Not if it resides in early userspace.  Then you need to break
the kernel image.

> And heavens
> help you if linux ever moves to dynamic device files, that would make a
> static /dev completely unusable. Which would in turn mean that your
> system is unusable unless udev is running. It's not a big problem, but
> myself I find myself using devfs without devfsd for those two reasons
> every once in a while, and in those instances devfs is really nice.
> 
If devfsd ran out of early userspace then you'd never be without that either.

> So the question is, is a devfs-like implementation really unfixable? And
It is fixable, but nobody wants to do it.  They have another solution 
they like better.  Feel free to fix devfs though, then we'll get
choice . . .

Helge Hafting

Re: devfs vs udev, thoughts from a devfs user

[Ian Kent]

Please lets not start another thread that gets us nowhere.

I'm only marginally familiar with devfs and I don't use on a day to day 
basis (but maybe I do now that I have a Gentoo install) but from what I 
have seen....

On Tue, 10 Feb 2004, Mike Bell wrote:

> 
> I keep hearing about how udev has no naming policy in the kernel, while
> devfs has a fixed one and if you don't like it tough. But udev relies on

>From what I can see devfs doesn't have much naming policy in the kernel. 
It appears to be mostly in devfsd.

> 
> Meanwhile, devfs (or a devfs-like solution) offer several things which
> udev just can't. Having a special kernel-exported filesystem just for
> /dev means your user-space daemon can see when a program is trying to
> access a device file that doesn't exist yet, you can't do that with
> udev and tmpfs. Moreover, it means you've got a functional /dev that
> accurately represents the system regardless of whether the user-space
> daemon is running yet. With udev, you're stuck with a static /dev unless
> udev is running. This can happen when broken system or doing a fresh
> installation, or if you accidentally break your udev binary. And heavens
> help you if linux ever moves to dynamic device files, that would make a
> static /dev completely unusable. Which would in turn mean that your
> system is unusable unless udev is running. It's not a big problem, but
> myself I find myself using devfs without devfsd for those two reasons
> every once in a while, and in those instances devfs is really nice.
> 

OK so udev is an alternative under active development. Good, life is all 
about choices.

> So the question is, is a devfs-like implementation really unfixable? And

Yes. I tried using devfs and see there is a lot of work to do to make it 
acceptable quality but .... see below ...

> 
> Finally, from /my/ experience, the one thing people disliked most about
> devfs was the long names for hard drive partitions. But isn't one of the

I happen to like those names.

> first things on the agenda for 2.7 taking the partition detection code
> out of the kernel and replacing it with device-mapper? If you do that,
> then the block devices you actually USE are all device mapper created.

Oh, more work before we begin.

> 
> Sorry if any of these points has already been discussed on
> linux-kernel, I don't have time to read the list so I'm going based on
> what's been reported in things like kernel-traffic.

There is another problem. There is no coherent support group to develop, 
test and disseminate the product. I've been subscribed to the mailing list 
for a while now and have seen only one message. Nothing is going to 
be fixed if the people that would like to use it don't get together to 
support it and develop it.

It's not as if people aren't making an effort. Andrey Borzenkov appears to 
have implemented some significant fixes for devfs and Bradley Chapman has 
been maintaining a branch of devfsd which is a much cleaner restructuring 
of the devfsd code. But Bradley has no way to get this code debugged and 
out to the user public.

So if devfs is needed by people then we must get together and do what is 
needed to support and develop the product.

Lets not forget that, at this point, udev is a recommended replacement for 
devfs, but is (I believe) still in development. So it may well happen 
that udev is an appropriate replacement for devfs at some point and that 
must be considered fairly and sensibly when the time comes.
 
Ian

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 09:32:57PM +0800, Ian Kent wrote:
> So if devfs is needed by people then we must get together and do what is 
> needed to support and develop the product.
> 
> Lets not forget that, at this point, udev is a recommended replacement for 
> devfs, but is (I believe) still in development. So it may well happen 
> that udev is an appropriate replacement for devfs at some point and that 
> must be considered fairly and sensibly when the time comes.

I agree that if udev is going to be maintained while devfs is left to
rot, udev is the way to go. My post was because the impression I got
from the udev author's posts was that devfs was dead and udev was the
designated successor, and superior in every way. Only when I really
looked at the arguments did I start to question.

So really, I was trying to ensure I was correct about devfs
(or the concept, at least) still offerring some things that the udev
concept never will, and to see if there were other people who would
still like to see devfs (or a devfs-alike, reimplemented without its
various problems) live on. It's pretty hard to form a user community for
devfs when it has been declared dead and its successor named, but that's
very much the impression I get from the udev author's posts (or at least
those reproduced in places like kernel-traffic).

So yeah, not an attempt to start a flamewar, I just wanted to register
myself as someone who doesn't see udev as the ideal solution, and see if
there were any others.

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 02:20:19PM +0100, Helge Hafting wrote:
> No matter what virtues devfs may have - arguments are useless unless
> someone volunteers to maintain it.

I completely agree. But who would volunteer to spend their time fixing
devfs if no one said they wanted devfs, if all evidence says everyone is
happy with udev? I just wanted to get out that I'm not, I think devfs
(as a concept, not neccessarily the implementation in the kernel right
now) has merits udev does not and never will possess, and to see if anyone
else agrees.

> Interesting idea.

I didn't mean it as an idea, hence the bit about not advocating it. I'm
just trying to show that they're basically the same thing. The kernel is
exporting in file form three pieces of information, character/block,
major, and minor whether it's done as an actual device file or not.
Trying to show how both are doing the same thing.

> Devfs can do this, but it is not necessarily a good thing.
> I tried it - and it only works if someone tries to look up
> a particluar name, such as /dev/dsp.  It doesn't work when someone
> does a "ls /dev" to see what devices is there.
> A "ls /dev/dsp*" didn't find the multiple soundcards for which
> modules weren't yet loaded.

Nor would you want it to... Although, it might be handy for something
like a SCSI controller. An opendir() in its directory would trigger the
kernel to see what's attached to it. Postponing the probing of every LUN
until someone goes looking could speed up boot times quite a bit.

> I worried about this too, but notice which way the kernel is going.
> "Essential" stuff like parsing the disk partition tables (or getting
> a nfs root via dhcp) is being moved out of the kernel and into a
> early userspace in initramfs.  Such a thing _must not_ break, so it
> is the perfect place to put udev too.  It won't break from mere
> misconfiguration because the initramfs isn't on disk but stuffed into
> the kernel image where it is safe.  Someone who actually disrupts the kernel
> loose anyway.

That's a point, and one I had thought of. But on the other hand, the
kernel also seems to be moving toward exporting information to userspace
through simple RAM based filesystems. And while I don't know enough
about the internals of these things to say for sure, I wouldn't be
surprised if /dev as a special exported filesystem actually took less
RAM than /dev on tmpfs, since tmpfs has to be so much more generic
(supporting files that can be up to ssize_t long, the sendfile() method
so they can be mounted loopback, etc) while a devfs-alike would just be
storing small files: devices, symlinks, fifos, etc. Nothing with actual
data.

> It is fixable, but nobody wants to do it.  They have another solution 
> they like better.  Feel free to fix devfs though, then we'll get
> choice . . .

Well, as I said, no sense in fixing devfs if nobody wants it. udev's
author is giving that impression, but I don't feel that way myself and
wanted to see if anyone else agreed.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 03:34:18AM -0800, Mike Bell wrote:
> I've been reading a lot lately about udev and how it's both very
> different to and much better than devfs, and with _most_ of the reasons
> given, I can't see how either is the case. I'd like to lay out why I
> think that is.

Did you read:
	http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

> Basically, udev relies on sysfs exporting
> device numbers. Well, imagine for a moment sysfs exported actual device
> files instead of just the numbers you'd need to make a device file (a
> pretty minor change, though not one I'm advocating).

But that is not what sysfs does.  And sysfs will not do this.  So this
point is moot.

> Sorry if any of these points has already been discussed on
> linux-kernel, I don't have time to read the list so I'm going based on
> what's been reported in things like kernel-traffic.

They pretty much all have been in the past.  Try reading the archives,
that's what they are there for :)

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mark Mielke]

On Tue, Feb 10, 2004 at 06:46:30AM -0800, Mike Bell wrote:
> I didn't mean it as an idea, hence the bit about not advocating it. I'm
> just trying to show that they're basically the same thing. The kernel is
                           --------------------------------

Exactly... :-)

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, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 09:01:57AM -0800, Greg KH wrote:
> Did you read:
> 	http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Yes, I've read everything since the original OLS one, and liked udev
less and less with each one.

> But that is not what sysfs does.  And sysfs will not do this.  So this
> point is moot.

No, you misunderstand. I'm not suggesting that sysfs /should/ export
device files. I'm saying that sysfs exporting type/major/minor as files
is not really that different from exporting full-fledged device files.
Making udev a sort of ugly-hack devfsd.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 09:13:39AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 09:01:57AM -0800, Greg KH wrote:
> > Did you read:
> > 	http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
> 
> Yes, I've read everything since the original OLS one, and liked udev
> less and less with each one.

Fine, that's your option.  I'm not forcing you to use udev, yet :)

> > But that is not what sysfs does.  And sysfs will not do this.  So this
> > point is moot.
> 
> No, you misunderstand. I'm not suggesting that sysfs /should/ export
> device files. I'm saying that sysfs exporting type/major/minor as files
> is not really that different from exporting full-fledged device files.
> Making udev a sort of ugly-hack devfsd.

No that is not what sysfs is about at all.  sysfs exports the internal
device tree that the kernel knows so that userspace can use this
information for all sorts of different things (proper power management,
etc.)  Please go read all of the sysfs and driver model documentation
(and OLS and linux.conf.au papers) for more details about what sysfs and
the driver core is all about.

And claiming udev as "a sort of ugly-hack devfsd" is pretty harsh.
Given that udev uses a documented, open interface, and easily allows
_any_ program to run from it, no matter what the language.  Try reading
the devfsd code some time, or getting it to run your perl script to name
a single type of device :)

Anyway, I'm done with this devfs vs. udev arguments that in the end go
nowhere.  See that document for my position.

If you like devfs, fine, use it.  If you don't, take a look at udev.
And if you like neither, then either create your own solution, or don't
use either.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 09:25:52AM -0800, Greg KH wrote:
> No that is not what sysfs is about at all.  sysfs exports the internal
> device tree that the kernel knows so that userspace can use this
> information for all sorts of different things (proper power management,
> etc.)  Please go read all of the sysfs and driver model documentation
> (and OLS and linux.conf.au papers) for more details about what sysfs and
> the driver core is all about.

I think you still misunderstand what I'm saying. All I'm saying is that
with either way, kernel is exporting three pieces of information (b/c,
major, minor) to userspace through file(s) on an artificial filesystem.
That's it. I know what sysfs is for, I like sysfs the way it is, I'm not
saying sysfs should be changed in any way. I'm saying that to create a
device with a given name, udev uses magic files exported by the kernel,
and devfsd uses magic file(s) exported by the kernel, and in both cases
they contain the same information. And hence in that sense devfs and
udev are the same. That's it.

What I'm trying to explain by that point is that udev is no more "naming
policy in the kernel" free than devfsd. devfsd relies on devfs, which
has naming policy in the kernel. udev relies on sysfs, which has naming
policy in the kernel. While devfs and sysfs are radically different,
they serve the same purpose for devfsd/udev.

> And claiming udev as "a sort of ugly-hack devfsd" is pretty harsh.
> Given that udev uses a documented, open interface, and easily allows
> _any_ program to run from it, no matter what the language.  Try reading
> the devfsd code some time, or getting it to run your perl script to name
> a single type of device :)

That's something udev does pretty well, and not quite what I meant. I
like devfs, defined for the time being as a working tree of device files
exported by the kernel as a virtual filesystem. For managing
permissions, user-space-dictated device names, and whatever else, I
don't care if you call it devfsd or udev or whatever else. I don't like
udev primarily because it tries to do the job without the help of a
devfs, and I think trying to do that makes it ugly.

> If you like devfs, fine, use it.  If you don't, take a look at udev.

Which was the point of my email. "Hey, I like devfs over udev. Am I
alone in this, or are there others?" As I stated at the start.

Re: devfs vs udev, thoughts from a devfs user

[Chris Friesen]

Mike Bell wrote:

> No, you misunderstand. I'm not suggesting that sysfs /should/ export
> device files. I'm saying that sysfs exporting type/major/minor as files
> is not really that different from exporting full-fledged device files.
> Making udev a sort of ugly-hack devfsd.

What names would you use for your device files?  This is the key 
difference.  With udev it gets a notification that says "I have a new 
block device", it then looks it up, applies the rules, and creates a new 
entry.  The whole point is to move the naming scheme into userspace for 
easier management.

You could have the kernel export a simple devfs with a hardcoded naming 
scheme based on similar ideas as what is in sysfs (which would then make 
sysfs and the daemon optional for tiny embedded setups), but the only 
advantage over just exporting the information in sysfs is to save a few 
bytes at the cost of yet another filesystem to maintain.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 09:01:57AM -0800, Greg KH wrote:
> Did you read:
> 	http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

While we're at it...

>  Problems:
>    1) devfs only shows the dev entries for the devices in the system.

Why is that a bad thing? Why should I want to see dev entries for firewire
drives on my 486 or LPT1 on my legacy-free laptop? 

>    2) devfs does not handle the need for dynamic major/minor numbers

It does as well as udev does. You say it yourself, "if the kernel switches to
dynamic major/minor". The same is true of devfs. It was designed for dynamic
major/minors, and the static ones were for backward compatibility with static
/devs.

>    4) devfs does provide a deamon that userspace programs can hook into
>       to listen to see what devices are being created or removed.

How is that a problem?

>  Constraints:
>    1) devfs forces the devfs naming policy into the kernel.  If you
>       don't like this naming scheme, tough.

Not true at all. If you don't like the naming scheme, run devfsd. Just
like running udev, only unlike udev at least you have device files even
if the daemon's not running.

>    2) devfs does not follow the LSB device naming standard.

No, but the userspace daemon attached to it could do so, just like udev.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 09:46:04AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 09:25:52AM -0800, Greg KH wrote:
> > No that is not what sysfs is about at all.  sysfs exports the internal
> > device tree that the kernel knows so that userspace can use this
> > information for all sorts of different things (proper power management,
> > etc.)  Please go read all of the sysfs and driver model documentation
> > (and OLS and linux.conf.au papers) for more details about what sysfs and
> > the driver core is all about.
> 
> I think you still misunderstand what I'm saying. All I'm saying is that
> with either way, kernel is exporting three pieces of information (b/c,
> major, minor) to userspace through file(s) on an artificial filesystem.

No, that is not true.  devfs exports the device node itself.  It does
not just export the major:minor number.  devfs also does not export the
position within the entire device tree, which sysfs does.  

They are two completely different filesystems, doing two completely
different things.  Please do not confuse them.

> That's it. I know what sysfs is for, I like sysfs the way it is, I'm not
> saying sysfs should be changed in any way. I'm saying that to create a
> device with a given name, udev uses magic files exported by the kernel,
> and devfsd uses magic file(s) exported by the kernel, and in both cases
> they contain the same information. And hence in that sense devfs and
> udev are the same. That's it.

But the main point is that udev is in userspace, and devfs is in the
kernel.  You forgot that :)

> What I'm trying to explain by that point is that udev is no more "naming
> policy in the kernel" free than devfsd. devfsd relies on devfs, which
> has naming policy in the kernel. udev relies on sysfs, which has naming
> policy in the kernel. While devfs and sysfs are radically different,
> they serve the same purpose for devfsd/udev.

sysfs has no such "naming policy".  It merely exports the name that the
kernel happened to give the device, using the LSB naming scheme.  It
does not rely on driver substems to create subdirectories for their
devices, nor export their own nested naming schemes.

sysfs merely exports the info that the kernel knows about a device, by
which udev creates a device node.

devfs exports the device node, and then lets devfsd override that node
and create other stuff.

Please also do not overlook the fragility of the devfs->devfsd
interface.  It is binary, relies on 1 sender and 1 receiver, and doesn't
allow any other programs to get this info.

udev uses the hotplug interface, a well documented, ascii interface that
anyone can hook into by merely dropping a symlink into a subdirectory.

Vastly different.

> > And claiming udev as "a sort of ugly-hack devfsd" is pretty harsh.
> > Given that udev uses a documented, open interface, and easily allows
> > _any_ program to run from it, no matter what the language.  Try reading
> > the devfsd code some time, or getting it to run your perl script to name
> > a single type of device :)
> 
> That's something udev does pretty well, and not quite what I meant. I
> like devfs, defined for the time being as a working tree of device files
> exported by the kernel as a virtual filesystem. For managing
> permissions, user-space-dictated device names, and whatever else, I
> don't care if you call it devfsd or udev or whatever else. I don't like
> udev primarily because it tries to do the job without the help of a
> devfs, and I think trying to do that makes it ugly.

But the point is that udev does not require such a interface as devfs to
get the job done.  devfsd does.

> > If you like devfs, fine, use it.  If you don't, take a look at udev.
> 
> Which was the point of my email. "Hey, I like devfs over udev. Am I
> alone in this, or are there others?" As I stated at the start.

Providing specific examples of what you find lacking in udev would be
constructive.  Saying, "I don't like it as it doesn't feel right to me"
is merely wanting to pick a fight.

I'm done with this thread,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

ugh, and here I said I wouldn't respond.  But to be fair, he wrote me
this before I said that...

On Tue, Feb 10, 2004 at 09:55:49AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 09:01:57AM -0800, Greg KH wrote:
> > Did you read:
> > 	http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
> 
> While we're at it...
> 
> >  Problems:
> >    1) devfs only shows the dev entries for the devices in the system.
> 
> Why is that a bad thing? Why should I want to see dev entries for firewire
> drives on my 486 or LPT1 on my legacy-free laptop? 

No, I'm saying that devfs does solve this problem.  Quite well in fact.

> >    2) devfs does not handle the need for dynamic major/minor numbers
> 
> It does as well as udev does. You say it yourself, "if the kernel switches to
> dynamic major/minor". The same is true of devfs. It was designed for dynamic
> major/minors, and the static ones were for backward compatibility with static
> /devs.

But devfs never used the dynamic major/minor code.  No one used it.
It's not even present anymore in 2.6.  That shows that devfs does not
solve this problem by itself.

> >    4) devfs does provide a deamon that userspace programs can hook into
> >       to listen to see what devices are being created or removed.
> 
> How is that a problem?

It isn't.  It's saying that devfs does do this.

> >  Constraints:
> >    1) devfs forces the devfs naming policy into the kernel.  If you
> >       don't like this naming scheme, tough.
> 
> Not true at all. If you don't like the naming scheme, run devfsd. Just
> like running udev, only unlike udev at least you have device files even
> if the daemon's not running.

Heh, you haven't ever converted a driver to use devfs have you?  If so,
you would have seen the fact that you had to specify your devfs name in
the driver interface.  That's hard coding the naming scheme in the
kernel.

And how flexible does devfsd allow you to specify your own naming
scheme?  How can you get the info from devfsd that you need to provide a
proper device name?  No one I know has ever does this.  And I know some
people who tried real hard...

> >    2) devfs does not follow the LSB device naming standard.
> 
> No, but the userspace daemon attached to it could do so, just like udev.

But it doesn't.  That was the point.

udev defaults to this.  Which is the sane thing to do.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 10:12:42AM -0800, Greg KH wrote:
> No, that is not true.  devfs exports the device node itself.  It does
> not just export the major:minor number.

That's a pretty minor difference, from the kernel's point of view. It's
basically putting the same numbers in different fields.

> devfs also does not export the position within the entire device tree,
> which sysfs does.  

devfs tried to do just that. sysfs does it better though. I don't see
what that has to do with my point.

> They are two completely different filesystems, doing two completely
> different things.  Please do not confuse them.

sysfs and devfs are very different. I said they both accomplish one
common goal, sysfs for udev and devfs for devfsd.

> But the main point is that udev is in userspace, and devfs is in the
> kernel.  You forgot that :)

No I didn't. udev is userspace, devfsd is userspace. devfs is kernel
space, sysfs is kernel space. They're the same.

> sysfs has no such "naming policy".  It merely exports the name that the
> kernel happened to give the device, using the LSB naming scheme.  It
> does not rely on driver substems to create subdirectories for their
> devices, nor export their own nested naming schemes.

But sysfs is still setting naming policy in the kernel. Because you
didn't write the kernelspace static names in question, they don't exist?

> sysfs merely exports the info that the kernel knows about a device, by
> which udev creates a device node.

devfs merely exports information the kernel knows, by which devfsd can
create device nodes.

> devfs exports the device node, and then lets devfsd override that node
> and create other stuff.

And sysfs exports files that are (from a kernel point of view) very
nearly a device node.

> Please also do not overlook the fragility of the devfs->devfsd
> interface.  It is binary, relies on 1 sender and 1 receiver, and doesn't
> allow any other programs to get this info.

Didn't say the current devfs was a good implementation of the concept.
Said I liked a devfs-like concept.

> But the point is that udev does not require such a interface as devfs to
> get the job done.  devfsd does.

Yes it does, it requires sysfs.

> Providing specific examples of what you find lacking in udev would be
> constructive.  Saying, "I don't like it as it doesn't feel right to me"
> is merely wanting to pick a fight.

udev tries to do the job without a devfs. I said that already. I think
there should be a kernel exported filesystem with kernel-created device
nodes, and that udev's role should continue to do something similar to what it
does now (manage permissions and user-supplied names), only on that
kernel-exported filesystem.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 03:34:18AM -0800, Mike Bell wrote:
> I've been reading a lot lately about udev and how it's both very
> different to and much better than devfs, and with _most_ of the reasons
> given, I can't see how either is the case. I'd like to lay out why I
> think that is.

One final comment:  Can you implement a persistent device naming scheme
using devfs today?  If so, please show me how you would:
	- always name a USB printer the same /dev name no matter when it
	  is discovered by the USB core (before or after any other USB
	  printer.)
	- always name your SCSI disk the same /dev name no matter where
	  in the scsi probe sequence it is (yank it out and plug it into
	  another place in your scsi rack.)

This is the main problem that udev solves.  The fact that it also gives
you a dynamic /dev is just extra goodness.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 10:19:32AM -0800, Greg KH wrote:
> But devfs never used the dynamic major/minor code.  No one used it.
> It's not even present anymore in 2.6.  That shows that devfs does not
> solve this problem by itself.

Does udev solve this problem by itself? :) No, it is just agnostic to
the change being made in the kernel. Pretty much the same way devfsd
would be.

> Heh, you haven't ever converted a driver to use devfs have you?  If so,
> you would have seen the fact that you had to specify your devfs name in
> the driver interface.  That's hard coding the naming scheme in the
> kernel.

It's hard coding _a_ name in the kernel. And what's bad about having a 
constant name for the device, if the user can have their own alternate
names? If you ask me, that's many times BETTER than having every
system use totally different names for every device with no way to
predictably find a device by name. At least with devfs I know that
/dev/input/mice will be named /dev/input/mice. This "no policy in kernel
space" you claim as a benefit really amounts to "/dev/input/mice could
be named anything at all". The default config may have a predictable LSB
type name, but what you're talking about isn't the flexibility to have
it named anything you want, but the flexibility NOT to have an
alternate, predictable name as well. Why is that a good thing?

> And how flexible does devfsd allow you to specify your own naming
> scheme?  How can you get the info from devfsd that you need to provide a
> proper device name?  No one I know has ever does this.  And I know some
> people who tried real hard...

That's a valid point against the existing devfs/devfsd, there are a few
of those (the races, for instance). But it's not inherent to the idea of
a devfs.

> udev defaults to this.  Which is the sane thing to do.

I don't know about that. from what I remember of the original devfs
discussion, it was along the lines of "LSB involves every device in
/dev, and is dumb.  We need a new scheme, this is as good as any. Anyone
who has a better idea for how devices should be laid out, let me know."

Re: devfs vs udev, thoughts from a devfs user

[Shawn]

You know better than to say you're done. I've run out of fingers and
toes trying to count the number of times you've tried to say that.

Sadly, there are those that will stir things up enough to get a
response.

I think it's because you're very helpful and actually want to improve
things and know how maybe?

On Tue, 2004-02-10 at 11:25, Greg KH wrote:
> Anyway, I'm done with this devfs vs. udev arguments that in the end go
> nowhere.  See that document for my position.

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 10:19:32AM -0800, Greg KH wrote:
> ugh, and here I said I wouldn't respond.  But to be fair, he wrote me
> this before I said that...

Also, since it's not intended to be a personal attack but rather an
attempt to find the truth, whether you personally want to respond or not
I'd still like to respond to the claims you made with why I think
they're wrong.

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 12:52:51PM -0500, Chris Friesen wrote:
> What names would you use for your device files?  This is the key 
> difference.  With udev it gets a notification that says "I have a new 
> block device", it then looks it up, applies the rules, and creates a new 
> entry.  The whole point is to move the naming scheme into userspace for 
> easier management.

Why does it make management easier to have no predictable name for a
device?

> You could have the kernel export a simple devfs with a hardcoded naming 
> scheme based on similar ideas as what is in sysfs (which would then make 
> sysfs and the daemon optional for tiny embedded setups), but the only 
> advantage over just exporting the information in sysfs is to save a few 
> bytes at the cost of yet another filesystem to maintain.

I think the space savings are a pretty good reason alone. Add to that
the fact I think devfs would be a good idea even if it cost MORE
memory... You can mount a devfs on your RO root instead of needing to
mount a tmpfs on /dev and then run udev on that. A devfs gives
consistant names for devices in addition to the user's preferred
user-space dictated naming scheme. A devfs means even with dynamic
majors/minors, even if you have new hardware in your system, your /dev
at least has the devices it needs.

Re: devfs vs udev, thoughts from a devfs user

[Chris Friesen]

Mike Bell wrote:

> Why does it make management easier to have no predictable name for a
> device?

I believe this is a misconception.

Udev uses standard rules by default.  If the end-user (or their distro) 
wants to add additional rules or override these rules, they can do that.

> I think the space savings are a pretty good reason alone. Add to that
> the fact I think devfs would be a good idea even if it cost MORE
> memory... You can mount a devfs on your RO root instead of needing to
> mount a tmpfs on /dev and then run udev on that.

Don't you have to explicitly mount /dev as type devfs?  How is this 
different than mounting it as tmpfs?

> A devfs gives
> consistant names for devices in addition to the user's preferred
> user-space dictated naming scheme. 

Udev gives consistant names unless you explicitly override it.

> A devfs means even with dynamic
> majors/minors, even if you have new hardware in your system, your /dev
> at least has the devices it needs.

So does udev.

The real gain with devfs is that you don't need to have any userspace 
intervention to get /dev/ populated with a baseline set of device nodes. 
  As long as the udev code is sufficiently robust and compact, I don't 
have a problem with needing a userspace daemon.  Anyone that *really* 
cares about compactness (embedded people, for instance) is going to use 
a static /dev tree pruned down to the bare minimum.  For everyone else, 
the overhead of having udev running should be unnoticeable.

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: devfs vs udev, thoughts from a devfs user

[Tomasz Torcz]

On Tue, Feb 10, 2004 at 02:46:16PM -0500, Chris Friesen wrote:
> >I think the space savings are a pretty good reason alone. Add to that
> >the fact I think devfs would be a good idea even if it cost MORE
> >memory... You can mount a devfs on your RO root instead of needing to
> >mount a tmpfs on /dev and then run udev on that.
> 
> Don't you have to explicitly mount /dev as type devfs?  How is this 
> different than mounting it as tmpfs?

 There is one magic option in kernel config, which mounts devfs 
automatically at boot.

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu@irc.-nie.spam-.pl   one blends softly casual into the other. 
|> Playing: Anathema - Pressure ...

Re: devfs vs udev, thoughts from a devfs user

[Theodore Ts'o]

On Tue, Feb 10, 2004 at 10:43:03AM -0800, Mike Bell wrote:
> That's a valid point against the existing devfs/devfsd, there are a few
> of those (the races, for instance). But it's not inherent to the idea of
> a devfs.

At least some races are inherent to the idea of having a filesystem
which is mounted on /dev.  At some level, this seems to be your main
complaint to the udev/sysfs combination --- that you cannot mount some
particular magic filesystem on top of /dev.  But think about it.  If
you are having the kernel specify a specific name, and then allow
devfsd program to override it (but have it magically appear in /dev if
devfsd is not running) it is very hard to avoid the races, and it
certainly makes it hard to do anything other than the one sender, one
receiver model.

If instead you have a filesystem which fundamentally must be mounted
somewhere else, such that there is no question that it can't be
mounted on /dev, and you have a notifer which tells you what's going
on --- well, you have the udev/sysfs combination.  

You could pontentially do this if you mount the devfs filesystem on
/devfs, but as near as I can tell, that was just a stalking horse by
the devfs folks who tried to be all things to all people.  If you're
going to mount devfs on /devfs, then udev/sysfs does a better job,
because that's what it's designed to do.

> > udev defaults to this.  Which is the sane thing to do.
> 
> I don't know about that. from what I remember of the original devfs
> discussion, it was along the lines of "LSB involves every device in
> /dev, and is dumb.  We need a new scheme, this is as good as any. Anyone
> who has a better idea for how devices should be laid out, let me know."

What udev defaults to is making the namespace be controlled strictly
by the userspace.  (i.e., the mount devfs on /devfs approach).  

As far as putting everything device name in a single directory, that
doesn't happen in /sysfs, since the filesystem tree reflects the
system's device tree.  And in terms of where to put the devices in
/dev, in udev that's strictly a userpsace issue --- which is where it
should be.


						- Ted

Re: devfs vs udev, thoughts from a devfs user

[Kevin P. Fleming]

Chris Friesen wrote:

> Don't you have to explicitly mount /dev as type devfs?  How is this 
> different than mounting it as tmpfs?

devfs is "single-instance": it can be mounted during initrd/initramfs 
processing, then remounted after pivot_root without losing its contents

Granted, I'm sure someone can come up with a single-instance ramfs 
filesystem that can be used for udev, but today it does not exist.

Re: devfs vs udev, thoughts from a devfs user

[Timothy Miller]

Please forgive me for stepping into this conversation so late...

Mike Bell wrote:
> On Tue, Feb 10, 2004 at 12:52:51PM -0500, Chris Friesen wrote:
> 
>>What names would you use for your device files?  This is the key 
>>difference.  With udev it gets a notification that says "I have a new 
>>block device", it then looks it up, applies the rules, and creates a new 
>>entry.  The whole point is to move the naming scheme into userspace for 
>>easier management.
> 
> 
> Why does it make management easier to have no predictable name for a
> device?
> 

What's unpredictable about it?  udev can apply exactly the same rules 
that devfs uses, thereby coming up with the same names.  In that limited 
case, the advantage to udev is to move code out of the kernel.  Not only 
does that shrink the kernel, but it moves policy that affects user space 
into user space.

If udev had a "devfs" mode where it used a ramdisk for device nodes, and 
it produced exactly the same names as devfs, would you be happy with it?

Any device node you needed would have been generated well before you 
needed it, and being a filesystem node, it's no slower to actually USE 
the device than devfs, and you'd get all the same behavior you had 
before.  The ONLY difference is that the code isn't in the kernel.

You have the further advantage, for the embedded people, that you can 
eliminate udev, and create static device nodes, without having to modify 
the kernel in any way.

For the typical case, udev COULD produce the same device names as devfs, 
completely addressing your "predictability" issue.  It would be 
PERFECTLY predictable.  But it has the additional advantage of being 
able to keep a database in a file that it uses to also make device names 
CONSISTENT.  Thus, if you attach a USB device and then remove it and 
then attach it again later, udev has a simple way to compare that device 
against its history of known devices and give that device again exactly 
the same name.  Can devfs do that?  If so, where does it keep its history?


> 
>>You could have the kernel export a simple devfs with a hardcoded naming 
>>scheme based on similar ideas as what is in sysfs (which would then make 
>>sysfs and the daemon optional for tiny embedded setups), but the only 
>>advantage over just exporting the information in sysfs is to save a few 
>>bytes at the cost of yet another filesystem to maintain.
> 
> 
> I think the space savings are a pretty good reason alone. Add to that
> the fact I think devfs would be a good idea even if it cost MORE
> memory... You can mount a devfs on your RO root instead of needing to
> mount a tmpfs on /dev and then run udev on that. A devfs gives
> consistant names for devices in addition to the user's preferred
> user-space dictated naming scheme. A devfs means even with dynamic
> majors/minors, even if you have new hardware in your system, your /dev
> at least has the devices it needs.

How does devfs save space?  Device node information has to be stores 
SOMEWHERE.  Whether that's in filesystem nodes or in datastructures in 
the kernel that are dynamically made to LOOK like device nodes, you 
still need to take up memory.

As for dynamic major/minor numbers, I'm not sure how udev precludes 
that.  The fact that udev might keep minor numbers from changing over a 
reboot doesn't matter.  Dynamic major/minor numbers just means that they 
can be arbitrary.

Re: devfs vs udev, thoughts from a devfs user

[Diego Calleja García]

El Tue, 10 Feb 2004 14:46:16 -0500 Chris Friesen <cfriesen@nortelnetworks.com> escribió:

> Mike Bell wrote:
> 
> > Why does it make management easier to have no predictable name for a
> > device?
> 
> I believe this is a misconception.
> 
> Udev uses standard rules by default.  If the end-user (or their distro) 
> wants to add additional rules or override these rules, they can do that.

It even communicate the addition/removal of devices to userspace applications
through DBUS (freedesktop.org standard that will be adopted by kde,
gnome, etc - ie: useful stuff). So you don't even need to know the device names: 
the application will receive the notificacion.

Of course, this is doable with devfs. But it's been done already, in a
*much* cleaner way, with udev. So why bother, I wonder...

Re: devfs vs udev, thoughts from a devfs user

[Bill Rugolsky Jr.]

On Tue, Feb 10, 2004 at 01:11:36PM -0700, Kevin P. Fleming wrote:
> devfs is "single-instance": it can be mounted during initrd/initramfs 
> processing, then remounted after pivot_root without losing its contents
> 
> Granted, I'm sure someone can come up with a single-instance ramfs 
> filesystem that can be used for udev, but today it does not exist.
 
mount --move olddir newdir

Regards,

	Bill Rugolsky

Re: devfs vs udev, thoughts from a devfs user

[Valdis.Kletnieks]

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

On Tue, 10 Feb 2004 11:24:57 PST, Mike Bell said:

> I think the space savings are a pretty good reason alone. Add to that
> the fact I think devfs would be a good idea even if it cost MORE
> memory... You can mount a devfs on your RO root instead of needing to
> mount a tmpfs on /dev and then run udev on that.

(As an aside, the original reason I started using devfs was because it created
a separate /dev filesystem, and / can be mounted 'nodev'.  But I don't have any
religious preference for mounting devfs-by-kernel or tmpfs-from-initrd).

On the flip side, udev gives me something that devfs *cant* without major
hacking - the ability to attach extended attributes/labels to the device when
it gets created, so things like SELinux can deal with them. (OK, so I admit I'm
still sorting out how to use the SElinux transition SID support for tmpfs ;)



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

Re: devfs vs udev, thoughts from a devfs user

[Matthew Reppert]

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

As always, not flaming ...

On Tue, 2004-02-10 at 12:29, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 10:12:42AM -0800, Greg KH wrote:
> >
> > devfs also does not export the position within the entire device tree,
> > which sysfs does.  
> 
> devfs tried to do just that. sysfs does it better though. I don't see
> what that has to do with my point.

The point is illustrating differences between devfs and sysfs, since you
seem to be saying "they do the same thing" over and over, when really, they
don't.

> > But the main point is that udev is in userspace, and devfs is in the
> > kernel.  You forgot that :)
> 
> No I didn't. udev is userspace, devfsd is userspace. devfs is kernel
> space, sysfs is kernel space. They're the same.

At the very least, sysfs' and devfs' approaches to devices differ in
philosophy. devfs says "here's a device node, you can tell where it is
in the bus hierarchy by looking at its filename". sysfs, on the other
hand, says "here's the device hierarchy", and gives you enough information
to create device nodes for each point in the hierarchy if you wish to do
so.

> > sysfs has no such "naming policy".  It merely exports the name that the
> > kernel happened to give the device, using the LSB naming scheme.  It
> > does not rely on driver substems to create subdirectories for their
> > devices, nor export their own nested naming schemes.
> 
> But sysfs is still setting naming policy in the kernel. Because you
> didn't write the kernelspace static names in question, they don't exist?

This is kind of like saying "bzImage sets root partition location policy
because it uses whatever was the root partition when you made the image".
Which is bogus, that's what root= is for.

sysfs is in no way setting naming policy by exporting the LSB naming scheme.
First of all, sysfs isn't even creating the device nodes - that, of course,
is udev's (or whatever else you might want to use) job. You're right,
actually - if you're using udev, files the sysfs static names *don't* exist -
*unless* your udev is configured to use them. If not, then obviously the
sysfs names don't matter at all.

> > sysfs merely exports the info that the kernel knows about a device, by
> > which udev creates a device node.
> 
> devfs merely exports information the kernel knows, by which devfsd can
> create device nodes.

As I understand it, devfs actually creates device nodes, but devfsd can
request that the names be changed. (Granted, my understanding of the Linux
devfs implementation is far from complete.) "Exporting the information into
device nodes" is kind of silly to claim as a minimal exercise, when creating
the device nodes is the end goal of the software.

> > devfs exports the device node, and then lets devfsd override that node
> > and create other stuff.
> 
> And sysfs exports files that are (from a kernel point of view) very
> nearly a device node.

This is like arguing that a file named foo with an accompanying file named
foo.acl is "very nearly" a file with an ACL. Or, more dramatically, like
equating a nuclear warhead with instructions on making U-238. The information
is there in sysfs, granted, but it's not in a directly usable form by itself.

> > But the point is that udev does not require such a interface as devfs to
> > get the job done.  devfsd does.
> 
> Yes it does, it requires sysfs.

ps requires /proc :3

The difference between sysfs and devfs, in this regard, is fairly simple. By
just turning on devfs support, you've suddenly changed the behaviour of the
system (device node creation and naming) once /dev is mounted. By turning on
sysfs, the behaviour of the system doesn't change at all, even when /sys is
mounted.

> > Providing specific examples of what you find lacking in udev would be
> > constructive.  Saying, "I don't like it as it doesn't feel right to me"
> > is merely wanting to pick a fight.
> 
> udev tries to do the job without a devfs. I said that already. I think
> there should be a kernel exported filesystem with kernel-created device
> nodes,

Why should the kernel create the device nodes? Sure, it's "just an extra
step", but the general Linux philosophy is that "just extra steps" don't
belong inside the kernel. Why should the kernel do more work?

Matt

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

Re: devfs vs udev, thoughts from a devfs user

[Matthew Reppert]

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

On Tue, 2004-02-10 at 14:15, Timothy Miller wrote:
>
> If udev had a "devfs" mode where it used a ramdisk for device nodes, and 
> it produced exactly the same names as devfs, would you be happy with it?

udev ships with several sets of device naming rules, one of which is
meant to create devfs-like names. etc/udev/udev.rules.devfs in the udev
distribution.

Matt

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

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 04:19:28PM -0600, Matthew Reppert wrote:
> At the very least, sysfs' and devfs' approaches to devices differ in
> philosophy. devfs says "here's a device node, you can tell where it is
> in the bus hierarchy by looking at its filename". sysfs, on the other
> hand, says "here's the device hierarchy", and gives you enough information
> to create device nodes for each point in the hierarchy if you wish to do
> so.

I don't see how that is the case. devfs doesn't do anywhere near as good
a job exporting info about the system's state as sysfs, wouldn't dream
of disputing that. But to me, /dev/scsi/host0/bus0/target0/lun0/disc and
/sys/bus/scsi/drivers/sd/0:0:0:0/block/dev are the same philosophy.

> This is kind of like saying "bzImage sets root partition location policy
> because it uses whatever was the root partition when you made the image".
> Which is bogus, that's what root= is for.

No, that's not what I mean at all.

> sysfs is in no way setting naming policy by exporting the LSB naming scheme.
> First of all, sysfs isn't even creating the device nodes - that, of course,
> is udev's (or whatever else you might want to use) job. You're right,
> actually - if you're using udev, files the sysfs static names *don't* exist -
> *unless* your udev is configured to use them. If not, then obviously the
> sysfs names don't matter at all.

No no, I'm not saying sysfs is setting /dev's naming policy. I'm saying
that no one is ranting and raving about how userspace should be able to
change the names of sysfs files using a userspace daemon. devfs
specifies a path in the kernel, 

> This is like arguing that a file named foo with an accompanying file named
> foo.acl is "very nearly" a file with an ACL. Or, more dramatically, like
> equating a nuclear warhead with instructions on making U-238. The information
> is there in sysfs, granted, but it's not in a directly usable form by itself.

So how is that better? :) Not that I'm suggesting sysfs should have
device files in it, but why is it a winning point for sysfs to be able
to say "hey, look, I don't export a device file, but a file which
carries exactly the same information but with less utility, since you
have to use that information to create ANOTHER file".

My point was that both filesystems are exporting that information to
userspace, at least devfs does it in a way where the product is useful
with or without a userspace daemon.

> The difference between sysfs and devfs, in this regard, is fairly simple. By
> just turning on devfs support, you've suddenly changed the behaviour of the
> system (device node creation and naming) once /dev is mounted. By turning on
> sysfs, the behaviour of the system doesn't change at all, even when /sys is
> mounted.

But I wasn't arguing they weren't different, I was arguing that they
both have naming policy in the kernel. As long as the user can specify
their own names as well, why is it "naming policy in the kernel" to
specify a hardcoded path in /dev, but not if you specify a hardcoded
path in /sys?

> Why should the kernel create the device nodes? Sure, it's "just an extra
> step", but the general Linux philosophy is that "just extra steps" don't
> belong inside the kernel. Why should the kernel do more work?

Not even an extra step, more a different step. Not "more" work, the same
work in a different way. And it should because then you have a working
/dev with guaranteed names.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 03:39:00PM -0500, Bill Rugolsky Jr. wrote:
> On Tue, Feb 10, 2004 at 01:11:36PM -0700, Kevin P. Fleming wrote:
> > devfs is "single-instance": it can be mounted during initrd/initramfs 
> > processing, then remounted after pivot_root without losing its contents
> > 
> > Granted, I'm sure someone can come up with a single-instance ramfs 
> > filesystem that can be used for udev, but today it does not exist.
>  
> mount --move olddir newdir

Doesn't work for what we want here:

	$ mkdir /tmp/a /tmp/b
	$ mount -t ramfs none /tmp/a
	$ touch /tmp/a/foo
	$ mount --move /tmp/a /tmp/b
	$ ls /tmp/b
	foo
	$ umount /tmp/a
	$ ls /tmp/b
	$ 

Hm, not nice :(

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 02:46:16PM -0500, Chris Friesen wrote:
> I believe this is a misconception.
> 
> Udev uses standard rules by default.  If the end-user (or their distro) 
> wants to add additional rules or override these rules, they can do that.

Right, but why is "override" better than "in addition to" in this case?
With the in addition case, any linux system at least has the
predictable, kernel-generated name, and any app can rely on that name
being the same on. If the user doesn't like it, he/she is free to make
another one, but the old one's still there.

udev's additional flexibility over devfs with regard to naming seems to
boil down to that, udev is instead of, devfs is in addition to. Why is
instead of better? 

There's space savings, but a simpler devfs might actually be more RAM
efficient than using the generic tmpfs with device nodes on it. And
there's the cleanliness of not having unused device nodes around, but
those unused device nodes guarantee that no matter what crazy naming
scheme you personally like for your devices, they're still findable the
old fashioned way too.

Re: devfs vs udev, thoughts from a devfs user

[Ian Kent]

On Tue, 10 Feb 2004, Greg KH wrote:

> On Tue, Feb 10, 2004 at 03:34:18AM -0800, Mike Bell wrote:
> > I've been reading a lot lately about udev and how it's both very
> > different to and much better than devfs, and with _most_ of the reasons
> > given, I can't see how either is the case. I'd like to lay out why I
> > think that is.
> 
> One final comment:  Can you implement a persistent device naming scheme
> using devfs today?  If so, please show me how you would:
> 	- always name a USB printer the same /dev name no matter when it
> 	  is discovered by the USB core (before or after any other USB
> 	  printer.)
> 	- always name your SCSI disk the same /dev name no matter where
> 	  in the scsi probe sequence it is (yank it out and plug it into
> 	  another place in your scsi rack.)
> 
> This is the main problem that udev solves.  The fact that it also gives
> you a dynamic /dev is just extra goodness.

In his final comment, inocently, he makes the big point.

This a huge deal.

Ian

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 03:15:39PM -0500, Timothy Miller wrote:
> What's unpredictable about it?  udev can apply exactly the same rules 
> that devfs uses, thereby coming up with the same names.  In that limited 
> case, the advantage to udev is to move code out of the kernel.  Not only 
> does that shrink the kernel, but it moves policy that affects user space 
> into user space.

But you're still relying on sysfs. You're not shrinking the kernel,
you're moving the resource usage to a different filesystem which is new
and thus doesn't have people who feel strongly about how the files in it
should be named.


> If udev had a "devfs" mode where it used a ramdisk for device nodes, and 
> it produced exactly the same names as devfs, would you be happy with it?

No, as I already said, udev on a tmpfs would not be enough for me. Or at
least that's the opinion I have now, it seems pretty much everyone loves
udev, so it may well become The Way to do things on linux, at which
point I may not have a choice but to grow to love it. :)

> You have the further advantage, for the embedded people, that you can 
> eliminate udev, and create static device nodes, without having to modify 
> the kernel in any way.

But the old devfs argument was that devfs actually takes LESS flash than
a static /dev. Even the udev author says it was good for embedded
people.

> For the typical case, udev COULD produce the same device names as devfs, 
> completely addressing your "predictability" issue.  It would be 
> PERFECTLY predictable.

No, because I'm saying that udev's fundamental philosophy seems to be
"instead of", when it talks about giving the user more choice than
devfs, it's talking about the freedom to have different names INSTEAD OF
the ones everyone else has. It doesn't matter what layout those names
have, devfs-style or LFS-style or whatever, the point is that the
devfs-style "in addition to" userspace daemon means you've always got
predictable names for device files there as well.

I'm not saying that's a big win for devfs, or that it couldn't be done
in userspace. I'm asking why people keep talking about that as if it was
a win for udev? Why is that a good thing? Because that's the difference
between a devfsd and a udev, both can create whatever crazy naming
scheme you want, completely in user space. But the devfsd relies on the
paths to kernel-generated device files, while udev relies on the paths
to kernel-generated text files in a different tree.

> Can devfs do that?  If so, where does it keep its history?

With devfsd. In userspace, the same place as udev. 

> How does devfs save space?  Device node information has to be stores 
> SOMEWHERE.  Whether that's in filesystem nodes or in datastructures in 
> the kernel that are dynamically made to LOOK like device nodes, you 
> still need to take up memory.

But a filesystem that is able to support the creation of a file
up to ssize_t, loopback mounting, maximum "disc" space usage and other
accounting stuff (tmpfs) is presumably more space inefficient than one
that just has to support devices, symlinks and fifos, all of which have
tiny metadata and don't need associated "blocks" to store their data.

Re: devfs vs udev, thoughts from a devfs user

[Kevin P. Fleming]

Greg KH wrote:

> Doesn't work for what we want here:
> 
> 	$ mkdir /tmp/a /tmp/b
> 	$ mount -t ramfs none /tmp/a
> 	$ touch /tmp/a/foo
> 	$ mount --move /tmp/a /tmp/b
> 	$ ls /tmp/b
> 	foo
> 	$ umount /tmp/a
> 	$ ls /tmp/b
> 	$ 

That seems very odd, the "umount /tmp/a" should have failed, given than 
nothing is mounted there any longer.

Also, what will happen if something on the filesystem on /tmp/a is open 
(say, /dev/console)? I was thinking that this process might work better:

$ mkdir /tmp/a /tmp/b
$ mount -t ramfs test /tmp/a
$ touch /tmp/a/foo
$ mount --bind /tmp/a /tmp/b
$ ls /tmp/b
foo
$ umount /tmp/a
$ ls /tmp/b
foo


And it does. In fact, it seems to work fine as long as no files are open 
on the ramfs when the umount is executed (otherwise -EBUSY).

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Tue, Feb 10, 2004 at 03:11:19PM -0500, Theodore Ts'o wrote:
> At least some races are inherent to the idea of having a filesystem
> which is mounted on /dev.  At some level, this seems to be your main
> complaint to the udev/sysfs combination --- that you cannot mount some
> particular magic filesystem on top of /dev.  But think about it.  If
> you are having the kernel specify a specific name, and then allow
> devfsd program to override it (but have it magically appear in /dev if
> devfsd is not running) it is very hard to avoid the races, and it
> certainly makes it hard to do anything other than the one sender, one
> receiver model.

OK, but I wasn't talking about overriding. In fact, I was taking it as
read that the devfs-type solution can't override (which it sort of
COULD, but as you say it has races) but would instead have its userspace
daemon create nodes _in addition to_ the kernel created ones, based on
user policy. Or symlinks, whatever the user space daemon wants.

> If instead you have a filesystem which fundamentally must be mounted
> somewhere else, such that there is no question that it can't be
> mounted on /dev, and you have a notifer which tells you what's going
> on --- well, you have the udev/sysfs combination.  

Agreed. 

> You could pontentially do this if you mount the devfs filesystem on
> /devfs, but as near as I can tell, that was just a stalking horse by
> the devfs folks who tried to be all things to all people.  If you're
> going to mount devfs on /devfs, then udev/sysfs does a better job,
> because that's what it's designed to do.

Yes, agreed. If anything, that was one of the points I was trying to
make, that udev/sysfs is similar in concept to devfsd with devfs mounted
somewhere other than /dev (please nobody tell me how sysfs and devfs are
different, I know. I meant for the purposes of the udev/devfs user space
programs, they're fulfiling the same purpose. Getting a major and minor
from the kernel to the userspace daemon by creating a file on a
kernel-generated filesystem.)

What I would like to see is a kernel generated /dev with
kernel-specified paths. A userspace daemon, whether you call it udev or
devfsd, would then manage alternate (in addition to, not instead of)
naming schemes according to the sysadmin's whim and permissions of
device nodes and other things that just don't make sense to do in kernel
space.

Re: devfs vs udev, thoughts from a devfs user

[viro]

On Tue, Feb 10, 2004 at 05:16:00PM -0800, Greg KH wrote:
> On Tue, Feb 10, 2004 at 03:39:00PM -0500, Bill Rugolsky Jr. wrote:
> > On Tue, Feb 10, 2004 at 01:11:36PM -0700, Kevin P. Fleming wrote:
> > > devfs is "single-instance": it can be mounted during initrd/initramfs 
> > > processing, then remounted after pivot_root without losing its contents
> > > 
> > > Granted, I'm sure someone can come up with a single-instance ramfs 
> > > filesystem that can be used for udev, but today it does not exist.
> >  
> > mount --move olddir newdir
> 
> Doesn't work for what we want here:
> 
> 	$ mkdir /tmp/a /tmp/b
> 	$ mount -t ramfs none /tmp/a
> 	$ touch /tmp/a/foo
> 	$ mount --move /tmp/a /tmp/b
> 	$ ls /tmp/b
> 	foo
> 	$ umount /tmp/a
> 	$ ls /tmp/b
> 	$ 
> 
> Hm, not nice :(

Huh?  Is that a bug report or just your guess at what would happen if you
tried the above?

If it _does_ happen - we have a problem and I'd like to know which versions
have such bug.

Re: devfs vs udev, thoughts from a devfs user

[Maneesh Soni]

On Wed, Feb 11, 2004 at 01:59:39AM +0000, Kevin P. Fleming wrote:
> Greg KH wrote:
> 
> >Doesn't work for what we want here:
> >
> >	$ mkdir /tmp/a /tmp/b
> >	$ mount -t ramfs none /tmp/a
> >	$ touch /tmp/a/foo
> >	$ mount --move /tmp/a /tmp/b
> >	$ ls /tmp/b
> >	foo
> >	$ umount /tmp/a
> >	$ ls /tmp/b
> >	$ 
> 
> That seems very odd, the "umount /tmp/a" should have failed, given than 
> nothing is mounted there any longer.

I think there is a bug in the mount utility. /etc/mtab is not updated
correctly after "mount --move". /proc/mounts does get updated correctly.
So, if one creates /etc/mtab as sym linked with /proc/mounts, the above 
steps will correctly _fail_ "umount /tmp/a"

Maneesh

-- 
Maneesh Soni
Linux Technology Center, 
IBM Software Lab, Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044999 Fax: 91-80-5268553
T/L : 9243696

Re: devfs vs udev, thoughts from a devfs user

[Helge Hafting]

Mike Bell wrote:
> On Tue, Feb 10, 2004 at 02:20:19PM +0100, Helge Hafting wrote:
> 
>>Non-devfs setups (with or without udev) support a similiar trigger
>>mechanism for module loading, that is simpler to set up and understand.
>>And that is a persistend device node.  Plain, simple, and ls sees it too.
>>Open it and the device is loaded as needed.  And at open time, not
>>at lookup time.  Load at lookup time might not be necessary, after all.
> 
> 
> This doesn't work anymore if you move to dynamic device numbers, nor
Sure.  Completely random device numbers will make this demand loading of 
device drivers impossible. Either it won't happen (all numbers won't be 
completely random, although they may get more dynamic than today) or
module loading based on device node opening will be deprecated.

This won't mean the end of dynamic loading, you will merely need to
load modules explicit before you get a device node.  

> does it work cleanly if /dev is on tmpfs or something else that doesn't
> persist between reboots (that's one of the things I like about devfs,
> being able to use it with a RO root.)
Still possible. Boot script (possibly the udev startup script)
copies a handful of device nodes from the RO root into the tmpfs /dev.  

Helge Hafting

Re: devfs vs udev, thoughts from a devfs user

[Helge Hafting]

Matthew Reppert wrote:

> At the very least, sysfs' and devfs' approaches to devices differ in
> philosophy. devfs says "here's a device node, you can tell where it is
> in the bus hierarchy by looking at its filename". sysfs, on the other
> hand, says "here's the device hierarchy", and gives you enough information
> to create device nodes for each point in the hierarchy if you wish to do
> so.
> 
There's an interesting security implication here.  I used to think 
"why don't they make a device node instead of exporting
numbers, udev could then simply make a link to it"
It'd be simpler, and the minimalists could use the node in sysf directly.

The security advantage is that we don't get a device with some default
permissions that might get abused.  The udev config can decide
to create a node with stricter than usual permissions, or decide
to not make the node at all.

Helge Hafting

Re: devfs vs udev, thoughts from a devfs user

[Bill Rugolsky Jr.]

On Wed, Feb 11, 2004 at 07:50:49AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Tue, Feb 10, 2004 at 05:16:00PM -0800, Greg KH wrote:
> > Doesn't work for what we want here:
> > 
> > 	$ mkdir /tmp/a /tmp/b
> > 	$ mount -t ramfs none /tmp/a
> > 	$ touch /tmp/a/foo
> > 	$ mount --move /tmp/a /tmp/b
> > 	$ ls /tmp/b
> > 	foo
> > 	$ umount /tmp/a
> > 	$ ls /tmp/b
> > 	$ 
> > 
> > Hm, not nice :(
> 
> Huh?  Is that a bug report or just your guess at what would happen if you
> tried the above?
> 
> If it _does_ happen - we have a problem and I'd like to know which versions
> have such bug.

Ugh, /etc/mtab really ought to die.

Anyway, with traditional /etc/mtab, mount --move produces:

   none on /tmp/a type ramfs (rw)
   /tmp/a on /tmp/b type none (rw)

ln -sf /proc/self/mounts /etc/mtab and retry, it works fine:

   none on /tmp/b type ramfs (rw)

I'll have a look at mount later today, if nobody else gets there first.

	-Bill

[PATCH] Fix /etc/mtab updating with mount --move [was Re: devfs vs udev, thoughts from a devfs user]

[Bill Rugolsky Jr.]

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

On Wed, Feb 11, 2004 at 07:33:52AM -0500, Bill Rugolsky Jr. wrote:
> Anyway, with traditional /etc/mtab, mount --move produces:
> 
>    none on /tmp/a type ramfs (rw)
>    /tmp/a on /tmp/b type none (rw)

Andries, 

The attached patch against util-linux-2.12pre fixes /etc/mtab updating
when using mount --move.

Regards,

	Bill Rugolsky

[-- Attachment #2: util-linux-2.12pre-mountmove.patch --]
[-- Type: text/plain, Size: 934 bytes --]

--- util-linux-2.12pre/mount/fstab.c.move	2003-07-05 16:16:05.000000000 -0400
+++ util-linux-2.12pre/mount/fstab.c	2004-02-11 09:56:12.644436000 -0500
@@ -541,8 +541,12 @@
 				mc->nxt->prev = mc->prev;
 			}
 		} else {
-			/* A remount */
+			/* A remount or move */
 			mc->m.mnt_opts = instead->mnt_opts;
+			if (!streq(mc->m.mnt_dir, instead->mnt_dir)) {
+				free(mc->m.mnt_dir);
+				mc->m.mnt_dir = xstrdup(instead->mnt_dir);
+			}
 		}
 	} else if (instead) {
 		/* not found, add a new entry */
--- util-linux-2.12pre/mount/mount.c.move	2003-07-13 17:26:13.000000000 -0400
+++ util-linux-2.12pre/mount/mount.c	2004-02-11 10:03:25.754436000 -0500
@@ -635,7 +635,9 @@
 	    print_one (&mnt);
 
     if (!nomtab && mtab_is_writable()) {
-	if (flags & MS_REMOUNT)
+	if (flags & MS_MOVE)
+	    update_mtab (mnt.mnt_fsname, &mnt);
+	else if (flags & MS_REMOUNT)
 	    update_mtab (mnt.mnt_dir, &mnt);
 	else {
 	    mntFILE *mfp;

Re: devfs vs udev, thoughts from a devfs user

[dleonard]

For mount 2.12 /etc/mtab doesn't get updated correctly but umount is at least smart (or dumb) enough not to do the wrong thing.

r:dryad:/tmp# mkdir /tmp/a /tmp/b
r:dryad:/tmp# mount -t ramfs none /tmp/a
r:dryad:/tmp# touch /tmp/a/foo
r:dryad:/tmp# mount --move /tmp/a /tmp/b
r:dryad:/tmp# ls /tmp/b
foo

r:dryad:/tmp# cat /etc/mtab
/dev/hda2 / ext3 rw,errors=remount-ro 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/hda5 /usr ext3 rw 0 0
/dev/hda6 /home ext3 rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0
none /tmp/a ramfs rw 0 0
/tmp/a /tmp/b none rw 0 0

r:dryad:/tmp# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/hda5 /usr ext3 rw 0 0
/dev/hda6 /home ext3 rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0
none /tmp/b ramfs rw 0 0

r:dryad:/tmp# umount /tmp/a
umount: none: not found
umount: /tmp/a: not mounted
umount: none: not found
umount: /tmp/a: not mounted
r:dryad:/tmp# ls /tmp/b
foo

This problem *does* occur exactly as Greg says with mount 2.11n (debian) though.

-- 

<Douglas Leonard>
<dleonard@dleonard.net>

On Wed, 11 Feb 2004, Bill Rugolsky Jr. wrote:

> On Wed, Feb 11, 2004 at 07:50:49AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> > On Tue, Feb 10, 2004 at 05:16:00PM -0800, Greg KH wrote:
> > > Doesn't work for what we want here:
> > >
> > > 	$ mkdir /tmp/a /tmp/b
> > > 	$ mount -t ramfs none /tmp/a
> > > 	$ touch /tmp/a/foo
> > > 	$ mount --move /tmp/a /tmp/b
> > > 	$ ls /tmp/b
> > > 	foo
> > > 	$ umount /tmp/a
> > > 	$ ls /tmp/b
> > > 	$
> > >
> > > Hm, not nice :(
> >
> > Huh?  Is that a bug report or just your guess at what would happen if you
> > tried the above?
> >
> > If it _does_ happen - we have a problem and I'd like to know which versions
> > have such bug.
>
> Ugh, /etc/mtab really ought to die.
>
> Anyway, with traditional /etc/mtab, mount --move produces:
>
>    none on /tmp/a type ramfs (rw)
>    /tmp/a on /tmp/b type none (rw)
>
> ln -sf /proc/self/mounts /etc/mtab and retry, it works fine:
>
>    none on /tmp/b type ramfs (rw)
>
> I'll have a look at mount later today, if nobody else gets there first.
>
> 	-Bill
> -
> 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, thoughts from a devfs user

[Theodore Ts'o]

On Wed, Feb 11, 2004 at 10:44:10AM +0100, Helge Hafting wrote:
> Sure.  Completely random device numbers will make this demand loading of 
> device drivers impossible. Either it won't happen (all numbers won't be 
> completely random, although they may get more dynamic than today) or
> module loading based on device node opening will be deprecated.

It could be made to work.  You could have a magic device number, say
(255,255), which means "unloaded device driver", which causes a
hotplug callout, and a SIGSTOP sent to the process that tried the
open.  The userspace program would then be responsible for loading the
relevant device driver, converting the /dev file to the correct
dynamic major/minor number, and then sending a SIGCONT to the process,
which would then either restart the open() or the open() would return
-EAGAIN.  

It would be kinda hairy, in that the kernel would need to know whether
or not userspace had accepted responsibility for handling these calls
(if it didn't open() would just return -ENODEV as it does today).  So
it might not be worth doing, but if people really cared about it, it
could indeed be done.

					- Ted

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 11:12:34AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 10:19:32AM -0800, Greg KH wrote:
> > ugh, and here I said I wouldn't respond.  But to be fair, he wrote me
> > this before I said that...
> 
> Also, since it's not intended to be a personal attack but rather an
> attempt to find the truth, whether you personally want to respond or not
> I'd still like to respond to the claims you made with why I think
> they're wrong.

Ok, will do.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Tue, Feb 10, 2004 at 10:29:44AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 10:12:42AM -0800, Greg KH wrote:
> > No, that is not true.  devfs exports the device node itself.  It does
> > not just export the major:minor number.
> 
> That's a pretty minor difference, from the kernel's point of view. It's
> basically putting the same numbers in different fields.

Heh, that's a HUGE difference!

I think you are missing a few things here:
  - sysfs is not only for exporting device major:minor info.  It's for a
    1001 other very useful things.  You can't config out sysfs, you get
    it for "free" with 2.6.  So it isn't a "choose sysfs vs. devfs"
    argument at all.  It's a "do I want to enable devfs or not" issue.
  
 - sysfs exports loads of info about every device in your system, not
   only the major:minor info.  It exports what device this major:minor
   is assigned to, the topology of the device, the fact that it has
   vendor id FOO and product id BAR, and serial number "123".  devfs has
   none of this.

 - you get /sbin/hotplug calls for "free" too.  Yes, you can config this
   out, but the added benefits of hotplug calls far outweigh any memory
   savings you get for not enabling this option (embedded systems not
   included.)

So, if you put hotplug and sysfs together, udev can control your /dev.
And it can provide persistent device naming, which on its own, devfs can
not.

Again, the fact that udev can do everything devfs can (manage a /dev),
in userspace, and in less memory, is a big win in my eyes.

Oh, and recall that I implemented a "dynamic /dev" with LSB names almost
a year ago, in 6Kb of userspace code.  The amount of memory that this
takes for devfs to do I don't really want to imagine...

> > devfs also does not export the position within the entire device tree,
> > which sysfs does.  
> 
> devfs tried to do just that. sysfs does it better though. I don't see
> what that has to do with my point.

persistent device names...  That's the main point of udev.

> > They are two completely different filesystems, doing two completely
> > different things.  Please do not confuse them.
> 
> sysfs and devfs are very different. I said they both accomplish one
> common goal, sysfs for udev and devfs for devfsd.

Not at all.  sysfs has 1001 goals at the least.  So many different
people are using it for different things that it's really amazing to me.
It also shows how powerful and how correct the model of it is.

And as stated above, you always get sysfs in your kernel (unless you are
running the -tiny tree...)

I'm not going to try to answer all of your other questions specifically,
as I think I have covered them all now.  If you feel that you still have
some questions remaining about this, or that I have not explained
anything good enough, please let me know.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Fri, Feb 13, 2004 at 01:19:20PM -0800, Greg KH wrote:
> > That's a pretty minor difference, from the kernel's point of view. It's
> > basically putting the same numbers in different fields.
> 
> Heh, that's a HUGE difference!

Only from userspace's point of view. To the kernel, it's basically the
same thing.

Now keeping in mind again that I'm not advocating putting device nodes
into sysfs, what about a little thought experiment. Supposing you did
replace sysfs's major:minor text file with a real device node, which I
contest is basically the same thing for the kernel. You've got yourself
devfs right there. Sure, the names are unusably long for actual /dev
use, but when it comes down to it that's all it is. Your kernel now
creates all your device nodes for you automatically, just like that.

Now, here's a question. What's wrong with taking those and splitting
them into a new filesystem? As I see it, part of the reason procfs
became such a nightmare was because people thought there could be only
one kernel-generated filesystem and put everything in there. Linux
is moving a lot of the silly magic values out of proc and into sysfs
where they make more sense. Great! But what about stuff that doesn't
really fit into sysfs as it is right now? Should we take sysfs's clean
interface and extend it with special cases until it's the ugly mess proc
is? Or leave everything that doesn't fit cleanly into sysfs in proc,
making proc a sort of special-cases wasteland?

Alternativly, why not say that there doesn't need to be just one or two
kernel-exported filesystems, and instead make a sort of library for
exporting kernel information via fake filesystems (I can't remember, has
this already been done?), and make one for every purpose - that does one
thing and does it well? procfs could do processes and processes alone. A
seperate filesystem could handle sysctls, sysfs could focus on devices
and how they're attached to the system as it (mostly) does now. And then
devfs is just one more filesystem of many. I'm not a kernel hacker, but
if they all share common code so functionality isn't duplicated (ie,
procfs and sysfs and whatever else use the same mechanisms to write
stuff instead of each doing the exact same thing with their own code) I
don't see why it would neccessarily be more than a miniscule overhead,
like what's imposed by using lots of small partitions instead of one
giant /.

So yeah, that's a rather longwinded way of saying "Sure, it can be done
in sysfs. That's not the question, the question is whether sysfs is the
BEST place to do it." If elsewhere gets you more functionality, I'd say
no. It all comes down to the overhead of a new kernel filesystem versus
the benefits you get. And while the only way to really know would be to
code it, I think kernel filesystems could be made very cheap. Maybe even
resulting in a net reduction in memory use as /proc is cleaned up. So it
wouldn't take much added functionality to make it worth the while.


>  - you get /sbin/hotplug calls for "free" too.  Yes, you can config this
>    out, but the added benefits of hotplug calls far outweigh any memory
>    savings you get for not enabling this option (embedded systems not
>    included.)

How do you figure that's free? hotplug's a great feature, nothing
against it, but as far as I know the vast majority of installations
aren't making use of it right now. So how does it become free if you're
taking something that can be turned off, which you aren't using right
now, and using it for udev? I'm very confused by the way you define free
and not free, it seems to be a sort of "I like this interface, so I
would have enabled whether I was using it or not, therefore it's
effectivly free!" system. :)

> So, if you put hotplug and sysfs together, udev can control your /dev.
> And it can provide persistent device naming, which on its own, devfs can
> not.

Absolutely. But again, you're talking about udev and devfs, when you
should talk about udev and devfsd. The question isn't whether it can be
done using udev (though there are still several things a devfs can do
that to my knowledge udev can't) but whether it is the BEST way of doing
it. As I see it, whether you call it udev or devfsd it's a userspace
daemon that handles names (whether alternate or not) and permissions and
the like. The question isn't udev versus devfs, it's what is the
cleanest and best interface for this userspace daemon (which you need in
any configuration) to use to talk to the kernel? When I object to udev,
it's not to the idea of a userspace daemon that manages permissions,
I don't see how you can do away with that. It's to the way udev talks to
the kernel, and on a non-technical front the way your perceptions of
udev versus devfs result in what I see as misleading "udev versus devfs"
claims.

> Not at all.  sysfs has 1001 goals at the least.  So many different
> people are using it for different things that it's really amazing to me.
> It also shows how powerful and how correct the model of it is.

I didn't say sysfs was there only to serve udev. I said they're both
accomplishing one common goal. So what if sysfs does 1001 other things
as well? Does that mean I can tack some lame-brained extension on to
sysfs and say "hey look, you may hate what I'm doing, but sysfs does
1001 other things as well, and they're all good, therefore what I'm
doing is good as well"?

Again, I like sysfs. At least most of it, I'm a bit concerned about
stuff like /sys/power/disk and /sys/fs. That seems a lot like the thin
end of the wedge toward what /proc became. Sure, you've got the
one-value-per-file, which is a great cleanup, but if that keeps going
we may wind up with the same insane namespace pollution we've got in
/proc right now, ie we've solved only half the problem of /proc. sysfs's
core undoubtedly had the right idea though, the values in it all make
sense in how they're layed out.

> And as stated above, you always get sysfs in your kernel (unless you are
> running the -tiny tree...)

So what happens if that particular patch makes it into the mainline
kernel? To me saying sysfs is free isn't a good argument, even though I
like it and include it in all my kernels (despite the fact I don't use
udev).



On an only semi-related note, I've been thinking about the whole "naming
policy in the kernel" thing. This is only tangentally related to my
comments about udev and devfs, but I'm wondering if anyone REALLY needs
to be able to specify non-default names for devices.

For instance, does anyone out there modify their BSD system to have more
linuxy device names, or vice-versa? Or when people talk about not
setting naming policy for dev in the kernel, are they REALLY saying "I
don't like the scheme you thought up"?

As I've said before, no one objects to sysfs's naming in the kernel, no
one wants to assign every sysfs node a number and keep the names out of
the kernel. Same for any number of interfaces that the kernel exports.
Why is dev special? Would devfs has been more popular if it had been
more conservative with its naming scheme?

Do we really need more than one layout for /dev? Or are objections based
less around the need for everyone's dev to be different, and more around
people not having agreed on one good layout yet? I'm of the opinion that
one common layout for /dev is a GOOD thing, it makes things predictable
between systems. Do you want to be completely unable to guess what
device your mouse is, because distribution X uses one name while Y uses
another? I heard that udev gives one common dev layout (LSB) but the
kernel could do the same. The difference is that udev makes it much
easier to completely replace the LSB layout with a different one. But
do any people really need completely different layouts so badly that we
should be making that need one of the key architectural design points?
(It's right there in udev_vs_devfs, number one of three design points.)

Sure there are cases where you might need one or two alternate device
names (like classifying your devices in some completely non-obvious way,
say /dev/PrintersWithinWalkingDistance/ and
/dev/PrintersOnTheOtherSideOfTheOffice) but is that something you need
to focus on, or could it be better handled with symlinks, or "as well
as" device nodes?

Assuming for the moment udev is the right way to go, /dev management
wise, and LSB is the best /dev layout imaginable, mightn't it make sense
to actually make it HARDER to override LSB defaults so people are
encouraged to use the symlinks method, and so the various distributions
don't drift apart? Freedom of choice is all well and good, but that
doesn't mean you should optimise for chaos.

Re: devfs vs udev, thoughts from a devfs user

[Christian Borntraeger]

Mike Bell wrote:
> On Fri, Feb 13, 2004 at 01:19:20PM -0800, Greg KH wrote:
> > > That's a pretty minor difference, from the kernel's point of view.
> > > It's basically putting the same numbers in different fields.
> >
> > Heh, that's a HUGE difference!
>
> Only from userspace's point of view. To the kernel, it's basically the
> same thing.

No. Giving a major and minor number is simple. 
Creating a device node means: you have to define a policy. Now the kernel 
has to think about:
- user id
- group id
- access rights
- naming

These are the reasons why devfsd was/is necessary for devfs.
A Kernel should only enforce a policy, it should not define it.

cheers

Christian

Re: devfs vs udev, thoughts from a devfs user

[Helge Hafting]

On Sat, Feb 14, 2004 at 10:13:50AM +0100, Christian Borntraeger wrote:
> Mike Bell wrote:
> > On Fri, Feb 13, 2004 at 01:19:20PM -0800, Greg KH wrote:
> > > > That's a pretty minor difference, from the kernel's point of view.
> > > > It's basically putting the same numbers in different fields.
> > >
> > > Heh, that's a HUGE difference!
> >
> > Only from userspace's point of view. To the kernel, it's basically the
> > same thing.
> 
> No. Giving a major and minor number is simple. 
> Creating a device node means: you have to define a policy. Now the kernel 
> has to think about:
> - user id
> - group id
> - access rights
> - naming
> 
> These are the reasons why devfsd was/is necessary for devfs.
> A Kernel should only enforce a policy, it should not define it.
> 
There is one more security-related point:
We may decide to not make the device node at all, in order
to prevent use of some dangerous/experimental device or driver.
We can't do that if the device is auto-created.

Root is usually capable of running mknod of course,
but it can be prevented. For example with a fs that
starts out rw but is remounted ro with no option for going back.
Or /dev on cdrom . . .

Helge Hafting

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Sat, Feb 14, 2004 at 12:51:11AM -0800, Mike Bell wrote:
> On Fri, Feb 13, 2004 at 01:19:20PM -0800, Greg KH wrote:
> > > That's a pretty minor difference, from the kernel's point of view. It's
> > > basically putting the same numbers in different fields.
> > 
> > Heh, that's a HUGE difference!
> 
> Only from userspace's point of view. To the kernel, it's basically the
> same thing.

Woah, no this is NOT true.  If you continue to this this, then this
discussion is going to go no where.

Remember, the "dev" file in sysfs is just another attribute for the
device.  Just like a serial number or product id.  A device node would
be a totally different thing.  See all of the other messages from others
about why this is true.

> Now keeping in mind again that I'm not advocating putting device nodes
> into sysfs, what about a little thought experiment. Supposing you did
> replace sysfs's major:minor text file with a real device node

Stop right there and go read the archives for why we are not going to do
this.  This has been discussed a lot.

> Now, here's a question. What's wrong with taking those and splitting
> them into a new filesystem?

Because then you have devfs, which is not what we are trying to do here.

It seems that you are insisting that we have to make a devfs.  Great,
have fun, use the devfs we already have.

> As I see it, part of the reason procfs
> became such a nightmare was because people thought there could be only
> one kernel-generated filesystem and put everything in there.

Not true.  procfs got to be a mess for lots of other reasons (lack of
control, no other options, etc...)

> Linux
> is moving a lot of the silly magic values out of proc and into sysfs
> where they make more sense. Great! But what about stuff that doesn't
> really fit into sysfs as it is right now? Should we take sysfs's clean
> interface and extend it with special cases until it's the ugly mess proc
> is?

No, and I'm not advocating that at all, and never have.  That's not the
point here.

> Or leave everything that doesn't fit cleanly into sysfs in proc,
> making proc a sort of special-cases wasteland?

No, go make your own fs if that's what is needed.  See the IBM service
processor driver filesystem for an example of something like this.

> Alternativly, why not say that there doesn't need to be just one or two
> kernel-exported filesystems, and instead make a sort of library for
> exporting kernel information via fake filesystems (I can't remember, has
> this already been done?)

already been done, see the libfs code.  I don't understand what this has
to do with udev though....

> I'm not a kernel hacker

Stop.  Go read http://ometer.com/hacking.com  Especially pay attention to
the section "Back-seat coders are bad."  I specifically like the lines:

	If you don't know how to code, then you don't know how to design
	the software either. Period.  You can only cause trouble.


So my main point is, I don't know what you are arguing anymore.  If you
don't like udev, and for some reason think that devfs and devfsd can
provide you a stable, secure, and PERSISTENT device naming system, then
fine, go use devfs.

The rest of us will be over here using udev.

(Remember you still haven't told me how you are going to name your scsi
disk and USB printer in a persistent manner no matter how they are
discovered using devfsd.)

> How do you figure that's free? hotplug's a great feature, nothing
> against it, but as far as I know the vast majority of installations
> aren't making use of it right now.

Hint, I don't know of ANY distro that does not enable CONFIG_HOTPLUG
that is not a embedded distro.  That's why I call it "free".  It has so
many other benefits that people can no longer turn it off and expect
their systems to work "nicely".

In conclusion, if you have any problems with udev, how it works, how it
is configured, etc., I'm very glad to hear them and help you through it.
But if you just want to complain about how we all should be using devfs
and devfsd instead of sysfs and udev, you are going to get no where with
me.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Alex Goddard]

On Sat, 14 Feb 2004, Greg KH wrote:

> Stop.  Go read http://ometer.com/hacking.com  

ITYM http://ometer.com/hacking.html

Good article.

-- 
Alex Goddard
agoddard at purdue dot edu

Re: devfs vs udev, thoughts from a devfs user

[Andrew Walrond]

On Saturday 14 Feb 2004 5:44 pm, Alex Goddard wrote:
> On Sat, 14 Feb 2004, Greg KH wrote:
> > Stop.  Go read http://ometer.com/hacking.com
>
> Good article.

Seconded. And guilty, at times, on all counts :)

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Sat, Feb 14, 2004 at 08:54:44AM -0800, Greg KH wrote:
> Woah, no this is NOT true.  If you continue to this this, then this
> discussion is going to go no where.
> 
> Remember, the "dev" file in sysfs is just another attribute for the
> device.  Just like a serial number or product id.  A device node would
> be a totally different thing.  See all of the other messages from others
> about why this is true.

Again, you're not understanding what I'm saying. It's different from
userspace's point of view (it's totally changing the kind of thing sysfs
is presenting, which is why I said I don't believe it should be done)
what I'm saying is that it wouldn't require extra code. It's not making
the kernel do extra work, it's just making it do the same work in a
different way. It was an example to prove a later point, not a
suggestion for how to do things.

> Stop right there and go read the archives for why we are not going to do
> this.  This has been discussed a lot.

I just said I wasn't advocating it! It was just to illustrate a later
point.

> Because then you have devfs, which is not what we are trying to do here.
>
> It seems that you are insisting that we have to make a devfs.  Great,
> have fun, use the devfs we already have.

Do you see the irony here? You accuse me of just wanting devfs instead
of udev the line after you answer a question with, essentially, "because
then you have devfs, and devfs is bad".

And I already do use the devfs we already have, and have done so for a
long time. But it could use a lot of improvement (the same way udev
could).

> > As I see it, part of the reason procfs became such a nightmare was
> > because people thought there could be only one kernel-generated
> > filesystem and put everything in there.
> 
> Not true.  procfs got to be a mess for lots of other reasons (lack of
> control, no other options, etc...)

Did you miss the word "part"? And you say "no other options", isn't that
what I just said ("only one kernel generated filesystem")? 

> > Linux is moving a lot of the silly magic values out of proc and into
> > sysfs where they make more sense. Great! But what about stuff that
> > doesn't really fit into sysfs as it is right now? Should we take
> > sysfs's clean interface and extend it with special cases until it's
> > the ugly mess proc is?
> 
> No, and I'm not advocating that at all, and never have.  That's not
> the point here.

No, but it was my example of why not everything has to be done in sysfs,
and why having a greater number of more specialised filesystems can be a
good thing.

What I was trying to say is:

1) Isn't it good to have more than one kernel-generated filesystem, if
each one can thereby be more specialised and therefore cleaner? (I
believe you agree on this point).

2) If that's the case, why do you keep arguing that devfs (exporting
device nodes from the kernel in a small and simple filesystem and
letting a userspace daemon control their permissions and make symlinks
so that the "right" cdrom drive is /dev/cdrom and such) is so horrible?

> already been done, see the libfs code.  I don't understand what this
> has to do with udev though....

Thought so, but I couldn't remember the name. And it has to do with
devfs (and implementing it using libfs), not with udev per se.

> > I'm not a kernel hacker
> 
> Stop.  Go read http://ometer.com/hacking.com  Especially pay attention
> to the section "Back-seat coders are bad."  I specifically like the
> lines:
> 
> 	If you don't know how to code, then you don't know how to design
> 	the software either. Period.  You can only cause trouble.

I didn't say I don't know how to code, I said I wasn't a kernel hacker.
And I wasn't TRYING to tell you how to write udev, though I may
accidentally have come off that way.

I started this thread out saying that I liked devfs better than udev for
a few reasons, that udev didn't give me everything I wanted, and that
therefore I would like to know if anyone else felt likewise and if so
whether there was enough interest to "save" devfs, either by fixing the
existing one or by doing it again from scratch.

I wasn't trying to tell you how to do udev (though again, I may have
come off that way accidentally, and if so I'm sorry). The only issue I
ever had with you was that I didn't agree with a lot of your "devfs
versus udev" document. Which is why I started the thread with a sort of
counter to that.

> So my main point is, I don't know what you are arguing anymore.  If
> you don't like udev, and for some reason think that devfs and devfsd
> can provide you a stable, secure, and PERSISTENT device naming system,
> then fine, go use devfs.

Again, I do. But if everyone stopped working on udev except for
bug-fixes, I bet it would start to be pretty nasty in one or two major
kernel releases. Which is why I was trying to see if anyone else was
interested in saving devfs.

> > How do you figure that's free? hotplug's a great feature, nothing
> > against it, but as far as I know the vast majority of installations
> > aren't making use of it right now.
> 
> Hint, I don't know of ANY distro that does not enable CONFIG_HOTPLUG
> that is not a embedded distro.  That's why I call it "free".  It has
> so many other benefits that people can no longer turn it off and
> expect their systems to work "nicely".

It may be enabled in a lot of kernels, but I don't know any distros that
actually break if you turn it off (though I may be wrong here). So I
don't think you're right when you say "It has so many other benefits
that people can no longer turn it off and expect their systems to work
"nicely"".

> In conclusion, if you have any problems with udev, how it works, how
> it is configured, etc., I'm very glad to hear them and help you
> through it.  But if you just want to complain about how we all should
> be using devfs and devfsd instead of sysfs and udev, you are going to
> get no where with me.

I wasn't trying to get somewhere with you. The main purpose of this
thread was to guage the level of interest in keeping devfs alive (which
I suppose I've done, though I'm disappointed more people don't seem to
agree with me on the advantages of a devfs solution over udev).

The most I ever wanted from you personally was for you to make your udev
versus devfs document a little fairer to devfs. I wish you the best of
luck in developing udev, and since it looks like it's the preferred
solution, I genuinely hope it matures quickly so that static /dev on
linux can go away.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Thu, Feb 19, 2004 at 01:47:21AM -0800, Mike Bell wrote:
> 
> And I already do use the devfs we already have, and have done so for a
> long time. But it could use a lot of improvement (the same way udev
> could).

What could be improved in udev?  What is it lacking that you need?
Seriously, I'm interested in this.  I'm not interested in devfs vs udev
arguments, as that argument has been played out zillions of times before
and devfs has consistently lost.

<big snip...>

> I wasn't trying to tell you how to do udev (though again, I may have
> come off that way accidentally, and if so I'm sorry). The only issue I
> ever had with you was that I didn't agree with a lot of your "devfs
> versus udev" document. Which is why I started the thread with a sort of
> counter to that.

Well, if you want to either send me a patch for the udev-vs-devfs
document that contains your suggested changes, or post your own
devfs_is_so_superior_to_udev_that_no_one_should_ever_argue_with_me
document, feel free to do so :)

> > > How do you figure that's free? hotplug's a great feature, nothing
> > > against it, but as far as I know the vast majority of installations
> > > aren't making use of it right now.
> > 
> > Hint, I don't know of ANY distro that does not enable CONFIG_HOTPLUG
> > that is not a embedded distro.  That's why I call it "free".  It has
> > so many other benefits that people can no longer turn it off and
> > expect their systems to work "nicely".
> 
> It may be enabled in a lot of kernels, but I don't know any distros that
> actually break if you turn it off (though I may be wrong here). So I
> don't think you're right when you say "It has so many other benefits
> that people can no longer turn it off and expect their systems to work
> "nicely"".

As you have proved that you do not understand what CONFIG_HOTPLUG is and
does for a system, I do not see how you can back up your argument about
this topic.  Please become more well-informed of the situation before
trying to discuss this.

> I wasn't trying to get somewhere with you. The main purpose of this
> thread was to guage the level of interest in keeping devfs alive (which
> I suppose I've done, though I'm disappointed more people don't seem to
> agree with me on the advantages of a devfs solution over udev).

If you look at your first post on this topic, it falls far short of this
goal.  It seemed like another "why is everyone picking on devfs as it's
so great!" complaint to me by someone who does not fully understand how
the devfs or udev code works.

> The most I ever wanted from you personally was for you to make your udev
> versus devfs document a little fairer to devfs. I wish you the best of
> luck in developing udev, and since it looks like it's the preferred
> solution, I genuinely hope it matures quickly so that static /dev on
> linux can go away.

udev is mature enough to do this today.  I'm typing this on a box that
runs it's /dev solely by using udev on a ramfs partition.  See my
recently posted HOWTO for how to do this if you are interested.

Also, please remember the main goal of udev, the ability to create
persistent names for devices.  This is something that devfs can not do
for you at all.  The fact that udev can fully replace devfs with a tiny
userspace program is further proof that udev is the proper way to manage
a /dev tree.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[Mike Bell]

On Thu, Feb 19, 2004 at 11:43:57AM -0800, Greg KH wrote:
> > It may be enabled in a lot of kernels, but I don't know any distros that
> > actually break if you turn it off (though I may be wrong here). So I
> > don't think you're right when you say "It has so many other benefits
> > that people can no longer turn it off and expect their systems to work
> > "nicely"".
> 
> As you have proved that you do not understand what CONFIG_HOTPLUG is and
> does for a system, I do not see how you can back up your argument about
> this topic.  Please become more well-informed of the situation before
> trying to discuss this.

Sorry, what? How did I prove that? All I'm saying is that I've got
plenty of systems that don't have any executable at /sbin/hotplug, even
though /proc/sys/kernel/hotplug is set to that, and they work just fine.
To me, this means that the system in question obviously ISN'T relying on
the hotplug mechanism dispite your claims that it's required for any
system to behave nicely.  Please stop resorting to personal insults
every time I disagree with you.

> If you look at your first post on this topic, it falls far short of this
> goal.  It seemed like another "why is everyone picking on devfs as it's
> so great!" complaint to me by someone who does not fully understand how
> the devfs or udev code works.

I just reread it, and I don't see how you can make any of those claims.

I asked "is a devfs-like implementation really unfixable? And if not, is
it worth whatever disadvantages can't be avoided?" To me, the answers
are still no and yes, but I'm going to /try/ to shut up about it now.
Either udev will eventually be sufficient for everyone's needs, or
someone will come along and write something better. I just wanted to
show people why I thought it was the latter, and hopefully encourage
that something better to come around sooner rather than later. I don't
see how that makes me a devfs-loving whiner who doesn't know what he's
talking about.

I said I disagreed with your argument about how devfs sets naming
policy in the kernel, while udev does not. devfs sets /dev's naming
policy in the kernel, while udev does not. But udev still relies on
naming policy set in the kernel, in the form of sysfs. To me, that's an
important difference. What you claim seems to me like you're saying that
names in the kernel are a deadly sin and udev does away with them
completely. What actually happens is that udev relies on names set in
the kernel in a new filesystem, so that people can see the /dev layout
they're used to or whatever other one they want. If you made that claim
and said it was an advantage for udev and I wouldn't argue, but to me
it's actually an advantage to devfs. One canonical name format for any
given device node and then symlinks for alternate names (like
/dev/mouse or a persistant name for a given USB device or anything else
that can only be decided in userspace) makes more sense to me than the
complete flexibility of udev.

Either people make use of udev's capability to do that, and their
system's SCSI hard drives have totally different device names to anyone
else's, or they don't, everyone has LSB /dev names, and the same effect
could have been accomplished by a devfs that exported LSB names instead
of the (sometimes objectionably long) ones it wound up exporting. Either
way, if you ask me, one consistant naming scheme is better than all the
"flexibility" udev has to offer, just like consistant syscall numbers
are better than consulting a userspace table to figure out what read()
is on this system, and just like /proc/sys/ and sysfs have consistant,
kernel generated names that people don't object to.

> Also, please remember the main goal of udev, the ability to create
> persistent names for devices.  This is something that devfs can not do
> for you at all. 
> 
> The fact that udev can fully replace devfs with a tiny userspace
> program is further proof that udev is the proper way to manage a /dev
> tree.

Creating persistent names for devices is good. It must be done from
userspace, since there's no way you could sanely put all the logic
required into the kernel. udev does this, and that's a good thing about
udev. The only part I disagree with is where you jump to "therefore,
udev is the right way to manage a /dev tree." The two do not go
together, udev creating all the device nodes in /dev is not required for
udev (or whatever the program is called) making persistent names (device
nodes or symlinks or whatever) in /dev.

Re: devfs vs udev, thoughts from a devfs user

[Greg KH]

On Fri, Feb 13, 2004 at 02:08:36PM -0800, walt wrote:
> Greg KH wrote:
> 
> > ...sysfs exports loads of info about every device in your system, not
> >   only the major:minor info.  It exports what device this major:minor
> >   is assigned to, the topology of the device...
> 
> For the benefit of us schlubs looking in from the outside, could you tell
> us what you mean by 'topology' ?

Run 'tree' from /sys/devices/ to see the topology of how all of the
different devices in your system are hooked together.  Notice how the
usb mouse is connected to a usb controller which is connected to a pci
device, and so on.

udev can use that "chain" of devices to determine how to name your
device.

thanks,

greg k-h

Re: devfs vs udev, thoughts from a devfs user

[walt]

Greg KH wrote:

>  ...sysfs exports loads of info about every device in your system, not
>    only the major:minor info.  It exports what device this major:minor
>    is assigned to, the topology of the device...

For the benefit of us schlubs looking in from the outside, could you tell
us what you mean by 'topology' ?

Thanks, from a gentoo/udev user!

Re: devfs vs udev, thoughts from a devfs user

["Andrey Borzenkov"]

> I completely agree. But who would volunteer to spend their time fixing
> devfs if no one said they wanted devfs, if all evidence says everyone is
> happy with udev? I just wanted to get out that I'm not, I think devfs
> (as a concept, not neccessarily the implementation in the kernel right
> now) has merits udev does not and never will possess, and to see if anyone
> else agrees.

I am not happy with udev as it is currently; I am not happy with devfs crashing; I will continue to do what I can as time permits.

I do not neccessarily need devfs - but udev lacks two features I need and I do not see any way to add them without creatign the same sort of problems as devfs has.

>> Devfs can do this, but it is not necessarily a good thing.
>> I tried it - and it only works if someone tries to look up
>> a particluar name, such as /dev/dsp.  It doesn't work when someone
>> does a "ls /dev" to see what devices is there.
>> A "ls /dev/dsp*" didn't find the multiple soundcards for which
>> modules weren't yet loaded.
>

no way. this requires far deeper devfs integration that is currently available. there was code that did it for removable media; it was removed during 2.5 series. fixing bugs in devfs is one thing; reintegrating it into kernel is another.

basically devfs in 2.6 is reduced to

mknod from within drivers
devfsd notification on lookup

> Nor would you want it to... Although, it might be handy for something
> like a SCSI controller. An opendir() in its directory would trigger the
> kernel to see what's attached to it. Postponing the probing of every LUN
> until someone goes looking could speed up boot times quite a bit.

I must admit I never used devfs names myself so it proved rather useless to me even in 2.4 times.

-andrey