DEVFS is very good compared to UDEV
Jari Soderholm
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 t=
he programs to use DEVFS filenames and thats it.
I think that it is very good that devicename files are out from the dis=
k, 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 mo=
re 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 solu=
tion.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Stan Bubrouski
> 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.
>
If you were such an advanced Linux user you'd read this list or at leas=
t
search it to understand the problems. DevFS may have seemed fine to
you, but the code is nasty and full of races. It's overly complicated
and the problems it exhibits were determined to not be easily fixable
and not worth the time. DevFS never really took off and it was under
development for a good part of 4 years. Richard Gooch did an admirable
job trying to come up with a new solution to the old /dev situation, bu=
t
frankly a new approach was needed, and he himself recognized this and
abandoned devfs.
> 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.
>
How do you know this? Have you looked at the code to both? You can't
be telling me you've looked at the devfs code and think its superior in
any way to other pitiful hacks in the kernel. Come on now. And UDEV
and libsysfs are works in progress, and I must say they've come a long
way in a very short time. Kudos to Greg and others BTW.
> DEVFS is a really simple to use, compile it into kernel and configure=
the programs to use DEVFS filenames and thats it.
>
Userspace can adapt to a different solution.
> I think that it is very good that devicename files are out from the d=
isk, one cannot delete those files, disk
> errors do not affect the, and searching device files is faster.
>
UDEV is currently slow right now while some libsysfs changes are being
made IIRC. Not a very apt comparison.
> Booting kernel is faster compared to UDEV.
>
See above.
> And DEVFS has worked for years for me at least very well, I haven't h=
ad any problems with it.
>
Consider yourself lucky.
> 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.
>
How on earth do you figure this? The /sys directory is links to things
that are already in memory, it is just providing a way to access those
structures and information, think procfs.
> 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's still young and will be better as time passes. At least UDEV isn'=
t
going to take 4 years and come out with crap.
> 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 so=
lution.
>
Honestly I'm trying to sound insulting here, but consider the fact that
only a couple of people are currently working on UDEV, and yeah some
things are hacked together right now. And remember init is mostly shel=
l
scripts, I don't see how this is so inferior.
> 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.
>
*sigh* see above
> 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.
>
*sigh* read the FAQ
> In my option good operating system kernel should use disk and externa=
l programs little as possible.
>
Here we go, IMO, I like that :) The thing is, you need some cooperatio=
n
and balance between the kernel and userspace. Things are shelled off t=
o
userspace because they can be, and it also takes burden off the core
kernel functions and reduces the kernel's memory footprint. This is
good for embedded devices too.
Ok for the sake of non-argument, keep using devfs if you want, but
remember it is obsolete, and nothing is going to change that AFICS.
Good Luck,
sb
> T Jari Söderholm
> jari.soderholm#stadia.fi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kerne=
l" in
Rob Love
(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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hua Zhong
>
> (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.
Felipe Alfaro Solana
> 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.
Well, udev way of doing things is very similar to Solaris. While booting
with -r, or by creating /.reconfigure, Solaris kernel scans the hardware
and creates entries in /devices tree. The /dev entries are just symlinks
to /devices entries.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Rob Love
> 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
Hua Zhong
> 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. :-)
gru...@teleline.es
bió:
> From my memory, at some point in time, somebody (Al Viro?) reviewed
> devfs code and flamed the author in public (klml), throwing lots of b=
ad
> 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).
I think the problem with CML2 was the author not willing to submit
CML2 in small patches adressing single problems instead of One Big Patc=
h.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Rob Love
> 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.
vi...@parcelfarce.linux.theplanet.co.uk
> 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.
Oh, really? That "flame in public" was after _many_ months of pointing
to the same problems in private - with zero effect.
If maintainer sits on exploitable holes for ~18 months and does not care to do
anything, his code is unmaintained. If same maintainer keeps pretending in
public that everything is fine, he can expect to have the truthfulness of his
statements challenged. Also in public. If the situation persists even after
that, then yes, there will be rather unflattering things to say.
Don't delude yourself - critical parts of devfs had not been maintained for
quite a while before Richard had disappeared. It's not the effect of flames
- it's their cause and it predates them by _far_.
Greg KH
> > 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
vi...@parcelfarce.linux.theplanet.co.uk
> 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 ;-)
Mike Fedyk
> Why, thank you. It's a bit early for New Year present, but it certainly
> makes a good one ;-)
It's not the 25th yet, so it's not too early for that day. ;)
Paul Jackson
Well before that flame fest, Richard would joke about he
had a talent for attracking flames.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
Albert Cahalan
> On Tue, 2003-12-23 at 16:20, Jari Soderholm wrote:
>> 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.
That may be, but at least the idea wasn't defective.
>> 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
How quickly we forget where those names came from!
Richard Gooch originally used the traditional names.
Linus ordered the names changed as a condition for
acceptance into the kernel. Of course, that led to
devfsd being a requirement, which kind of took away
the whole point of using devfs.
The Linus-approved names made devfs a pain to use,
so few people used devfs and fewer helped out.
Richard is only to blame for his inability to spell
/dev/disk correctly. For that, he belongs in "jail"
with a "j". It was enough of an eyesore to make me
give up on devfs.
>> 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.
That can be done. It is neither clean nor fast.
It's a nasty hack to emulate a proper devfs.
>> 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.
Certainly. It amuses me to no end watching sysfs
mutate into /proc++ and udev growing day by day.
Do you remember all the trash-talking about how
sysfs was going to be a strict and clean view of
the power management dependencies instead of a
bloated mess that slurps in random functionality
like /proc does?
Let's just get it over with: per-process XML
in /sys, built-in SQL engine, CJK i18n, an ASN.1
view of it all, and /sys/bin/GnomeMailReader.
>> 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 can well imagine not trusting it for a serious
multi-user shell box. It works for others.
>> 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.
Uh huh. They're named in /sys though, and on the
kernel command line for root and console.
We might as well admit to the truth here.
>> 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.
Excellent. So we could have a real devfs, based on
kernel code that is supposedly more solid.
>> 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.
There is no "correct". There are desktop systems,
stripped-down embedded boxes, full-featured embedded
boxes, business servers, compute cluster nodes...
An optional devfs is a very good choice to have.
Theodore Ts'o
> How quickly we forget where those names came from!
> Richard Gooch originally used the traditional names.
> Linus ordered the names changed as a condition for
> acceptance into the kernel. Of course, that led to
> devfsd being a requirement, which kind of took away
> the whole point of using devfs.
>
> The Linus-approved names made devfs a pain to use,
> so few people used devfs and fewer helped out.
>
And this is **precisely** why putting the device names in the kernel
via devfs was such a mistake. Naming is policy, and should not be in
the kernel. Yes, the new style names were Linus's idea, but the
problem was that while he has extremely good taste with respect to
code, unfortunately he had exquisitely bad taste with respect to devfs
device names. And when one person's taste (even if that person is
Linus) about names can cause such grief, it should be an object lesson
about why putting that kind of user-visible naming policy in the
kernel is such a bad idea.
> Richard is only to blame for his inability to spell
> /dev/disk correctly. For that, he belongs in "jail"
> with a "j". It was enough of an eyesore to make me
> give up on devfs.
Shouldn't that be "jail" with a "g"? (As in "gaol"? :-)
- Ted
Ian Kent
>
> Booting kernel is faster compared to UDEV.
Mmm. Doesn't seem that way to me. What have I missed?
>
> 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.
Didn't seem to difficult to me when I checked out both systems this last
few days. In fact I like'em both.
>
> 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.
Some how I don't think that's the reason for that statement.
>
> 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.
Looks to me like that was never the aim of sysfs. I haven't checked into
sysfs yet but I suspect it is quite different to devfs.
>
> 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.
That would take away the ability to have a changeable device naming
scheme. One of the main reasons for having dynamic device name mapping
system is to map the names from a device detection system to specified
(possibly changing) naming scheme.
Please don't get me wrong. I like devfs very much and I see it has come a
long way since I last used it, but it needs work just to maintain its
current functionality within 2.6.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in