> > - Breaks filesystem semantics in several ways, makes it very hard to check
> > ramifications
>
> Please elaborate. I have yet to see you describe one case where the
> semantics are broken. If you can, please provide code/commands/a scenario
> in which devfs does "the wrong thing" with respect to filesystems.
rename(). link(). revalidate(), if you want to go inside the kernel.
[snip]
> > Also: It is extra code, has to be maintained and updated, and has to be
> > accounted for in new driver developments. It _will_ add new bugs, even new
> > classes of bugs. This doesn't come for free.
>
> Ooohh... extra code. Gee, you know, you better detach that printer...
> using it causes extra code to be used by your computer.
>
> If every time someone thought of a new and better way to do something,
> people stopped him because it would add 'extra code' and possibly
> introduce a 'new class of bug', we'd still be using the abacus.
Spoken as a true EMACS user... You see, there is one nasty problem -
inside devfs is _not_ a normal fs. Unfortunately this "inside" includes
the interface with VFS. It makes VFS-related changes much trickier. Yes,
current device handling is not good either. The right thing would be a
separate fs that WOULD NOT BE MOUNTED. Devices should live there. Device
inodes in ext2/ufs/etc. (including devfs, BTW) should be considered as
pseudo-links to that filesystem. IOW, we ought to have two in-core inodes
here instead of trying to stuff everything into one. It's not the same as
Richard's devfs, but it would be useful for all filesystems and it would
offload lots of stuff from devfs proper. Devfs in its current form tries
to do way too many things and effectively ties hands to VFS work. Badly.
That's my main problem with it - user-visible interface is less severe
one.
-
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/