On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 19:18, Eric Anholt <[email protected]> wrote: > > 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. > > Why do you need to update libdrm separately from the kernel? Is there > so much that's in libdrm that does not also require a new drm? Newer > libdrm functionality usually also requires a new drm... > > > 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. > > Again I don't see what kind of changes you have in mind. You just say > "regress".
I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. -- Eric Anholt [email protected] [email protected]
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
