linuxconsole-dev

New device filesystems

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

As some might have noticed we are starting work on devices filesystems.
For those that don't know what this is about look at the 

LANANA: To Pending Device Number 

thread on the kernel mailing list. We basically are build filesystems for
each type of device. This allows us to have more than one file represent a
device instead of the traditional UNIX method of one file to one device.
As you can image this gives much more power to the driver writer. 
   One advantage to such a design is network transprancy. You can program
devices remotely. This means for example on embedded devices, even a cell
phone, you could have a kernel image a just NFS some machine remotely. On
that remote machine you could program the hardware on the cell phone.
   Another advantage is you could write basic scripts to preform hardware
functions. For example we could do a 

echo "640x480-16@70" > /dev/gfx/card0/mode1



P.S

   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.
   The second thing is you have 

struct file_operations gfxfs_file_ops = {
        mmap:           generic_file_mmap,
        llseek:         generic_file_llseek,
};

For this filesystem to be truly network transparent we also need to remove
mmap support as well as ioctl support. Read and write only. 

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Sun, Oct 07, 2001:

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

I don't think creating a new directory is a good idea.  What's wrong with
keeping gfxfs where it is in fs/gfxfs?  What isn't clean about that?
That's the standard spot for all vfs drivers and it's self-contained.  Also
(and Paul can explain this better than I can), gfxfs is just a vfs layer
for the fb, it isn't devfs.  You seem to think they're related, when gfxfs
is intended to perform a different role.  When describing this, please keep
devfs and gfxfs seperate to reduce confusion.

IMO, inputfs should go into fs/inputfs as well.

>    The second thing is you have 
> 
> struct file_operations gfxfs_file_ops = {
>         mmap:           generic_file_mmap,
>         llseek:         generic_file_llseek,
> };
> 
> For this filesystem to be truly network transparent we also need to remove
> mmap support as well as ioctl support. Read and write only. 

Er, these would still be needed for /dev/gfx/0/fb, since they'll be
translated into the fb_mmap() call (I'm not so sure what llseek would be
used for, but it would probably be useful in other gfxfs files).

M. R.

Re: New device filesystems

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

> I don't think creating a new directory is a good idea.  What's wrong with
> keeping gfxfs where it is in fs/gfxfs?  What isn't clean about that?

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?

> When describing this, please keep
> devfs and gfxfs seperate to reduce confusion.

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

> > For this filesystem to be truly network transparent we also need to remove
> > mmap support as well as ioctl support. Read and write only. 
> 
> Er, these would still be needed for /dev/gfx/0/fb, since they'll be
> translated into the fb_mmap() call (I'm not so sure what llseek would be
> used for, but it would probably be useful in other gfxfs files).

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. 

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.

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.

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.

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Sun, Oct 07, 2001:

> 
> As some might have noticed we are starting work on devices filesystems.
> For those that don't know what this is about look at the 
> 
> LANANA: To Pending Device Number 
> 
> thread on the kernel mailing list. We basically are build filesystems for
> each type of device. This allows us to have more than one file represent a
> device instead of the traditional UNIX method of one file to one device.

Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
that subject.

M. R.

Re: New device filesystems

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

> > LANANA: To Pending Device Number 
> > 
> > thread on the kernel mailing list. We basically are build filesystems for
> > each type of device. This allows us to have more than one file represent a
> > device instead of the traditional UNIX method of one file to one device.
> 
> Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
> that subject.

You have to look in the archives around May.

Re: New device filesystems

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

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

> 
> > > LANANA: To Pending Device Number 
> > > 
> > > thread on the kernel mailing list. We basically are build filesystems for
> > > each type of device. This allows us to have more than one file represent a
> > > device instead of the traditional UNIX method of one file to one device.
> > 
> > Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
> > that subject.
> 
> You have to look in the archives around May.

Specifically, May 14th, 2001:

"LANANA: To Pending Device Number Registrants"

http://boudicca.tux.org/hypermail/linux-kernel/2001week20/

M. R.

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.