On Sun, Mar 7, 2010 at 20:42:51 +0100, Bastian Blank wrote: > On Sun, Mar 07, 2010 at 05:43:30PM +0000, Ben Hutchings wrote: > > On Fri, 2010-03-05 at 19:37 +0100, Bastian Blank wrote: > > > The linux kernel is source of the drm headers in the meantime. > > It *is*, but it shouldn't be. Let's fix this now. > > Ah. So libdrm still works if we remove the drm drivers as this is no > kernel interface at all? > > Either it is a kernel interface, then the kernel includes the > definitions for it and provides it to the other parts of the system. Or > it is not, but why are there drivers _providing_ this interfaces then? > Because the userspace part of the drivers (meaning xf86-video-foo and the mesa dri drivers) need to have these definitions to call libdrm functions (wrappers around drm ioctls). They can handle a too old kernel at runtime, but at build time they need the latest headers so the source isn't full of useless #ifdefs. The headers in libdrm are regularly synced with Dave's drm tree (or Linus), and updating libdrm is easier than bumping the kernel. So basically what we have here is a kernel interface which is fast-moving enough that userspace needs to have its own copy. Which means either we have libdrm install a system-wide copy, or each driver has to include its own copy of the headers, if we want to be able to update them without waiting for a new kernel. As I said, I'd be fine with leaving /usr/include/drm/ to linux-libc-dev, and install the headers from libdrm to /usr/include/libdrm or so. Or linux-libc-dev drops the drm subdir, and libdrm goes back to installing these headers (like it was doing before 2.6.28).
Cheers, Julien
signature.asc
Description: Digital signature
