>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/