On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 20:02, Eric Anholt <e...@anholt.net> wrote: > > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt <e...@anholt.net> wrote: > >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > >> >> 2009/11/6 Kristian Høgsberg <k...@bitplanet.net>: > >> >> > 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?
So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? -- Eric Anholt e...@anholt.net eric.anh...@intel.com
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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
