[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dri-devel
Subject:    Re: RFC: libdrm repo
From:       Michel =?ISO-8859-1?Q?D=E4nzer?= <michel () daenzer ! net>
Date:       2009-11-23 17:40:22
Message-ID: 1258998022.9159.30.camel () thor ! local
[Download RAW message or body]

On Mon, 2009-11-23 at 11:43 -0500, Kristian Høgsberg wrote: 
> 2009/11/23 Michel Dänzer <michel@daenzer.net>:
> > On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote:
> >> 2009/11/23 Michel Dänzer <michel@daenzer.net>:
> >> > On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote:
> >> >> 2009/11/19 Eric Anholt <eric@anholt.net>:
> >> >> > On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
> >> >> >> 2009/11/6 Kristian Høgsberg <krh@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.
> >> >> >>
> >> >> >> Ok, here's an update to the proposal.  I've rebased the libdrm branch
> >> >> >> in people.freedesktop.org/~krh/libdrm.git to include a copy of
> >> >> >> $kernel_source/usr/include/drm as a toplevel include/drm directory in
> >> >> >> git.  I also added a makefile rule to copy a new version of the
> >> >> >> headers from a kernel git repo and commit it with a message describing
> >> >> >> the version it was copied from.  The location of the kernel repo is
> >> >> >> given at ./configure time with the --with-kernel-source argument.
> >> >> >>
> >> >> >> By adding the makefile rule, I'd like to encourage people to not hand
> >> >> >> edit the headers and to commit updates of the header files
> >> >> >> independently from other changes.  And of course, updates to the
> >> >> >> headers should still follow the rules we have now; only copy over new
> >> >> >> changes once they're in drm-next (I think, or is that in Linus'
> >> >> >> tree?).
> >> >> >>
> >> >> >> Anyway, I think this should address the concerns raised in the thread
> >> >> >> and if there's no other problems, I can put this into place today.
> >> >> >> I'll merge the couple of changes on master since I branched for this
> >> >> >> work and I'll put a mesa/drm.git symlink in place to point to
> >> >> >> libdrm.git.
> >> >> >
> >> >> > Awesome.  Just a touchup to the README to reflect the current state
> >> >> > seems to be needed.
> >> >>
> >> >> Done and pushed.
> >> >
> >> > Is it expected that there are now two slightly different sets of radeon
> >> > headers in the repo? Which set will get installed?
> >>
> >> The headers in include/drm will be installed and libdrm_radeon should
> >> be updated to use those headers instead of the ones in radeon/ since
> >> they're what's upstream.
> >
> > At least one of the headers in question - radeon_bo.h - isn't in the
> > kernel (and it probably makes no sense to put userland specific headers
> > like that in the kernel) and is outdated in include/drm.
> 
> Oh, only radeon_drm.h is in the kernel, so only that should be in
> include/drm.  The other radeon_*.h files live in radeon/.  I guess
> accidentally copied over the userspace headers when I populated the
> include/drm directory initially.  Should be cleaned up now.

Thanks Kristian.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


------------------------------------------------------------------------------
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

[prev in list] [next in list] [prev in thread] [next in thread]