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