Re: DEVFS is very good compared to UDEV

[Albert Cahalan <albert@users.sf.net>]

Rob Love writes:
> 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.