Re: New device filesystems

[James S. <jsi...@tr...>]

> > 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).

Okay. You both have had good arguments about keeping it where it is. By
shared code I mean the code duplication that might occur between gfxfs and
inputfs and eventually the others. Of course we could create another
directory under fs/ to store this code. 

> 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 that eventually will happen. It was planned for 2.5.X. I like this to
be the testing ground for these concepts until it matures and it can
become it own project.

> > 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 :).

Okay. Well if you can make it network transparent and have scripts able to
use it then I have no problem with keeping mmap.