On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 23:33, Eric Anholt <e...@anholt.net> wrote: > > 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? > > > > 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. > > If the only reason not to merge the libdrm into the kernel tree is > because you have a "difficult" time finding a libdrm for old kernels > (and only during the transition), well I'd say that means there's no > real problem here.
There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. robert. > 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 > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland <rnol...@2hip.net> 2Hip Networks ------------------------------------------------------------------------------ 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
