On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
> 2009/11/6 Kristian Høgsberg <[email protected]>:
> > Hi,
> >
> > This has come up a few time and it's something I think makes a lot of
> > sense.  Since all driver development (afaik) now happens in linux
> > kernel tree, it makes sense to drop the driver bits from the drm.git
> > repo.  I've put up a repo under
> 
> Actually, I don't think a separate libdrm makes much sense. We don't
> want to add yet another outside component and ask ourselves questions
> like "how do I maintain compatibility" (which, incidentally, have
> already been raised).
> 
> Given this, IMO libdrm live somewhere alongside the kernel.
> Furthermore when pulling outside stuff we driver devs can do a
> kernel+DRM+libdrm pull at the same time which is a win.
> 
> And also users don't have to wonder where/how to pick the right
> libdrm. You get the right one with your kernel.

This is a bad idea.  libdrm with the kernel means that users and
distributions can't trivially update libdrm.  So all of the users of
libdrm end up being an ifdeffed nightmare of both compile-time and
runtime detection.   Our code used to be that way before we fixed libdrm
to be "only use kernel code that's going upstream, and never regress
it".  Things have improved in the last few years for upstream drivers,
and I don't want to regress them with moving libdrm to the kernel.

This is why I've also argued against having libdrm not install the ioctl
headers.  It seems like the argument is mostly that having libdrm keep a
copy of the kernel headers in the repo is bad because people might cp
the file wrong.  If the cost of not keeping them in the repo is having
the libdrm and its consumers be ifdef hell, I will keep a cp in the
repo.

-- 
Eric Anholt
[email protected]                         [email protected]


Attachment: signature.asc
Description: This is a digitally signed message part

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to