On Sun, Nov 8, 2009 at 20:02, Eric Anholt <[email protected]> wrote: > 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. >
Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? Stephane ------------------------------------------------------------------------------ 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
