Mailing List Archive

On Sun, Oct 10, 1999 at 12:25:12AM -0100, David Ford wrote:
> Nathan Hand wrote:
>
> > Would a /proc/devices file which lists all devices also solve your
> > problems with the existing system?
>
> [...]
>
> > HPA, would you be open to the idea of /proc/devices. This won't be
> > a terrific loss of functionality from the existing devfs.
>
> make your devfs mountpoint /proc/devices. already exists, already used,
> already ignored as a beneficial point.
No this is *not* the same thing.
Mounting devfs on /proc/devices would entail readdir() and stat() to
discover devices, instead of select() and read() (HVB's concern).
Mounting devfs on /proc/devices also introduces a heap of code which
doesn't go through VFS (Viro's concern).
Mounting devfs on /proc/devices also introduces several new features
only one of which is considered useful (TSO's concern).
Mounting devfs on /proc/devices also implements policy into a naming
scheme for device nodes (HPA's concern).
ObServation: I can't believe the stubborness exhibited by both sides
in this never-ending flamewar. Both sides are going to have to agree
that some compromise is needed. HVB has suggested what's obviously a
decent compromise (/proc/devices) and I'm shocked that so many devfs
users are too goddamn stubborn to even consider it. I am a supporter
of devfs, but I'm not so blind I won't listen to the arguments being
raised against devfs, or so stubborn that I won't listen to proposed
compromises.
The existing devfs is *NOT* getting into the kernel. Accept this and
get over it. Start looking for acceptable compromises instead.
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 1515 E-mail: nathanh@chirp.com.au
-
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/

On Sun, 10 Oct 1999, Nathan Hand wrote:
> Mounting devfs on /proc/devices also introduces a heap of code which
> doesn't go through VFS (Viro's concern).
Where the heck does this 'doesn't go through VFS' come from? It does, it
just mirrors the VFS structures below the surface. Unfortunately it
creates a pile of problems with the revalidation code which VFS doesn't
really support (it's _not_ a devfs-specific problem). Side channel with
register/unregister creates problems, all right, but the real point being
that devfs manages to touch _very_ sore point of VFS. BTW, the other side
of said sore point regulary resurfaces in knfsd - part of stale fhandles
processing suffers badly from that. And I don't need to explain why knfsd
that doesn't compile for several releases is _not_ an option, do I? It's
ugly, entangled and messy. Normal filesystems will not care for
modifications in that area and anything that will... well, doesn't make me
happy.
-
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/