On Mon, Nov 9, 2009 at 17:42, Eric Anholt <[email protected]> wrote: > On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: >> On Sun, Nov 8, 2009 at 23:33, Eric Anholt <[email protected]> wrote: >> > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: >> >> 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? >> > >> > 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? >> > >> >> People with old kernels can pick an old libdrm from some place else in >> the meantime.People with 2.6.32 don't have to grab anything more as >> libdrm came with their kernel already. > > I don't care about the transition. I care about the long term. Replace > 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user > get his libdrm at that time?
Well, once libdrm is with the kernel, you get libdrm ... with the kernel. What's unclear in what I explained? > > And how do I get releases of libdrm out outside of kernel releases? > We're doing libdrms at least twice a kernel cycle, because we've got > stable fixes to push out/new interfaces to start relying on faster than > every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. 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
