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

List:       dri-devel
Subject:    Re: RFC: libdrm repo
From:       Kristian_Høgsberg <krh () bitplanet ! net>
Date:       2009-11-23 16:43:16
Message-ID: 59ad55d30911230843k45e1a0a5h81c07a8a6475164b () mail ! gmail ! com
[Download RAW message or body]

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

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