Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) )

Larry McVoy (lm@bitmover.com)
Thu, 7 Oct 1999 22:24:50 -0700

On Fri, Oct 08, 1999 at 12:09:05AM -0400, Alexander Viro wrote:
> 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.

The devfs fans should listen to this guy. I don't know all the details
but what he is saying sounds right; I've been here before and device
nodes should definitely be handled in their own way, they aren't files,
they are devices.

But even that's not the main point. The main point which he is making
is that you need to think hard about the file system interfaces and the
semantics of those interfaces. I dunno if he's right or wrong about
devfs tying the VFS' hands, it's certainly plausible, but I'll let the
devfs guys argue that point. However, if he's right, that's the best
anti-devfs argument I've heard in this whole thread.

One last comment: as far as I can tell, most people aren't against devfs,
they are against the current implementation. The basic idea is useful at
some level. If that is correct, perhaps you're all arguing about nothing
(not that I've ever done that; sigh).

-- 

---
Larry McVoy            	   lm@bitmover.com           http://www.bitmover.com/lm 


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