On Tue, 17 Nov 2009 18:53:22 +0100 Stephane Marchesin <marche...@icps.u-strasbg.fr> wrote:
> On Tue, Nov 17, 2009 at 18:07, Jesse Barnes > <jbar...@virtuousgeek.org> wrote: > > On Mon, 9 Nov 2009 17:46:44 +0100 > > Stephane Marchesin <marche...@icps.u-strasbg.fr> wrote: > >> > 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). > > > > Btw the kernel releases every 3 months. > > > >> 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. > > > > I don't see big advantages to packaging it with the kernel, mainly > > disadvantages. I don't think it'll get wider testing if it's in the > > kernel, and I don't think compatibility will be easier to maintain. > > > > FWIW, you gave me the opposite argument when you decided that DRM > development should happen in the kernel. Back then you used to say > that we'd get more testers that way. Which one should I believe? Testers for kernel code, yes. Testers for libdrm code, no. When I install a new kernel I don't typically install new headers and all the other junk that comes with the new kernel, I just install the vmlinuz and make a new initrd if necessary. I don't think I'm alone. But even if we concede that libdrm would get more testers if included in the kernel, there are still other issues to deal with. > > There's a big downside too, since it makes packaging much harder. > > Distros typically stick with one kernel for a relatively long time, > > but if they want to pick up a libdrm fix unrelated to a new DRM > > interface (like the one Remi pointed out) they'll have to grab a > > recent kernel, extract libdrm, and make sure it works with their > > current kernel (which may involve some extra work if new DRM > > interfaces have gone in too). > > > > Yes, but the positive side is that distros using a standard/old (about > a year) kernel don't need to crawl the old libdrm repo and find the > right version (in your case they have to do this ° backport stuff) ... > I think that plus the fact that it makes development and merging > simpler is just a reason to do it. Presumably they'd want the last released version... Anyway I'm just dubious about moving most userland code into the kernel; udev, klibc, etc. I think it makes more things harder than it does easier. But like Kristian said, it's really a separate discussion from making a more standalone libdrm repo. Nothing stops you (or anyone else) from taking that new repo and proposing it for inclusion in the kernel. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ 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
