The removal of the deprecated devfs from the mainline kernel took another step forward today with a patch from Greg KH that removes devfs from the build process. He adds, "if this goes well, and there are no complaints for a few weeks, I'll resend my big 'devfs-die-die-die' series of patches that rip the whole thing out of the kernel tree." Mike Bell expressed concern, "once devfs is out, it's out for good. It is for all intents and purposes impossible to maintain such a thing outside of mainline. You should know that, udev's kernel infrastructure was developed pretty much entirely within mainline and look how long it took to get even the present number of drivers working with it." The replacement for devfs is udev, which Greg KH began developing in 2001 [story].

This led into a lengthy discussion debating the merits of using devfs with embedded systems. 2.6 maintainer Andrew Morton [interview] suggested that the fate of devfs is still undecided, "I don't have enough info to know whether the world would be a better place if we keep devfs, remove devfs or remove devfs even later on. I don't think anyone knows, which is why we're taking this little disable-it-and-see-who-shouts approach."

From: Mike Bell [email blocked]
To: Greg KH [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 18:00:32 -0700

On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> There might be some complaints.  But I doubt they would be from anyone
> running a -mm tree as those people kind of know the current status of
> things in the kernel.  There have been numerous warnings as to the fact
> that this was going away, and I waited a _year_ to do this.

I use -mm and I'm complaining.

Knowing it's coming isn't the same as agreeing with it. :)

Once devfs is out, it's out for good. It is for all intents and purposes
impossible to maintain such a thing outside of mainline. You should know
that, udev's kernel infrastructure was developed pretty much entirely
within mainline and look how long it took to get even the present number
of drivers working with it.

It's pretty hard to put effort into devfs when said patches won't get
merged because it has already been decided by certain people that devfs
is not the way to go. For example the quick death without comment of the
earlier devfs-on-top-of-tmpfs patches.

Or, look at how hard of a time udev had gaining mindshare, how long it
was around for until now. Only shock tactics like marking devfs OBSOLETE
(at a time when udev was completely unready to replace devfs, making
it far from obsolete) got people switching.

> Also, no disto uses devfs only (gentoo is close, but offers users udev
> and a static /dev also.)

It breaks a lot of my embedded setups which have read-only storage only
and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
being - in my experience - still unready. Not to mention the general
bother of having to change dozens of desktop/server systems to work with
udev, but I doubt you care about that.



From: Andrew Morton [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 18:18:25 -0700

Mike Bell [email blocked] wrote:
>
> On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> > There might be some complaints.  But I doubt they would be from anyone
> > running a -mm tree as those people kind of know the current status of
> > things in the kernel.  There have been numerous warnings as to the fact
> > that this was going away, and I waited a _year_ to do this.
> 
> I use -mm and I'm complaining.

Thanks!

> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs.

Well that's quite a problem.  We're certainly causing people such as
yourself to take on quite a lot of work.  But on the other hand we do want
the kernel to progress sanely, and that sometimes involves taking things
out.

I don't have enough info to know whether the world would be a better place
if we keep devfs, remove devfs or remove devfs even later on.  I don't
think anyone knows, which is why we're taking this little
disable-it-and-see-who-shouts approach.



From: Bill Gatliff [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 21:13:47 -0500

Andrew:


>>It breaks a lot of my embedded setups which have read-only storage only
>>and thus need /dev on devfs or tmpfs.
>>    
>>
>
>Well that's quite a problem.  We're certainly causing people such as
>yourself to take on quite a lot of work.  But on the other hand we do want
>the kernel to progress sanely, and that sometimes involves taking things
>out.
>
>I don't have enough info to know whether the world would be a better place
>if we keep devfs, remove devfs or remove devfs even later on.  I don't
>think anyone knows, which is why we're taking this little
>disable-it-and-see-who-shouts approach.
>  
>

I would prefer to keep devfs around as well, but most of my embedded 
systems have enough RAM to put a primitive /dev tree in tmpfs using a 
linuxrc script at boot.  The workarounds for the userland requirements 
of udev are a little less clear to me, but I'm not sure they're 
insurmountable yet for anything except the smallest embedded systems, 
since Busybox appears to have some udev support available now.

I think that devfs and udev appeal to different audiences, hence I don't 
think you can say that the "world will be a better place" with one or 
the other.  It would be nice to find a way to have the two coexist 
peacefully...

Case in point.  I'm going to udev reluctantly; all my embedded work 
based on earlier kernels used devfs exclusively.


b.g.

-- 
Bill Gatliff
So what part of:
   $ make oldconfig clean dep zImage
do you not understand?
bgat@billgatliff.com



From: Greg KH [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 21:59:59 -0700

On Wed, Jun 22, 2005 at 06:00:32PM -0700, Mike Bell wrote:
> On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> > There might be some complaints.  But I doubt they would be from anyone
> > running a -mm tree as those people kind of know the current status of
> > things in the kernel.  There have been numerous warnings as to the fact
> > that this was going away, and I waited a _year_ to do this.
> 
> I use -mm and I'm complaining.
> 
> Knowing it's coming isn't the same as agreeing with it. :)

I don't mean to pick on you, but this has been known for over a year
now, right?  Hasn't anyone been preparing for any alternative situation
should this happen?  I know some distros have, but it seems the embedded
people (you aren't the first to mention the "joys" of using devfs in
embedded systems) just have been hoping this wasn't going to happen.

Very odd...

> Once devfs is out, it's out for good. It is for all intents and purposes
> impossible to maintain such a thing outside of mainline.

Not true, look at how long it was maintained out of mainline to start
with.  Using the tools we have today (like quilt and git) it should be
quite easy to keep the patch going if you really need it.

> You should know that, udev's kernel infrastructure was developed
> pretty much entirely within mainline and look how long it took to get
> even the present number of drivers working with it.

I do know that, but again, just reverse the patch and keep it going if
you really want to.  All of the hard work is already done.

> > Also, no disto uses devfs only (gentoo is close, but offers users udev
> > and a static /dev also.)
> 
> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
> being - in my experience - still unready.

Woah, I think Red Hat's and SuSE's "enterprise" distros would prove this
statement wrong.  Also, there have been some people making some boot
images with udev in it for embedded systems that are almost a no-brainer
for someone to use (see the linux-hotplug-devel mailing list for more
info about this.)

> Not to mention the general bother of having to change dozens of
> desktop/server systems to work with udev, but I doubt you care about
> that.

I do care about this, please don't think that.  But here's my reasoning
for why it needs to go:

	- unmaintained for a number of years
	- original developer of devfs has publicly stated udev is a
	  replacement.
	- policy in the kernel.
	- no distro uses it
	- clutter and mess
	- code is broken and unfixable
	- udev is a full, and way more complete solution (it offers up
	  so much more than just a dynamic /dev.  Way more than I ever
	  dreamed of.)
	- companies are shipping, and supporting distros that use udev.
	- It has been public knowledge that it would be removed for a
	  number of years, and the date has been specifically known for
	  the past year.

Are you really going to want to update a running system that uses devfs
to a newer kernel?  If so, your distro will have a static /dev or a udev
package to replace it.  If you aren't using your own distro, a drop-in
static /dev tree is a piece of cake for the short run, and udev is
simple to get up and running after that if you really want dynamic
stuff.

And again, for embedded systems, there are packages to build it and put
it in initramfs.  People have already done the work for you.

thanks,

greg k-h



From: Mike Bell [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 23:28:42 -0700

On Wed, Jun 22, 2005 at 09:59:59PM -0700, Greg KH wrote:
> I don't mean to pick on you, but this has been known for over a year
> now, right?  Hasn't anyone been preparing for any alternative situation
> should this happen?  I know some distros have, but it seems the embedded
> people (you aren't the first to mention the "joys" of using devfs in
> embedded systems) just have been hoping this wasn't going to happen.
>
> Very odd...

What other choices are there? Fork the kernel?

> Not true, look at how long it was maintained out of mainline to start
> with.  Using the tools we have today (like quilt and git) it should be
> quite easy to keep the patch going if you really need it.

In an increasingly broken and harder to maintain state. Official
blessing means a great deal. If you didn't know this, why did you go to
such great lengths to state that udev was the official future path of
the linux kernel? Even before the official removal date was announced,
vocal udev proponents actively discouraged out-of-tree projects from
accepting devfs fixes. Once it's removed, this becomes even worse.
Something like devfs (or the device model, or anything else core
infrastructurey) isn't possible without the cooperation of the community
in general, because it touches so much.

> I do care about this, please don't think that.  But here's my reasoning
> for why it needs to go:

> 	- unmaintained for a number of years

Semi-debatable. Even without a single maintainer, it has been getting
fixes (just look at all the work that happened in the 2.5 series). And
Adam J. Richter attempted to take over maintainership not long ago as I
recall.

> 	- policy in the kernel.

Already exists. Don't see why /dev is policy in userspace but /proc and
/sys aren't, or why a single canonical name set by the driver author
with symlinks to whateverthehellyouwant isn't far superior. Fine, people
hate devfs's drive naming. I'm hardly a big fan of it either. But that
doesn't mean the idea of a single canonical naming scheme by which
userspace can consistently identify devices isn't a good one. As I
recall you even tried to propose such a scheme, albiet as overridable
policy in udev rather than in devfs, so you must recognize that there is
advantage to not having a different /dev naming scheme on every dist. As
long as I can have my USB serial wireless modem named
"/dev/usb-serial-wireless-modem" via a symlink, why should I care that
the canonical name is something about USBttyS?

> 	- no distro uses it

Bull. Complete. Can I claim by similar logic that no distro uses udev?

> 	- clutter and mess

Which is true of many other parts of the kernel, some of which were
cleaned up rather than being declared obsolete and preventing further
work to clean them up.

> 	- code is broken and unfixable

People attempting to fix the code might disagree. In fact, I'd consider
the claim that any code is "unfixable" pretty hard to back up logically.

> 	- udev is a full, and way more complete solution (it offers up
> 	  so much more than just a dynamic /dev.  Way more than I ever
> 	  dreamed of.)

That works if you exclude all the things that devfs does that udev
doesn't, which you do because you consider them misfeatures, but that
kind of logic doesn't work for everyone.

> 	- companies are shipping, and supporting distros that use udev.

After being forced to do so by the sudden surprise deprication of devfs
and the ensuing publicity to udev.

> 	- It has been public knowledge that it would be removed for a
> 	  number of years, and the date has been specifically known for
> 	  the past year.

Based somewhat on repeated statements that this was fait accompli. If
people are still using it and still consider udev not to be a complete
replacement, then the possibility of leaving it in the kernel should at
least be entertained. Not only is OSS still around for these reasons, but
even cryptoloop is still there! And unlike OSS and devfs, I haven't
recently heard anyone claim cryptoloop did something dm-crypt doesn't.

> Are you really going to want to update a running system that uses devfs
> to a newer kernel?

Why not? I've been doing it for over five years now. Or do you mean
change a running system using devfs to udev? No, I don't want to do that
at all, which is why I'm trying to get devfs left alone.

> If so, your distro will have a static /dev or a udev package to
> replace it.  If you aren't using your own distro, a drop-in static
> /dev tree is a piece of cake for the short run, and udev is simple to
> get up and running after that if you really want dynamic stuff.

Well, in my case dynamic stuff is a prerequisite, while my servers would
all be fine with a static dev it would for all intents and purposes
destroy the functionality of my notebooks (practically everything is
dynamic. I can't even type on one without devfs.)

> And again, for embedded systems, there are packages to build it and
> put it in initramfs.  People have already done the work for you.

I'll look yet again, but I've been told that udev was "ready" when it
wasn't enough times now that I'm highly skeptical.

I've always considered myself an early adopter of "better" solutions. I
switched to devfs on my desktop the day it was put into mainline. I
invested a little time to switch from cryptoloop to dm-crypt for my
crypted-home-on-flash setup before dm-crypt was even in the kernel,
because I was won over by arguments that it was better. I always run the
current development series (when there is one) on at least one of my
machines, usually my main one. It's not like I'm resistant to change,
quite the opposite. I'm just plain unconvinced that udev is better in
every way to devfs. And the bizarre "force it down your throats" policy
that has characterized the udev over devfs saga has done little to
endear me to it.



From: Greg KH [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 23:48:47 -0700

On Wed, Jun 22, 2005 at 11:28:42PM -0700, Mike Bell wrote:
> On Wed, Jun 22, 2005 at 09:59:59PM -0700, Greg KH wrote:
> > I don't mean to pick on you, but this has been known for over a year
> > now, right?  Hasn't anyone been preparing for any alternative situation
> > should this happen?  I know some distros have, but it seems the embedded
> > people (you aren't the first to mention the "joys" of using devfs in
> > embedded systems) just have been hoping this wasn't going to happen.
> >
> > Very odd...
> 
> What other choices are there? Fork the kernel?

No, plan for it.  Speak up.  Complain sometime a while ago instead of
right when it happens.

> > Not true, look at how long it was maintained out of mainline to start
> > with.  Using the tools we have today (like quilt and git) it should be
> > quite easy to keep the patch going if you really need it.
> 
> In an increasingly broken and harder to maintain state. Official
> blessing means a great deal.

I understand this.

> If you didn't know this, why did you go to such great lengths to state
> that udev was the official future path of the linux kernel?

When did I ever say this?  I have only ever said it was an option that
people who want dynamic /dev and persistant naming can use.  There are
other projects out there becides udev that do much the same thing in
userspace, udev isn't the only one.

> Even before the official removal date was announced, vocal udev
> proponents actively discouraged out-of-tree projects from accepting
> devfs fixes.

I was not aware of this.

> > I do care about this, please don't think that.  But here's my reasoning
> > for why it needs to go:
> 
> > 	- unmaintained for a number of years
> 
> Semi-debatable. Even without a single maintainer, it has been getting
> fixes (just look at all the work that happened in the 2.5 series). And
> Adam J. Richter attempted to take over maintainership not long ago as I
> recall.

He did, as did others.  However no one actually did the work, and were
persistant, which is what really matters in this community.

> > 	- policy in the kernel.
> 
> Already exists.

namespace policy does?  Yes, the LANNANA one.  A non-LSB standard should
not.

> Don't see why /dev is policy in userspace but /proc and /sys aren't,
> or why a single canonical name set by the driver author with symlinks
> to whateverthehellyouwant isn't far superior. Fine, people hate
> devfs's drive naming.

See the above point about LSB.

> I'm hardly a big fan of it either. But that doesn't mean the idea of a
> single canonical naming scheme by which userspace can consistently
> identify devices isn't a good one.

But for persistant device naming, you need to do this in userspace, the
kernel can not do it (and before the old ptx developers pipe up, yes,
you all did do this within your kernel years ago, but your performance
sucked and I'm not putting a whole database into our kernel...)

> As I recall you even tried to propose such a scheme, albiet as
> overridable policy in udev rather than in devfs, so you must recognize
> that there is advantage to not having a different /dev naming scheme
> on every dist.

udev allows different /dev naming schemes, even a devfs-compatible one
so you don't have to change any other programs if you want so.  devfs
was unable to provide different ones.

> As long as I can have my USB serial wireless modem named
> "/dev/usb-serial-wireless-modem" via a symlink, why should I care that
> the canonical name is something about USBttyS?

dot-files will die that way :(

Becides them, no, you shouldn't, in fact, some distros use udev that way
today.

> > 	- no distro uses it
> 
> Bull. Complete. Can I claim by similar logic that no distro uses udev?

What distro shipps support for devfs and a 2.6 kernel?  I am not aware
of one (Gentoo doesn't count, they don't "ship" anything :)  Honestly, I
don't know of any.  I do know of a lot of them that ship udev.

> > 	- clutter and mess
> 
> Which is true of many other parts of the kernel, some of which were
> cleaned up rather than being declared obsolete and preventing further
> work to clean them up.

But it was unmaintained clutter and mess.

> > 	- code is broken and unfixable
> 
> People attempting to fix the code might disagree. In fact, I'd consider
> the claim that any code is "unfixable" pretty hard to back up logically.

See Al Viro's comments about this, and then try to refute them.  It's
not just me saying this at all.  In the end, no one has fixed them to
prove him wrong so he might just be on to something...

> > 	- udev is a full, and way more complete solution (it offers up
> > 	  so much more than just a dynamic /dev.  Way more than I ever
> > 	  dreamed of.)
> 
> That works if you exclude all the things that devfs does that udev
> doesn't, which you do because you consider them misfeatures, but that
> kind of logic doesn't work for everyone.

There is only 1 thing that I know of that devfs does that udev does not,
auto-module-loading if you try to access a device node that isn't
present.  See my previous posts as to why this is a unworkable scheme
anyway for 99% of the kernel devices.  Yes, the other 1% can use this,
like ppp and raw.  But the distros have already solved this issue, so
it's kind of moot.

Is there anything else that devfs can do that udev can't?  I have a
whole list of things that udev can do that devfs can not :)

> > 	- companies are shipping, and supporting distros that use udev.
> 
> After being forced to do so by the sudden surprise deprication of devfs
> and the ensuing publicity to udev.

I have not forced _any_ company to do so.  I have not even _asked_ any
company to do so.  I have simply been amazed that so many companies
siezed on udev and brought it up to maturity and shipped it.  That tells
me that people really wanted it and see the advantages of it over devfs.

> > 	- It has been public knowledge that it would be removed for a
> > 	  number of years, and the date has been specifically known for
> > 	  the past year.
> 
> Based somewhat on repeated statements that this was fait accompli.

Nothing is ever that way in our community, you should know that :)

> If people are still using it and still consider udev not to be a
> complete replacement, then the possibility of leaving it in the kernel
> should at least be entertained.

I have not heard any such issues in the past 6 months.  Hence my
supprise now (well, not really supprise, I knew someone would complain,
pretty amazed that it's only been one person in public (and one person
privatly) so far.)

> Not only is OSS still around for these reasons, but
> even cryptoloop is still there! And unlike OSS and devfs, I haven't
> recently heard anyone claim cryptoloop did something dm-crypt doesn't.

Maybe no one has just taken the time and effort to want to remove
cryptoloop.  That's what it takes to get anything done around here...
Don't thing that lack of action always implies acceptance...

> > Are you really going to want to update a running system that uses devfs
> > to a newer kernel?
> 
> Why not? I've been doing it for over five years now. Or do you mean
> change a running system using devfs to udev? No, I don't want to do that
> at all, which is why I'm trying to get devfs left alone.

Ok, fair enough.

> > If so, your distro will have a static /dev or a udev package to
> > replace it.  If you aren't using your own distro, a drop-in static
> > /dev tree is a piece of cake for the short run, and udev is simple to
> > get up and running after that if you really want dynamic stuff.
> 
> Well, in my case dynamic stuff is a prerequisite, while my servers would
> all be fine with a static dev it would for all intents and purposes
> destroy the functionality of my notebooks (practically everything is
> dynamic. I can't even type on one without devfs.)

Then use the devfs mode of udev.  The devfs author even sent me updates
in order to get them to work properly for his machines...

> > And again, for embedded systems, there are packages to build it and
> > put it in initramfs.  People have already done the work for you.
> 
> I'll look yet again, but I've been told that udev was "ready" when it
> wasn't enough times now that I'm highly skeptical.

I would be glad to help out in any way, if you have any issues.  You
should post them to the linux-hotplug-devel mailing list so the other
udev developers can also help out.

> I've always considered myself an early adopter of "better" solutions. I
> switched to devfs on my desktop the day it was put into mainline. I
> invested a little time to switch from cryptoloop to dm-crypt for my
> crypted-home-on-flash setup before dm-crypt was even in the kernel,
> because I was won over by arguments that it was better. I always run the
> current development series (when there is one) on at least one of my
> machines, usually my main one. It's not like I'm resistant to change,
> quite the opposite. I'm just plain unconvinced that udev is better in
> every way to devfs. And the bizarre "force it down your throats" policy
> that has characterized the udev over devfs saga has done little to
> endear me to it.

I have never, until now, forced anyone to use udev.  And even now, I'm
not forcing anyone (there are other solutions to a dynamic /dev becides
udev).  I do feel, and it seems others agree, that udev is a far
superior solution to the persistant device naming issue than devfs is
(well, that's not really fair, as devfs can't even do that.)  As a
wonderful side affect, it also handles a dynamic /dev which other people
seem to like.

thanks,

greg k-h




From: Mike Bell [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Thu, 23 Jun 2005 01:29:00 -0700

On Wed, Jun 22, 2005 at 11:48:47PM -0700, Greg KH wrote:
> No, plan for it.  Speak up.  Complain sometime a while ago instead of
> right when it happens.

Did so. Raised the same points I'm doing now. Said at the time I was
going to wait and see if udev evolved to meet my needs before devfs got
removed. That time has arrived, and it hasn't, hence this. Seems
sensible to me.

> When did I ever say this?  I have only ever said it was an option that
> people who want dynamic /dev and persistant naming can use.  There are
> other projects out there becides udev that do much the same thing in
> userspace, udev isn't the only one.

But they all use fundamentally the same interface as udev and thus none
of them is any different with regard to my problems with udev, no?

> > Even before the official removal date was announced, vocal udev
> > proponents actively discouraged out-of-tree projects from accepting
> > devfs fixes.
> I was not aware of this.

Nonetheless true, and an example of the kind of problems maintaining
it out of tree would only make worse. And are you yourself not an
advocate of not caring if one breaks anything out of tree?

> He did, as did others.  However no one actually did the work, and were
> persistant, which is what really matters in this community.

The process for getting code into mainline involves getting someone "in
the loop" to adopt your patch. If no one looks like they are going to do
that, your effort is wasted. What is one supposed to do?

> namespace policy does?  Yes, the LANNANA one.  A non-LSB standard should
> not.

> See the above point about LSB.

See my point about how I don't care about devfs's specific namescheme,
how driver authors should pick the names for their devices, and how if
you mean "these particular names don't belong in the kernel" you should
say as much, not "policy in kernel".

> But for persistant device naming, you need to do this in userspace, the
> kernel can not do it (and before the old ptx developers pipe up, yes,
> you all did do this within your kernel years ago, but your performance
> sucked and I'm not putting a whole database into our kernel...)

You can't reasonably have "this USB fob will always have this name but
another of the same make will have a different name" without userspace
help, nor should you, but you can have "all v4l devices show up in this
form" and the like. Which, for the vast majority of cases, is enough.

> udev allows different /dev naming schemes, even a devfs-compatible one
> so you don't have to change any other programs if you want so.  devfs
> was unable to provide different ones.
> 
> > As long as I can have my USB serial wireless modem named
> > "/dev/usb-serial-wireless-modem" via a symlink, why should I care that
> > the canonical name is something about USBttyS?
> 
> dot-files will die that way :(

Not if they follow the symlink as they should.

> Becides them, no, you shouldn't, in fact, some distros use udev that way
> today.

So basically you've stated that this way of doing things is fine? And
since there's nothing to stop this way of doing things from happening
with devfs and a small, optional userspace helper to come up with
meaningful symlinked names based on logic that cannot reasonably be put
in the kernel....

> What distro shipps support for devfs and a 2.6 kernel?  I am not aware
> of one (Gentoo doesn't count, they don't "ship" anything :)  Honestly, I
> don't know of any.  I do know of a lot of them that ship udev.

Debian? Their installer even relies on devfs instead of udev. And
following up absolute statements like "no distro uses it" with things
like "gentoo doesn't count" is why I never trust the things you say.
"udev is smaller than devfs", if you discount sysfs. Or earlier "udev
does everything devfs does" comments which were actually "can
theoretically do these things, but currently isn't implemented, and it
only works with a handful of devices"

> But it was unmaintained clutter and mess.

Which people have attempted to maintain. Presumably, had it not been
marked OBSOLETE and thus useless to bother maintaining in the eyes of
most, said patches would have gone in just like any other cleanup, and
just like devfs cleanups had been doing until that point.

> See Al Viro's comments about this, and then try to refute them.  It's
> not just me saying this at all.  In the end, no one has fixed them to
> prove him wrong so he might just be on to something...

If this is about the stupid race, I don't see why all of devfs should be
damned for a feature no one (to my knowledge) uses anyway and thus could
be easily ripped out without the objections of devfs-liking people. See
above comments about a single canonical name for devices.

> There is only 1 thing that I know of that devfs does that udev does not,
> auto-module-loading if you try to access a device node that isn't
> present.  See my previous posts as to why this is a unworkable scheme
> anyway for 99% of the kernel devices.  Yes, the other 1% can use this,
> like ppp and raw.  But the distros have already solved this issue, so
> it's kind of moot.

I mentioned earlier that my main problems with udev were the continued
reliance on a partially static /dev, the way /dev is no longer
representative of the kernel's state, the reliance on sysfs to get any
usable system (assuming you treat static /dev as an unacceptable option,
which it is increasingly becoming) and most especially the early
userspace stuff. But before I assume you're making it up again I do need
to check your claims that these things have been addressed.

> Is there anything else that devfs can do that udev can't?  I have a
> whole list of things that udev can do that devfs can not :)

But I'll wager none (well, not if you exclude
features-that-aren't-features in my mind like "not being devfs" and "not
having device names in the kernel) that I can't accomplish just fine on
a devfs using system, right? You said yourself that udev isn't intended
to be a dynamic dev, that's just a fringe benefit. So there's absolutely
nothing stopping me using hotplug and sysfs with devfs - as I do right
now - to gain the features of udev without losing devfs.

> > After being forced to do so by the sudden surprise deprication of devfs
> > and the ensuing publicity to udev.
> 
> I have not forced _any_ company to do so.  I have not even _asked_ any
> company to do so.  I have simply been amazed that so many companies
> siezed on udev and brought it up to maturity and shipped it.  That tells
> me that people really wanted it and see the advantages of it over devfs.

Mysteriously and coincidentally in a great burst around the time devfs
was marked obsolete and you repeatedly commented that people needed to
switch away from devfs or risk getting caught where I am now? :)

> I have not heard any such issues in the past 6 months.  Hence my
> supprise now (well, not really supprise, I knew someone would complain,
> pretty amazed that it's only been one person in public (and one person
> privatly) so far.)

Because when patches to fix it get ignored, what else can one do? Who
wants to pipe up with "I like devfs" only to be told "you're stupid, if
you think you like devfs you don't understand udev" and knowing that
even saying so you don't really stand a chance of saving it?

> Then use the devfs mode of udev.  The devfs author even sent me updates
> in order to get them to work properly for his machines...

The names aren't my concern, the early-boot behaviour, partially static
nature, and other such incompatibilities are.

> I have never, until now, forced anyone to use udev. 

Technically true given the definition of the word "forced". But will you
not concede that the whole "OBSOLETE" thing, especially at such an early
stage in udev's maturity, was a good deal more of a strong-arm tactic
than the kernel usually sees?

> And even now, I'm not forcing anyone (there are other solutions to a
> dynamic /dev becides udev).

Yeah, the name of the userspace app doesn't mean a lot to me, they're
all forced to rely on the same kernel<=>userspace communication
mechanism and basically all work the same. I never complained about the
way udev handles its job in userspace, only about the removal of what
IMHO is a superior interface to kernelspace which offers things udev
alone cannot.

> I do feel, and it seems others agree, that udev is a far superior
> solution to the persistant device naming issue than devfs is

Wouldn't disagree with this. In fact, I'll come right out and say that
given the complete stagnation of devfs (which, I would argue, is not
entirely its own fault as you claim) and udev's rapid advances (based to
some degree I would argue on the attention it gained from things like
the marking of devfs obsolete) udev is the better solution today
(ignoring the migration headache and pretending both were completely new
systems introduced today, the features it offers that devfs doesn't are
worth much more than those devfs offers and udev doesn't, and it has a
much stronger community behind it).

But I also think that an even better solution could have been built
around the idea of a simple devfs that presented a single canonical
device file to userspace for each device and left the creation of
meaningful symlinks to an optional sysfs-using userspace helper. This
would have eliminated dependence on sysfs for the majority of systems I
know of, which rarely have custom rules giving more meaning to a device
than devfs currently presents, leaving me with all the features of devfs
I enjoy today and no migration headache, but a simple sysfs-using
userspace I could optionally apply to gain the features of udev. And
before you say something about "why didn't I then", I'd like to point
out that feature-wise I have that today, the only thing lacking is the
cleanups of devfs code, which really wasn't my primary concern and based
on the examples of others wouldn't have gotten in even if I had written
them.


So in closing, while I disagree with the whole way this has gone about,
in terms of things that can be done /now/ all I'm asking is that kernel
developers reevaluate the assumption that devfs is truly obsolete rather
than merely depricated, based on the fact that even after all this time
and energy udev is still not seen as a complete replacement by everyone.



From: Miles Bader [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Thu, 23 Jun 2005 15:14:08 +0900

Greg KH [email blocked] writes:
> And again, for embedded systems, there are packages to build it and put
> it in initramfs.  People have already done the work for you.

BTW, has anyone done a comparison of the space usage of udev vs. devfs
(including size of code etc....)?

Thanks,

-Miles
-- 
Run away!  Run away!



From: Greg KH [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Wed, 22 Jun 2005 23:26:27 -0700

On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:
> Greg KH [email blocked] writes:
> > And again, for embedded systems, there are packages to build it and put
> > it in initramfs.  People have already done the work for you.
> 
> BTW, has anyone done a comparison of the space usage of udev vs. devfs
> (including size of code etc....)?

Not that I know of.  If you want to do this, compare the original udev
releases that were around 5kb of code, as the nice features it has today
are stuff that devfs can not support at all.

thanks,

greg k-h



From: Miles Bader [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Thu, 23 Jun 2005 15:36:11 +0900

On 6/23/05, Greg KH [email blocked] wrote:
> Not that I know of.  If you want to do this, compare the original udev
> releases that were around 5kb of code, as the nice features it has today
> are stuff that devfs can not support at all.

That wouldn't be such an effective tool for convincing people to
switch though... :-)  "Look this obsolete version is much smaller!"

If udev has really bloated up due to whizzy new features, how hard
would it be to compile a stripped-down version?  [Well I should look
at the busybox support somebody mentioned -- perhaps it's exactly
that.]

-Miles
-- 
Do not taunt Happy Fun Ball.



From: Greg KH [email blocked]
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date:	Thu, 23 Jun 2005 00:03:09 -0700

On Thu, Jun 23, 2005 at 03:36:11PM +0900, Miles Bader wrote:
> On 6/23/05, Greg KH [email blocked] wrote:
> > Not that I know of.  If you want to do this, compare the original udev
> > releases that were around 5kb of code, as the nice features it has today
> > are stuff that devfs can not support at all.
> 
> That wouldn't be such an effective tool for convincing people to
> switch though... :-)  "Look this obsolete version is much smaller!"
> 
> If udev has really bloated up due to whizzy new features, how hard
> would it be to compile a stripped-down version?  [Well I should look
> at the busybox support somebody mentioned -- perhaps it's exactly
> that.]

It wouldn't be that hard at all, just look at the first couple of
releases for example code to use (you would want it to be a totally
separate project, the current udev is not ment for such a stripped down
thing, it's ment to take over all of the /sbin/hotplug funcionality,
through netlink no less.)

thanks,

greg k-h



From: Greg KH [email blocked]
Subject: [PATCH] devfs: remove devfs from Kconfig preventing it from being built
Date:	Tue, 21 Jun 2005 15:24:19 -0700

Here's a much smaller patch to simply disable devfs from the build.  If
this goes well, and there are no complaints for a few weeks, I'll resend
my big "devfs-die-die-die" series of patches that rip the whole thing
out of the kernel tree.

Signed-off-by: Greg Kroah-Hartman [email blocked]

---
 fs/Kconfig |   50 --------------------------------------------------
 1 files changed, 50 deletions(-)

--- gregkh-2.6.orig/fs/Kconfig	2005-06-21 14:46:34.000000000 -0700
+++ gregkh-2.6/fs/Kconfig	2005-06-21 14:48:27.000000000 -0700
@@ -741,56 +741,6 @@
 
 	Designers of embedded systems may wish to say N here to conserve space.
 
-config DEVFS_FS
-	bool "/dev file system support (OBSOLETE)"
-	depends on EXPERIMENTAL
-	help
-	  This is support for devfs, a virtual file system (like /proc) which
-	  provides the file system interface to device drivers, normally found
-	  in /dev. Devfs does not depend on major and minor number
-	  allocations. Device drivers register entries in /dev which then
-	  appear automatically, which means that the system administrator does
-	  not have to create character and block special device files in the
-	  /dev directory using the mknod command (or MAKEDEV script) anymore.
-
-	  This is work in progress. If you want to use this, you *must* read
-	  the material in <file:Documentation/filesystems/devfs/>, especially
-	  the file README there.
-
-	  Note that devfs no longer manages /dev/pts!  If you are using UNIX98
-	  ptys, you will also need to mount the /dev/pts filesystem (devpts).
-
-	  Note that devfs has been obsoleted by udev,
-	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/&gt;.
-	  It has been stripped down to a bare minimum and is only provided for
-	  legacy installations that use its naming scheme which is
-	  unfortunately different from the names normal Linux installations
-	  use.
-
-	  If unsure, say N.
-
-config DEVFS_MOUNT
-	bool "Automatically mount at boot"
-	depends on DEVFS_FS
-	help
-	  This option appears if you have CONFIG_DEVFS_FS enabled. Setting
-	  this to 'Y' will make the kernel automatically mount devfs onto /dev
-	  when the system is booted, before the init thread is started.
-	  You can override this with the "devfs=nomount" boot option.
-
-	  If unsure, say N.
-
-config DEVFS_DEBUG
-	bool "Debug devfs"
-	depends on DEVFS_FS
-	help
-	  If you say Y here, then the /dev file system code will generate
-	  debugging messages. See the file
-	  <file:Documentation/filesystems/devfs/boot-options> for more
-	  details.
-
-	  If unsure, say N.
-
 config DEVPTS_FS_XATTR
 	bool "/dev/pts Extended Attributes"
 	depends on UNIX98_PTYS

• Archive of above thread
• KernelTrap interview with Andrew Morton