linuxconsole-dev

Re: [Linux-fbdev-devel] Future of Framebuffer

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

On Thu, 4 Oct 2001, Paul Mundt wrote:

> On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote:
> > I have spoken about this before. I like to see both interfaces merge in
> > the future. Especially with the desire to move from traditional device
> > files to device filesystems. In the future their will be a graphics
> > frilesystem to replace the two. Well that is my dream. Of course their are
> > a few issues on design with DRI which I will not go into here.  
> > 
> This sounds like a potential Ruby issue to me (well, the FS part anyways)..
> how about starting a module for it (or hacking it into the existing tree)?

We could but it would be a huge job. Alot of devfs tinkering. 

Re: [Linux-fbdev-devel] Future of Framebuffer

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

On Thu, Oct 04, 2001 at 04:58:53PM -0700, James Simmons wrote:
> > > I have spoken about this before. I like to see both interfaces merge =
in
> > > the future. Especially with the desire to move from traditional device
> > > files to device filesystems. In the future their will be a graphics
> > > frilesystem to replace the two. Well that is my dream. Of course thei=
r are
> > > a few issues on design with DRI which I will not go into here. =20
> > >=20
> > This sounds like a potential Ruby issue to me (well, the FS part anyway=
s)..
> > how about starting a module for it (or hacking it into the existing tre=
e)?
>=20
> We could but it would be a huge job. Alot of devfs tinkering.=20
>=20
Why deal with devfs tinkering? It would make more sense to implement it as =
its
own native virtual fs. As an example.. could have something like /dev/gfx a=
s a
top level mountpoint for the fs, and then just mount on that (wouldn't matt=
er
if it were devfs or not).

As far as general interfaces go.. a drop-in replacement for the ioctl()'s
really wouldn't be that big of a deal.

For each device that registered with the system, things could be done like:

/dev/gfx/
    0/
        fb
	cmap
	...
	mode
    1/
        fb
	cmap
	...
	mode

and so on, and so forth..

/dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

FBIOGETCMAP/FBIOPUTCMAP can be done away with by doing reads and writes to =
the
/dev/gfx/0/cmap dentry. Just as all other GET/PUT routines can be done away
with.

Instead of trying to do "special" dentry manipulation in the fs itself, I
think it'd make more sense to just provide a few common interfaces.. Devices
only really need to register themselves with the system.. it's up to the
fb layer to deal with creation of the dentrys and dealing with any kind of
special requests. (Just as it would the requirement for any other subsystem
(DRM anyone?) to deal with special files and registering callbacks with
the fs for them).

The fs itself only needs to do a few things.. provide a few routines for
device registration, and for registering callbacks. In the event that no
callback is provided (or no flags like read-only are set on the created
file), generic dcache routines can be utilized instead..

This could all be done with just having a small structure that contained
a pointer to the dentry struct and a pointer to a set of routines that
callbacks can be assigned to. (Then just check for the existance of a provi=
ded
callback registered with the dentry when things were allocated, and either
use those, or fallback on defaults).

Another advantage of this system is that people who have special needs with
the system can simply write a module that sets up the files it wants, and
registers some callbacks and have it either globally applied or limit it
specifically to a specific card.. Reducing the need for adding ioctl()'s.

All in all, this really shouldn't be that big of a deal.. I don't think an
initial implementation should be difficult at all.. laying out the API
would really be the biggest trick.

Comments?

Regards,

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

Re: [Linux-fbdev-devel] Future of Framebuffer

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

> Why deal with devfs tinkering? 

I'm thinking devfs was designed with the one file decriptor to hardware
model. As you know I plan to expand this.

> It would make more sense to implement it as its
> own native virtual fs. As an example.. could have something like /dev/gfx as a
> top level mountpoint for the fs, and then just mount on that (wouldn't matter
> if it were devfs or not).

True. Perhaps we should start off this way with a few device filesystems
and see the commonality in them to figure out a common backbone. I just
don't want to end up duplicating alot of what devfs has done.

[snip..
> /dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

Yeap. 

[snip]... 

Wow!! I see you have put serious thought into this. More than I have. 

> laying out the API would really be the biggest trick.

Oh yeah. Tonight we can discuss some issues then.

Re: [Linux-fbdev-devel] Future of Framebuffer

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

On Fri, Oct 05, 2001 at 11:30:12AM -0700, James Simmons wrote:
> I'm thinking devfs was designed with the one file decriptor to hardware
> model. As you know I plan to expand this.
>=20
devfs works fine with the one file descriptor per registered device model,
as that's what it was designed for. For any kind of specialized requirements
such as multiple file descriptors per registered device component, you are
no longer under the scope of what devfs was designed for, thus a new virtual
fs makes sense.

> > It would make more sense to implement it as its
> > own native virtual fs. As an example.. could have something like /dev/g=
fx
> > as a top level mountpoint for the fs, and then just mount on that (woul=
dn't
> > matter if it were devfs or not).
>=20
> True. Perhaps we should start off this way with a few device filesystems
> and see the commonality in them to figure out a common backbone. I just
> don't want to end up duplicating alot of what devfs has done.
>=20
There really shouldn't be too much duplication of devfs at all. I think the
only thing we really need to deal with devfs for would be for /dev/fb/0
registration.. at which point we can just register with devfs and have it
generate a symlink to the appropriate dentry under the gfxfs.. in this case
/dev/gfx/0/fb. Other than that, devfs has no reason to care about anything
else.

> > laying out the API would really be the biggest trick.
>=20
> Oh yeah. Tonight we can discuss some issues then.

Sounds good.

Regards,

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

Re: [Linux-fbdev-devel] Future of Framebuffer

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

> you are
> no longer under the scope of what devfs was designed for, thus a new virtual
> fs makes sense.

I thought so. 

> > Oh yeah. Tonight we can discuss some issues then.
> 
> Sounds good.

Okay. I will be online around 7:30 tonight.