From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Tue, 11 May 1999 21:54:26 +0000

Re: MMIO accel with kgicon drivers.

Jon M. Taylor wrote:
> 
> On Tue, 11 May 1999, Marcus Sundberg wrote:
> > >         MMIO acceleration is a security hole.
> >
> > Not anymore than fbcon already is.
> 
>         fbdev drivers can use ioctls.  They do not have access to the KGI
> internal structures and management framework, but they can still catch
> and handle per-driver ioctls, correct?

Yes.

> > > What is really needed for a
> > > good solution to this problem is accel-operation FIFOs to reduce the
> > > number of kernel-user transitions, as this is what kills performance.
> > > Steffen's new KGI 0.9 design has exactly this, for exactly this reason.
> >
> > The old Dali KGI had it too, but unfortunately there was only one
> > driver that used it... (the Mystique)
> 
>         Are you talking about the 'pingpong buffers'?

Yes. Well FIFO might not be the right thing to call it.

> > But in any case mapping the accel registers to userspace should
> > always be possible.
> 
>         Well not always - I certainly cannot do that |-/.  Unless you mean
> 'possible within the overall KGI[con] API framework'.

Yes, that's what I meant. There's no point in mapping the registers to
userspace if their layout is secret or something. ;)

> > For KGI 0.9 it probably will require root privs
> > (or my preference - a separate device which you can give whatever
> > permissions you want)
> 
>         I would do any such non-framebuffer mappings through device-specific
> /proc entries created on the fly.  I am considering using such a scheme for
> my Creative driver - accel buffers, texture buffers, vertex buffers, MMIO
> registers (when appropriate) etc can all be handled this way and it keeps the
> fbdev interface clean of driver-specific stuff. Perhaps ioctls could be
> bound to each /proc file as well so that /dev/fb does not have to handle them
> all.  This use of multiple ioctl entrypoints could provide a speed boost, but
> I do not know if /proc entries are normal device files which handle
> ioctls....

Proc entries can have a struct file_operations associated with them,
so they can basicly do everyting a device node can do.
But another (and IMHO more suitable) alternative is the devfs
filesystem which will hopefully go into early 2.3 kernels.
I've been using devfs for the last months and it's really nice.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se