A recent posting to the lkml suggested that the udev project has unfairly hijacked the devfs project, leading into yet another lengthy discussion comparing udev to devfs, and questioning why the latter has been deprecated. Linux devfs was written by Richard Gooch and merged into the 2.3.46 kernel in February of 2000. Since that time, Richard has stopped maintaining it, though a number of issues remain. During the 2.5 release cycle others such as Andrey Borzenkov have contributed fixes, though problems evidently remain with the actual design.

As early as 2001, Greg Kroah-Hartman began developing udev, working to implement the same functionality as devfs, but in userspace. Currently at version 010 [story], though not complete, udev is quite functional. For a good understanding of how it works, refer to this pdf from Greg's 2003 OLS talk. During the recent lkml discussion, 2.6 maintainer Andrew Morton acknowledged that though it has "architectural/cleanliness issues [...] devfs shall remain in 2.6 and shall continue to be supported." He went on to explain:

"Nor would I recommend that devfs be removed early from 2.7.x. We should wait until the proposed udev/sysfs solutions have matured in 2.6 and have proven themselves in the field. Only then will we be in a position to confirm that devfs can be removed without causing some people unacceptable levels of grief. There is no rush."

From: Bradley W. Allen [email blocked]
To:  linux-kernel
Subject: Re:  DevFS vs. udev
Date: Tue, 23 Dec 2003 03:51:58 -0800

DevFS was written by an articulate person who solved a lot of
problems.  udev sounds more like a thug who's smug about winning,
not explaining himself, saying things like "oh, the other guy
disappeared, so who cares, you have to use my code, too bad it sucks".

Just by what the udev people have said I have decided never to use it,
and to return to DevFS.  Thank god for linux-kernel archives.

A few points:

*  User space is slow, causing all sorts of extra work for device
   accesses.
*  Another layer of filesystem for udev to have to interact with
   is also slow, especially if it has to be disk based with all sorts
   of extra caches, and also if it's with buggy tmpfs code and layers.
*  Most of the interesting devices I have now are character devices,
   and have multiple potential /dev entries per device.  I've heard
   that udev can't even handle that requirement!
   Udev has lots of other problems, like something called an anonymous
   device, and it not being fully implemented, however, that's OK for
   development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
   solid for over half a decade, so it belongs in stable kernels.
*  Many times a broken record comes out with claims.  Here are a few:
   "... there are still unfixable devfs bugs in the code." without
   any examples, so I don't believe him (Greg K-H).  Others have looked
   and not found that.
*  Userspace is not the proper place for kernel device drivers or
   anything they need to work.
*  We do not need the same old maintainer for devfs.  We can create
   new code, and maintain old code, as a group, ourselves.
*  Greg K-H (what that dash is for I can't imagine) claims that DevFS
   is experimental and proof of concept; well, it has been in production
   use for over half a decade, which in the life of Linux is pretty long.
   It's certainly not just some experiment any more.
*  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
   things that most Linux kernel compilers, linux-kernel readers, and
   DevFS users (including lots of admins) have probably never ever
   heard of except the bad attitude of the hahaha part.
*  Someone named viro said "the latter had stayed, period" refering to
   udev, which means absolutely nothing, but expected it to mean
   something.
*  Viro also said that devfs had been "shoved" into the tree, and
   that it "had stayed around for many months".  It's been stable for
   many *YEARS*, for most of a *DECADE*.

I've spent two hours on this problem, and that's absurd; stable shouldn't
be doing this sort of thing to us.  Yes, we know there are things that
happen during transition from development to stable, but to have some
terrorist hijack part of the kernel and destroy it right at the begin-
ing of stable is simply criminal thinking.  Luckily, this is just
software, so we can do what we want with it, but organizationally it
is conceptually just as bad.



From: Paul Dickson [email blocked]
Subject: Re: DevFS vs. udev
Date: Tue, 23 Dec 2003 07:30:52 -0700

On Tue, 23 Dec 2003 03:51:58 -0800, Bradley W. Allen wrote:

> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".
> 
> Just by what the udev people have said I have decided never to use it,
> and to return to DevFS.  Thank god for linux-kernel archives.

Nice piece of FUD you've written without really understanding what devfs
and udev do.  This devfs vs udev issue has become emotional, and it's
starting to slip into name calling.

Devfs had reached its design limits and the maintainer gave up on it,
mostly because the support was too painful for other kernel developers.
It's still in 2.6, just don't expect fixes for areas that don't (and
can't) work.

I use devfs for my router I threw together, but I fully expect to switch
to udev once all the missing /dev support is added in 2.6.1 or 2.6.2.

Devfs is deprecated.  This means it's still available but you should
consider moving to other options when available.  Obsolete means it
shouldn't be used.  Some 2.6 docs have confused these two terms WRT devfs.


> A few points:
> 
> *  User space is slow, causing all sorts of extra work for device
>    accesses.
> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

udev is not used for device access.  The /dev devices are no slower than a
static /dev directory or a devfs /dev directory.


> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!
>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
>    solid for over half a decade, so it belongs in stable kernels.

Udev is not a finished or fully functional project in 2.6.0, but neither
is devfs (and, as you mentioned, devfs has had five years).


> *  Many times a broken record comes out with claims.  Here are a few:
>    "... there are still unfixable devfs bugs in the code." without
>    any examples, so I don't believe him (Greg K-H).  Others have looked
>    and not found that.

A large chunk of devfs code was removed during 2.5 development if I recall
correctly.  I believe is was mostly unused so I haven't missed it.

Perhaps you should depend on the hearsay of others.  Either listen to the
kernel developers or figure out the locking code within the kernel
yourself.


> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

Device drivers do not need /dev to function, only userspace needs these. 
Configuring userspace should be done in userspace, IMHO.


> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

As I mentioned, devfs had reach limits in it's design and to push past
this would require added complexity to other areas of the kernel. 
Complexity that would make maintainability harder.

Designs that don't work are eventually replaced with those that do.


> *  Greg K-H (what that dash is for I can't imagine) claims that DevFS
>    is experimental and proof of concept; well, it has been in production
>    use for over half a decade, which in the life of Linux is pretty long.
>    It's certainly not just some experiment any more.

Careful, you're starting to drop into name calling.

Devfs has problems.  It's being replace during the life of the 2.6 kernel
with something that hopefully won't have as many problems.  This is the
norm for software development.


> *  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
>    things that most Linux kernel compilers, linux-kernel readers, and
>    DevFS users (including lots of admins) have probably never ever
>    heard of except the bad attitude of the hahaha part.

So udev documentation is a bit scarce.  So don't use it.  Continue to use
devfs or a static /dev until you find documentation good enough for you to
understand or you find some else's example to copy.


> *  Someone named viro said "the latter had stayed, period" refering to
>    udev, which means absolutely nothing, but expected it to mean
>    something.

Reading http://kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ, I take
the part you quote as meaning: the unfixable bugs in devfs, since the
section was about devfs.


> *  Viro also said that devfs had been "shoved" into the tree, and
>    that it "had stayed around for many months".  It's been stable for
>    many *YEARS*, for most of a *DECADE*.
>
> I've spent two hours on this problem, and that's absurd; stable shouldn't
> be doing this sort of thing to us.  Yes, we know there are things that
> happen during transition from development to stable, but to have some
> terrorist hijack part of the kernel and destroy it right at the begin-
> ing of stable is simply criminal thinking.  Luckily, this is just
> software, so we can do what we want with it, but organizationally it
> is conceptually just as bad.

Getting closer and closer to name calling...

If you don't like udev, don't use it.  It's as simple as that for the
moment.  Since 2.6.0 shipped with devfs deprecated, it's conceivable,
although unlikely, that devfs could be removed once a udev-like project is
fully functional.

You did not mention how you're using devfs.  Your comments don't suggest a
lot of experience with it either.

	-Paul Dickson



From: Greg KH [email blocked]
Subject: Re: DevFS vs. udev
Date: Tue, 23 Dec 2003 13:59:10 -0800

On Tue, Dec 23, 2003 at 03:51:58AM -0800, Bradley W. Allen wrote:
> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".

Huh?  I sound like a thug?  I might look like one at times, smell like
one lots of times, but I didn't think I typed like one...

> Just by what the udev people have said I have decided never to use it,
> and to return to DevFS.  Thank god for linux-kernel archives.
> 
> A few points:
> 
> *  User space is slow, causing all sorts of extra work for device
>    accesses.

What do you mean by this.  What is too slow for you?  Have you timed
udev vs. devfs?  Yes, udev-010 now takes a whole second to band-aid over
a race condition in the udev code, but that will be fixed up...

And that's only 1 second from inserting a device into the system.  Is
this a problem with some kind of hardware or real-time devices that you
are using?  Do you have to be able to access the device in the least
possible amount of time?  If so, what's your timing constraints you are
working with?

> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

What "extra layer of filesystem" are you talking about?  sysfs?  Hey,
sysfs isn't going away at all.  Reading from a ramfs filesystem is
_fast_, no disk accesses at all.

What do you mean by "buggy tmpfs code and layers"?  sysfs uses libfs and
is a ramfs-like filesystem.  It isn't tmpfs.  And if you've found some
bugs, people are interested in finding them.

> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!

Where did you hear this?  It isn't true.  I have a multi-port usb serial
device with 16 /dev entries for a single device.  Works just fine.

>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.

What kind of device exactly are you talking about?

>    DevFS has been solid for over half a decade, so it belongs in
>    stable kernels.

5 years stability?  Hm, oh well, please check the lkml archives and the
udev FAQ for the reasons why devfs is broken and can not be fixed.

> *  Many times a broken record comes out with claims.  Here are a few:
>    "... there are still unfixable devfs bugs in the code." without
>    any examples, so I don't believe him (Greg K-H).  Others have looked
>    and not found that.

Heh, see the archives for where these claims were made by Al Viro and
backed up with real examples.

> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

What do you mean by this?  Userspace is where the device node lives, on
a filesystem, that's it.

> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

Are you volunteering?

> *  Greg K-H (what that dash is for I can't imagine) claims that DevFS
>    is experimental and proof of concept; well, it has been in production
>    use for over half a decade, which in the life of Linux is pretty long.
>    It's certainly not just some experiment any more.

Where did I claim this?  And the '-' is part of my name, if you want you
can spell the whole thing out every time.

> *  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
>    things that most Linux kernel compilers, linux-kernel readers, and
>    DevFS users (including lots of admins) have probably never ever
>    heard of except the bad attitude of the hahaha part.

Hm, sorry for trying to lend a bit of humor at times.  My 2003 udev
paper is well documented (try googling for it) and is contained in the
udev tarball.  sysfs is also well documented in a linux.conf.au paper by
it's author, Pat Mochel.

> I've spent two hours on this problem, and that's absurd; stable shouldn't
> be doing this sort of thing to us.

What problem is this?  Have you posted with questions on how to set up
udev properly for you?

> Yes, we know there are things that happen during transition from
> development to stable, but to have some terrorist hijack part of the
> kernel and destroy it right at the begin- ing of stable is simply
> criminal thinking.  Luckily, this is just software, so we can do what
> we want with it, but organizationally it is conceptually just as bad.

I welcome you as the new devfs maintainer.  I'm not forcing anyone to
not use devfs, just realize that there are problems with it, and it will
probably go away in the future.

thanks,

greg k-h

/me sighs...



From: Ian Kent [email blocked]
Subject: Re: DevFS vs. udev
Date: Wed, 24 Dec 2003 09:52:00 +0800 (WST)

On Tue, 23 Dec 2003, Greg KH wrote:

>
> Are you volunteering?

Well I was. That was the point of my post which started this again. Sorry.

Seems to me that the best way to remedy this unrest is to have someone
accept maintenance of devfs and when/if it is not used to remove it
from the kernel then.

It certainly seems like a good project for a someone, such as myself, that
is new to kernel development.

However, if Andrew wants it gone from the kernel there is no point.

Ian



From: Rob Love [email blocked]
Subject: Re: DevFS vs. udev
Date: Tue, 23 Dec 2003 21:03:57 -0500

On Tue, 2003-12-23 at 20:52, Ian Kent wrote:

> It certainly seems like a good project for a someone, such as myself, that
> is new to kernel development.

Please take no offense to this, but it is an awful project for someone
new to kernel development.  Plenty of knowledgeable/semi-knowledgeable
kernel hackers looked at devfs and given up on it.  Despite what some
people say about Richard, he is a good guy, and he did not succeed
either.

devfs is hard to get right and, worse, you will be starting with a bad
base of code that I would not want to touch with an 18.72 foot pole.

Greg, via udev, has made it so easy to just back up, slowly, and walk
away from devfs.  devfs is not going anywhere in 2.6, I do not think,
but let sleeping piles of crap sleep and let's just jettison this thing
as soon as we can.

Just my two cents - I am warning you ;)

	Rob Love



From: Andrew Morton [email blocked]
Subject: Re: DevFS vs. udev
Date: Tue, 23 Dec 2003 18:38:20 -0800

Ian Kent [email blocked] wrote:
>
> However, if Andrew wants it gone from the kernel there is no point.

I do not.  devfs shall remain in 2.6 and shall continue to be supported.

Richard has disappeared but Andrey Borzenkov understands devfs well and
performed valuable work on it during 2.5 development.


Nor would I recommend that devfs be removed early from 2.7.x.  We should
wait until the proposed udev/sysfs solutions have matured in 2.6 and have
proven themselves in the field.  Only then will we be in a position to
confirm that devfs can be removed without causing some people unacceptable
levels of grief.    There is no rush.


And yes, there are architectural/cleanliness issues with devfs.  In 2.5
Adam Richter totally reinventing devfs's internals, basing it around the
ramfs infrastructure.  If we elect to retain devfs in 2.8 then that effort
should be resurrected.


Now would be a good time for someone to feed the whole thing through indent
though.



From: Al Viro [email blocked]
Subject: Re: DevFS vs. udev
Date: Wed, 24 Dec 2003 03:41:21 +0000

On Tue, Dec 23, 2003 at 06:38:20PM -0800, Andrew Morton wrote:
 
> And yes, there are architectural/cleanliness issues with devfs.  In 2.5
> Adam Richter totally reinventing devfs's internals, basing it around the
> ramfs infrastructure.  If we elect to retain devfs in 2.8 then that effort
> should be resurrected.

Switching internals to ramfs won't be enough, though.  There are problems
with devfs API that can't be solved by work on internals - lifetime rules
for devfs nodes make no sense.  Take a look at the insertion/removal
primitives and think of the lifetime rules they create for directories and
user-created nodes.  _That_ is independent from the way you implement
the internals (and sanitized version of the interface won't fit into
use of ramfs, BTW).

From: Rusty Russell [email blocked]
Subject: Re: DevFS vs. udev
Date: Wed, 24 Dec 2003 15:13:14 +1100

On Tue, 23 Dec 2003 03:51:58 -0800
"Bradley W. Allen" [email blocked] wrote:

> DevFS was written by an articulate person who solved a lot of
> problems.  udev sounds more like a thug who's smug about winning,
> not explaining himself, saying things like "oh, the other guy
> disappeared, so who cares, you have to use my code, too bad it sucks".

Badley, you've made an unvaluable contribution today.  The least I can
do is punctuate your words with my own thoughts, below:

> *  User space is slow, causing all sorts of extra work for device
>    accesses.

Hey, I didn't realize that!  It seems so unlikely.

> *  Another layer of filesystem for udev to have to interact with
>    is also slow, especially if it has to be disk based with all sorts
>    of extra caches, and also if it's with buggy tmpfs code and layers.

I hear you: if it were slow and buggy, it *would* be slow and buggy.
I had never really thought of it in that way before.

> *  Most of the interesting devices I have now are character devices,
>    and have multiple potential /dev entries per device.  I've heard
>    that udev can't even handle that requirement!

Now, I've heard that too!

>    Udev has lots of other problems, like something called an anonymous
>    device, and it not being fully implemented, however, that's OK for
>    development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
>    solid for over half a decade, so it belongs in stable kernels.

And who's thinking about the poor users?  Their upturned faces, full of
trust and love: their shining lack of experience, unstained by harsh
knowledge of programming realities.  These people have needed a voice:
a hero if you will.

> *  Userspace is not the proper place for kernel device drivers or
>    anything they need to work.

Agreed.  Not to put it too harshly, these "kernel hackers" are cruel
overlords, jealously guarding their free code from the users who need it.

It's time for the USERS to rise up and speak.  But who will speak for
them?  Who?

> *  We do not need the same old maintainer for devfs.  We can create
>    new code, and maintain old code, as a group, ourselves.

You're right: WE know what we want!  All we need is someone like US:
close to the users, NOT close to the code!

> *  Viro also said that devfs had been "shoved" into the tree, and
>    that it "had stayed around for many months".  It's been stable for
>    many *YEARS*, for most of a *DECADE*.

This Viro, he's another one of these oppressive "coders", right?
It seems pretty clear that we need LESS coders making technical
decisions which effect users, an MORE users making technical
decisions!

> I've spent two hours on this problem, and that's absurd

After reading the precision and sophistication of your prose, your
grasp of technical content is clear.  Finding out that you'd spent two
hours on *anything* technical is shocking to me.

> Luckily, this is just software, so we can do what we want with it, but
> organizationally it is conceptually just as bad.

Reading this last sentence brought tears to my eyes.  Really.

I think I speak for most people on this list when I say that the kernel
NEEDS people like you like we need devfs itself.  I remember in 2.3, when
we all needed devfs badly, and that's how we got it: we needed it, and
it went in.  Now those same people who didn't want it in the first place
want it removed.

Badley, I ask you in all seriousness: will you take up the challenge,
and fill the gaping hole which we've all felt for so long in the Linux
community?  To give raw, unvarnished feedback, unconfused by the
complexities of code?

I, for one, see the future lies in your posts.
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

From: Jari Soderholm [email blocked]
Subject: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 23:20:18 +0200

Hello !

I am quite advanced Linux user who has used DEVFS quite
long time, and have also been a little suprised that it
has been marked OBSOLETE in 2.6 kernel.

I think that there are plenty good arguments why in many
cases it is technically better solution than udev, and
I like to give my view on that.

DEVFS is a really simple to use, compile it into kernel and configure the programs 
to use DEVFS filenames and thats it.

I think that it is very good that devicename files are out from the disk, one 
cannot delete those files, disk errors do not affect the, and searching device 
files is faster.

Booting kernel is faster compared to UDEV.

And DEVFS has worked for years for me at least very well, I haven't had any 
problems with it.

I do not understand some opinions that DEVFS uses memory.
Compared to the size of applications people run in linux
, the memory what kernel with DEVFS takes is practically
nonexistent.
I think that files in SYSFS-directory (needed by UDEV) probably take more memory 
than those in DEVFS-dir.

UDEV otherwise is very complex for average user and it
is definetly much slower , it has much greater chance
for errors because very complicated scrips which seem 
to need many different gnu commandline utilities.

It is quite funny that when DEVFS creates device files
automagically and in the ram-memory, some people want
to go backwards, and use shell scripts to 
create those files on hard disk, and then it is technically better solution.

If one you look at the /sysfs-directory there are
device filenames, (but not the actual devicefiles), so
it does same thing that DEVFS, but actually much worce
way, it created devicefilenames in the ram, but
one cannot use them, because they are not devicefiles.

Why could you develop it so that UDEV could create those
actual device files there also, then most linux
users would not need those horrible scipts anymore.
All that is then needed link from /sysfs to /dev dir.

In my option good operating system kernel should use disk and external programs 
little as possible.

T Jari Söderholm
jari.soderholm#stadia.fi



From: Rob Love [email blocked]
Subject: Re: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 17:01:24 -0500

On Tue, 2003-12-23 at 16:20, Jari Soderholm wrote:

(please use a mailer that wraps lines, in the future)

> I am quite advanced Linux user who has used DEVFS quite
> long time, and have also been a little suprised that it
> has been marked OBSOLETE in 2.6 kernel.

devfs is marked obsolete for more reasons that just the presence of
udev.  Devfs is also buggy, poorly designed, and unmaintained.

> DEVFS is a really simple to use, compile it into kernel and configure
> the programs to use DEVFS filenames and thats it.

udev, in time, we be even easier than this: just install it.  It will
use the historic kernel naming (FHS names) so you need not change your
programs, although a devfs-style naming policy is possible

> I think that it is very good that devicename files are out from the disk,
> one cannot delete those files, disk errors do not affect the, and searching
> device files is faster.

udev can store files on a tmpfs (or any other) mount, if so desired.

> Booting kernel is faster compared to UDEV.

Today, udev is not even involved in booting, so this cannot possible be
true.  If you mean running the udev initscript is slow, perhaps it is:
but eventually that will not be needed.

Also, udev is nascent and still under development.  It has not been
fine-tuned yet.

> And DEVFS has worked for years for me at least very well, I haven't
> had any problems with it.

Lucky you.  It is a mess.

> I do not understand some opinions that DEVFS uses memory.
> Compared to the size of applications people run in linux
> , the memory what kernel with DEVFS takes is practically
> nonexistent.

I never heard this argument, actually, and I agree it is not an
important one.

> UDEV otherwise is very complex for average user and it
> is definetly much slower , it has much greater chance
> for errors because very complicated scrips which seem 
> to need many different gnu commandline utilities.

The user will never have to do with the command line stuff.  And udev
does not involve any complicated scripts.

And, as I said, I do not yet buy the slower argument.

> It is quite funny that when DEVFS creates device files
> automagically and in the ram-memory, some people want
> to go backwards, and use shell scripts to 
> create those files on hard disk, and then it is technically better solution.

udev is not a shell script and, as I said, udev can use _anything_ as
its backing store -- whether that is a directory on your root partition,
an NFS mount, or a tmpfs mount.

> If one you look at the /sysfs-directory there are
> device filenames, (but not the actual devicefiles), so
> it does same thing that DEVFS, but actually much worce
> way, it created devicefilenames in the ram, but
> one cannot use them, because they are not devicefiles.

sysfs is a tree of the kernel's in-memory representation of devices.

We do _not_ want to put the device naming policy in the kernel. 
User-space should handle that.

> Why could you develop it so that UDEV could create those
> actual device files there also, then most linux
> users would not need those horrible scipts anymore.
> All that is then needed link from /sysfs to /dev dir.

This was proposed before, and certainly do-able.  Someone (Linus, I
think?) shot it down.

But this is not a huge step from current udev.  Is it that big a deal
whether the device nodes are created new or symlinked?  It is the same
solution, either way.

> In my option good operating system kernel should use disk and external
> programs little as possible.

In my opinion, good operating system kernels should be wise to correctly
delineate between what should be in user-space and what should be in the
kernel.

	Rob Love



From: Hua Zhong [email blocked]
Subject: RE: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 14:21:03 -0800

> On Tue, 2003-12-23 at 16:20, Jari Soderholm wrote:
> 
> (please use a mailer that wraps lines, in the future)
> 
> > I am quite advanced Linux user who has used DEVFS quite
> > long time, and have also been a little suprised that it
> > has been marked OBSOLETE in 2.6 kernel.
> 
> devfs is marked obsolete for more reasons that just the presence of
> udev.  Devfs is also buggy, poorly designed, and unmaintained.

I do not care about devfs, and I believe/trust udev is a better
approach.

But I do have sth fair to say about this "unmaintained" part.

>From my memory, at some point in time, somebody (Al Viro?) reviewed
devfs code and flamed the author in public (klml), throwing lots of bad
impolite words to him, which I think was the biggest reason that the
author stopped maintaining it. This was one of the projects that got
killed by flames, or improper handling with flames (another one that
comes to mind is CML2).

Correct (but not flame :-) me if I am wrong.



From: Rob Love [email blocked]
Subject: RE: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 17:30:04 -0500

On Tue, 2003-12-23 at 17:21, Hua Zhong wrote:

> But I do have sth fair to say about this "unmaintained" part.
> 
> From my memory, at some point in time, somebody (Al Viro?) reviewed
> devfs code and flamed the author in public (klml), throwing lots of bad
> impolite words to him, which I think was the biggest reason that the
> author stopped maintaining it. This was one of the projects that got
> killed by flames, or improper handling with flames (another one that
> comes to mind is CML2).
> 
> Correct (but not flame :-) me if I am wrong.

Well, Al definitely shot forth many flames over devfs, for sure :)

I do not know the time line of the flames vs. any decisions made by
Richard, though.  Some flamage was definitely earlier, when Richard was
active, and some flames were definitely after Richard scaled back his
kernel development.  And, yes, Al flames very hard and a bit rude -- but
I have never seen him wrong, that is for sure ;-)

So I cannot comment over _why_ defvs is unmaintained, but that is not
the point: either way, it stands that devfs is unmaintained.  That is a
problem in and of itself.

	Rob Love



From: Hua Zhong [email blocked]
Subject: RE: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 15:00:43 -0800

> I do not know the time line of the flames vs. any decisions made by
> Richard, though.

I believe this is what I saw but I am not exactly sure:

http://www.ussg.iu.edu/hypermail/linux/kernel/0110.3/0712.html

And at that time Richard claimed he was still active.

> And, yes, Al flames very hard and a bit rude -- but
> I have never seen him wrong, that is for sure ;-)

Me neither :-) and when he is not flaming me (which I have not got the
chance yet), it's fun to read. But I hate him, you know, because I now
tend to be influenced by the way he (and several others on this list)
writes emails, and that's not nice in a corporate environment!!

> So I cannot comment over _why_ defvs is unmaintained, but that is not
> the point: either way, it stands that devfs is unmaintained.  
> That is a problem in and of itself.

It's just my impression that around that time core developers had
decided to replace devfs with a new model. If I were in ths same shoes,
I would probably also stop maintaining it. Then 2 years later when
somebody asks, the reason to replace my code shouldn't be
"unmaintained". Just the technical reasons should be enough. :-)

> 	Rob Love



From: Al Viro [email blocked]
Subject: Re: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 23:26:27 +0000

On Tue, Dec 23, 2003 at 03:00:43PM -0800, Hua Zhong wrote:
 
> Me neither :-) and when he is not flaming me (which I have not got the
> chance yet), it's fun to read. But I hate him, you know, because I now
> tend to be influenced by the way he (and several others on this list)
> writes emails, and that's not nice in a corporate environment!!

Why, thank you.  It's a bit early for New Year present, but it certainly
makes a good one ;-)



From: Rob Love [email blocked]
Subject: RE: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 18:03:23 -0500

On Tue, 2003-12-23 at 18:00, Hua Zhong wrote:

> Me neither :-) and when he is not flaming me (which I have not got the
> chance yet), it's fun to read. But I hate him, you know, because I now
> tend to be influenced by the way he (and several others on this list)
> writes emails, and that's not nice in a corporate environment!!

You should not hate anyone.  But especially not Al.

> It's just my impression that around that time core developers had
> decided to replace devfs with a new model. If I were in ths same shoes,
> I would probably also stop maintaining it. Then 2 years later when
> somebody asks, the reason to replace my code shouldn't be
> "unmaintained". Just the technical reasons should be enough. :-)

Sure.  But, it is unmaintained today, regardless of why, and that is a
factor in deciding how to proceed.

	Rob Love



From: Greg KH [email blocked]
Subject: Re: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 15:14:57 -0800

On Tue, Dec 23, 2003 at 03:00:43PM -0800, Hua Zhong wrote:
> > So I cannot comment over _why_ defvs is unmaintained, but that is not
> > the point: either way, it stands that devfs is unmaintained.  
> > That is a problem in and of itself.
> 
> It's just my impression that around that time core developers had
> decided to replace devfs with a new model. If I were in ths same shoes,
> I would probably also stop maintaining it. Then 2 years later when
> somebody asks, the reason to replace my code shouldn't be
> "unmaintained". Just the technical reasons should be enough. :-)

Back in June of 2001, Pat Mochel and I talked with Richard about this
whole driver model, sysfs, and udev design at the 2001 kernel summit,
after presenting it to all of the other kernel developers.  He had some
objections, but was very aware of what we wanted to do.

It's not like udev and this whole sysfs / driver model implementation
snuck into the kernel late at night when no one else was looking, and
pounced on all of the poor, unsuspecting devfs users, eating them for a
early morning snack.


greg k-h

• Archive of above thread
• KernelTrap interview with Rob Love
• KernelTrap interview with Andrew Morton
• KernelTrap interview with Rusty Russell