Re: info on gfxfs

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

On Sun, Oct 21, 2001 at 06:12:59PM -0400, cw...@so... wrote:
> After reviewing the console archives over the month of october, we have s=
een=20
> how much has really happened (more than we expected :^)  however, we havn=
't=20
> seen many details as to what is actually going into the fs, other than fb=
,=20
> frameN, cmap, mode, and perhaps a few other things.  is there a standard =
list=20
> of items in there, and is there any information on what they do/how to us=
e=20
> them?  if nothing else, we would like to become familiar with this featur=
e and=20
> document it to help others put it to good use.
>=20
For the time being, it'll work as a drop-in replacement for the ioctl()
interfaces. (which is where things like cmap/mode/etc. come in). The FS
exports a few symbols that can be used by other drivers (fbmem.c will deal
with the most of the cruft), and people will be able to register new entries
with the filesystem for their own purposes.

In all honesty, a lot of this kind of stuff could be abstracted out into an
"ioctlfs" to reduce code duplication.. especially when we start working on
things like the inputfs.. it might make more sense to just fork the stuff i=
nto
an ioctlfs and then deal with gfxfs and inputfs afterwards, and simply have
them calling hooks from the ioctlfs.

The base idea behind it is you have a registered device which you are grant=
ed
a directory for.. in that directory you have dentrys for your various frame
buffers, cmap, mode, and all the regular ioctl stuff. At the time of
registration, you simply setup your customized read/write routines that you
want to be dealt with as a callback on the dentrys, and hand a pointer to t=
he
structure with the function pointers in it off to the registration routine.
This then inserts the data into a private location so it can be referenced
later (inode->u.generic_ip for example).

fbmem.c will deal with all the core stuff initially.. but if you have your =
own
particular needs, you can simply write a driver that sets up some read/write
routines, registers them with its entry, and then gets invoked when operati=
ons
on the dentry happen.

I'm still tinkering with the gfxfs, though I'm leaning more and more towards
the idea of abstracting things out as an "ioctlfs" and simply having gfxfs
utilize that.. inputfs could then do the same. As the API and such gets
refined and to a point of useability, I'll write documentation on it so oth=
ers
can play with it.

> also, /dev/gfx seems to be a standard device for linux/irix on sgi boxes=
=20
> [iirc].  is creating this fs with the same name going to cause a conflict?
>=20
Right:

                148 =3D /dev/gfx          Linux/SGI graphics effects device

and on IRIX:

crw-rw-rw-   1 root     sys       10,  56 Oct 21 15:58 /dev/gfx

I suppose that could cause some issues, but at the same time, it's just a
mountpoint.. the gfxfs can really be mounted just about anywhere. I'd sugge=
st
keeping /dev/gfx for the mountpoint and trying to get /dev/gfx changed to
something more meaningful like /dev/sgigfx in the case of the graphics effe=
cts
device..

Regards,

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