[Dri-devel] Re: Three proposed new generic DRM IOCTLs

[Michel <mi...@da...>]

On Sat, 2004-03-13 at 17:35, Jon Smirl wrote:
> --- Michel Dnzer <mi...@da...> wrote:
> > On Sat, 2004-03-13 at 04:54, Jon Smirl wrote:
> > > 
> > > A fourth call will be a driver specific call for setting the video mode. I
> > am
> > > implementing this by completely computing the register values needed to set
> > the
> > > mode in user space. I then pass these as a struct to the IOCTL and the
> > driver
> > > sets the mode. Doing it this way moves about 100K of code (in the radeon
> > case vs
> > > framebuffer) out of the kernel and into user space.
> > 
> > Is the verification of the input data really that much smaller?
> 
> Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to
> user space. It only took a couple of days. Mode setting code is seldom used as
> compared to an interrupt handler, this gives the space back for more important
> things and eliminates the need to security audit the code. 

The security audit still needs to happen somewhere. Does the DRM code
validate the user data?

> It's also much easier to debug.

That I can imagine.


> It's a path to providing more controlled access to the graphics hardware. Right
> now we have a free for all when every app and device driver can just do what it
> wants to the hardware. 

I don't see what prevents that in your scheme.


> Although I haven't written the code yet, I intend to add a output-only console
> driver entry point to DRM. Since mode setting is now tracked through the DRM
> driver it will be possible to display a kernel oops that occurs while running
> xserver. This is something framebuffer can't currently do.

Actually it can, or at least it did at some point, been a while since
I've experienced a panic. :)


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer