From: "Jari Soderholm" <Jari.Soderholm@edu.stadia.fi>
To: <linux-kernel@vger.kernel.org>
Subject: DEVFS is very good compared to UDEV
Date: Tue, 23 Dec 2003 23:20:18 +0200 [thread overview]
Message-ID: <sfe8cdc2.027@mail2.edu.stadia.fi> (raw)
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
next reply other threads:[~2003-12-23 21:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-23 21:20 Jari Soderholm [this message]
2003-12-23 21:50 ` DEVFS is very good compared to UDEV Stan Bubrouski
2003-12-23 22:01 ` Rob Love
2003-12-23 22:21 ` Hua Zhong
2003-12-23 22:30 ` Rob Love
2003-12-23 23:00 ` Hua Zhong
2003-12-23 23:03 ` Rob Love
2003-12-23 23:14 ` Greg KH
2003-12-23 23:26 ` viro
2003-12-24 0:00 ` Mike Fedyk
2003-12-23 23:03 ` grundig
2003-12-23 23:05 ` viro
2003-12-24 2:24 ` Paul Jackson
2003-12-23 22:24 ` Felipe Alfaro Solana
2003-12-27 11:57 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2003-12-24 3:33 Albert Cahalan
2003-12-24 18:40 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sfe8cdc2.027@mail2.edu.stadia.fi \
--to=jari.soderholm@edu.stadia.fi \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox