Messages in this thread | | | From | Shawn Leas <> | Subject | RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) | Date | Fri, 8 Oct 1999 12:00:23 -0500 |
| |
From: Alexander Viro [mailto:viro@math.psu.edu] Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device allocation))
>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.Interesting take on the concept, however, is it really that different?
I'm not sure I understand how device nodes on UFS/ext2/etc could be pseudolinks to in-core quasi mount points. Don't get me wrong, I believe you, I just lack understanding.
One thing I think this approach lacks (or may lack) is an easy automatic device node creation. With devfs, the deivce node is as if it is created implicitely upon registration by the driver.
I might be WAYY off base, so correct me if I'm grossly mistaken.
-Shawn
- 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/
| |