Messages in this thread |  | | | Date | Fri, 8 Oct 1999 00:09:05 -0400 (EDT) | | From | Alexander Viro <> | | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) |
| |
On Thu, 7 Oct 1999, Matthew Dharm wrote:
> > - 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/
|  |