[Xorg] DRI merging

[Jon Smirl]

--- Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
> Secondly every line of code you put in the kernel has to be audited,
> analysed and can introduce security holes or crash the machine. Its
> harder to debug and its harder to write in the first place. There are
> very good reasons (see the original DRI paper) for putting as much as
> you can in user space. The Mesa X work also tries to keep as much as
> possible in user space - including designs for mode computation by
> kernel->user callback.

There is a fine line to walk with the user space versus kernel split. For
example the X server should not be changing the PCI bus routing from user space
like it currently does. It should also not be capable of moving things like the
framebuffer address around in PCI space. The kernel provides an API for doing
those things and X should be using it. You just can't move hardware around
without telling the kernel and then expect hotplug to work. If things aren't
where the kernel expects them to be the kernel may assign the hotplug device
addresses on top of them.

On the other hand you shouldn't put too much into the kernel. Mode setting is an
example of this. It takes a lot of code to read a monitor's DDC and then compute
the mode. This code can easily run in user space and then use an IOCTL to set
the final result into the hardware. fbdev is trying to do all of this in kernel
space.

Finally there is the issue of needing root priv. With a properly designed kernel
driver the X server does not need to map the hardware into user space and run as
root. DRM + mode + cursor equals a driver capable of support a non-root X server.

=====
Jon Smirl
jonsmirl at yahoo.com


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/