Re: New device filesystems

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

On Sun, Oct 07, 2001 at 09:52:26PM -0700, James Simmons wrote:
>    A few commits about the code entered into CVS. I really like to create
> a directory devfs2 and place gfxfs in their. The reason is I like to write
> the inputfs as well. Plus in time we probable will add more device
> classes like sound to this directory. I just like to keep the fs directory
> clean.

Convulting different filesystems with different things in mind into a common
code base doesn't seem like the best way to keep the fs directory "clean".
A good majority of subsystems deal with their own filesystems, it's only a
select few that touch anything in fs/. The usbdevfs for example, is kept fu=
lly
inclusive to the drivers/usb heirarchy. Something similar could be done with
the inputfs (and maybe even the gfxfs) if there was valid reasoning behind
keeping it out of fs/.

Personally, I prefer sticking things where they belong, and fs/ is the logi=
cal
place to dump filesystems, whether they're virtual or not. Think ramfs,
theoretically it's MM bound, but sticking it in mm/ would be appaling.
Likewise, limiting a fs to a subsystem bound directory when there's better
places to put it, are equally disturbing. Hardly the clean image one wants.

Provided there's a good reason for adding a new fs, there's absolutely noth=
ing
wrong with sticking it in fs/. Adding a new fs simply for the purpose of
adding a new fs is another matter entirely, and I don't think that applies =
to
gfxfs or inputfs. Maybe what's really needed is some clarification in the f=
s/
directory to differentiate between virtual filesystems and filesystems that
actually deal with devices. But that's just a cosmetic issue, and is purely=
 a
matter of opinion.

>    The second thing is you have=20
>=20
> struct file_operations gfxfs_file_ops =3D {
>         mmap:           generic_file_mmap,
>         llseek:         generic_file_llseek,
> };
>=20
> For this filesystem to be truly network transparent we also need to remove
> mmap support as well as ioctl support. Read and write only.=20
>=20
ioctl support I don't want either, seeing as how the whole idea is to get
_away_ from the mess of ioctl()'s in the first place. mmap() support has its
uses though.. especially with things like network transparency in mind. It's
not uncommon to want to mmap() the framebuffer (/dev/fb/0), and being able =
to
do so from a remote machine far outweighs any disadvantages to supporting i=
t.
Naturally, we can do our own gfxfs_mmap() incase there's any special concer=
ns
that need addressing.. though I haven't quite gotten that far in development
of the system to really be heavily concerned about mmap/llseek support yet.
(They're just there as generic placeholders, as the comments suggest).

Regards,

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