> AV> Though luck, then. What you are telling boils down to: "I want it; I don't
> AV> give a damn for the problems; code around and I can't be even bothered to
> AV> figure out what those problems _are_." Do you really expect to be taken
> AV> seriously?
>
> Problems are solved by Richard mostly. So far I hear only about one technical
> problem with devfs (from you BTW): problems with VFS (which one BTW: rename is
> not implemented in procfs and procfs is included in kernel; what's is so
> different in devfs?). This is THE ONLY REAL problem. All other problems are
The devfs quasifiles _ARE_ renamable:
=== Cut ===
[root@nomad /dev]# ls cua*
cua0 cua1
cua:
0 1
[root@nomad /dev]# mv cua1 cua3
[root@nomad /dev]# mv cua/1 cua/3
[root@nomad /dev]# ls cua*
cua0 cua3
cua:
0 3
[root@nomad /dev]# mv cua3 cua1
[root@nomad /dev]# mv cua/3 cua/1
[root@nomad /dev]# ls cua*
cua0 cua1
cua:
0 1
=== Cut ===
> myths or political ones. Is it the only reason to not include devfs in kernel ?
> BTW what about devpts and procfs: are they any better from VFS side ? They are
> both in kernel and devpts was added when devfs already existed...
> There are quite a few things in kernel not welcomed by Linus initially.
> But in case with devfs I can not see technical problems at all -- just
> political ones. There are problem with rename, for example, but procfs also
> has it AFAIK. Why it's Ok for procfs and not Ok for devfs ?
The quasifiles in /dev _ARE_ renamable. They are also chownable, chmodable,
cpable, rmable etc. etc....
The "good ol' way" is good only till it doesn't stop the progress. It was
very good to have a live horse as an engine for a cab, but once upon a time
a man called Henry Ford did start to manufacture a new cabs called Ford T and
the live horse had became obsolete...
===========================================================================
Sergey Kubushin aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/