RE: [Linux-fbdev-devel] fbdev API problems

[Matt S. <mat...@ho...>]

> > No doubt, as you state, there are applications that would need the
> > physical framebuffer address. The problem is that when you just leave
> > a pointer laying around in a public data structure there is no way
> > for a user application to know when the pointer is valid and when it
> > is not. If a unsuspecting TV capture card tried to use my physical
> > address without knowing that I only have 64k banks the whole system
> > would come down hard.
> 
> Ah. You are talking about having a real RRM (rendering resource manager).
> When a process open /dev/fb or DRI it should be registered with the RRM.
> Then when someone does something global like change the graphics
> resolution the RRM sends a signal to all the processes that are using the
> graphics card resources. As for the 64k bank sitution you can use VM
> tricks to make it appeard linear to userland. If you something really
> bizarre then you add something on the order of:
> 

No I wasn't talking about anything that complex. I just don't want
userland or anyone outside my driver using the pointers I am required
to provide. I'm just going to set them all to zero, and whatever falls
over needs to be fixed.

> > MMio is a very different animal. Most mmio regions are not safe for
> > untrusted userspace binaries to access. This is why such access is 
> > limited to root. Further there is no generic use for these mmio regions,
> > only a userspace driver would know what to do with them. Certainly a
> > userspace driver and kernelspace driver that are working together should
> > be able to work out a way to share the locations they need without
> > leaving them lay around in public.
> 
> It doesn't have to be root. DRI allows normal clients to use the MMIO
> regions. The key is that you have a RRM that is the guardian angel. If a
> process does the naughty you kill it and reset the accel engine.
> 

No it doesn't. The DRM only allows clients to map regions that are safe.
This doesn't include the mmio registers for most cards. The drm provides
safe interfaces to do dma and dispatch commands. It doesn't just let
clients touch the registers. For instance on i810 you can map a dma
buffer into the client but in order to dispatch a command the kernel
unmaps the buffer from the client writes the instruction to the dma
buffer and then dispatched the buffer. It isn't safe on i810 to allow
the client full access even to the dma buffers. It isn't like the
kernel gives you full access but will kill you if you do something
wrong, there is no interface to allow you to do something wrong in
the first place.

I think the kgi does more of what you are talking about here.

-Matt