Re: New device filesystems

[Paul M. <pm...@mv...>]

On Mon, Oct 08, 2001 at 10:33:30AM -0700, James Simmons wrote:
> 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.=20

That's a good point, and has me thinking as well.. there will undoubtedly b=
e a
good chunk of duplicate code (as there already is..) between gfxfs and inpu=
tfs
that could likely be almost entirely shared with the exception of a few sma=
ll
routines. Even things like ramfs (which gfxfs is heavily based off of so fa=
r),
could be shared with some common routines.. Perhaps instead of just sharing
between inputfs and gfxfs we should look at things from the greater scope a=
nd
think about what virtual filesystems in general are going to have in common.
Adding generic dcache routines for dealing with virtual filesystems might be
something to consider. (link, unlink, lookup, mknod, etc, etc, can all be
shared).

> 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.
>=20
Maybe we should look into adding these kind of routines into fs/dcache.c or
perhaps a fs/virtdcache.c? We're going to have to have seperate filesystems
regardless.. making it less painful and reducing code duplication as a whole
seems like the best way to go IMO.

> Okay. Well if you can make it network transparent and have scripts able to
> use it then I have no problem with keeping mmap.
>=20
That'll be the end goal.. llseek() support would be handy as well. Even if =
it
breaks on network transparency (which it shouldn't for any logical reason),=
 it
could still be useful for local usage.

James, I saw you started on some of the inputfs stuff, what are your design
goals/thoughts for it?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.