Re: New device filesystems

[M. R. B. <mr...@0x...>]

* James Simmons <jsi...@tr...> on Mon, Oct 08, 2001:

> 
> The reason for this is one we will add more device filesystems. Second
> most likely we will see merger of shared code. Where will we place that?
> 

Wherever it belongs.  Filesystem drivers have always lived in fs/, why put
them anywhere else?  It only makes the kernel tree less maintainable and
cluttered (one of the reasons we've been working on cleaning up the mips/
and sh/ targets).

About shared code, it should go where it's appropiate, if it's a character
device, drivers/char/, an input device, drivers/input/, etc.  That has
nothing to do with filesystem placement.

> 
> Sorry about the confusion. By saying devfs2 I mean a full device
> filesystem. We should call it something else. Any ideas?
> 

Huh?  gfxfs is it's own filesystem, it's already been named.  But Paul has
better arguments for keeping it in fs/.  Are you saying you want every
subsystem device in driver/ to have it's own filesystem?  Hmm, if that's
the case, then we should formalize that project and develop it
independently of linuxconsole, that seems to be outside the scope of what
we're working on.  Of course, gfxfs and inputfs would stay here until the
"devfs2" project matures.

> 
> YEs we will need a /dev/gfx/0/frame1 but you will have to use read and
> write instead of mmap. This is what Linus wants as pointed out in the
> discussion between me, him and Viro. 

I'm on my way to read the thread now, but if you don't have the ability to
mmap the framebuffer, it'll be a pain to use...  and "what Linus wants"
shouldn't be the determining factor of functionality, esp. when it hinders
progress ("....VM....VFS....") :P.

When I read the thread, I'll be back with more comments :).

M. R.