On Fri, Aug 1, 2008 at 6:27 PM, Dave Airlie <airlied@...> wrote:
>> > Personally, I only use the existing DRM repo on old kernels because that's how
>> > it's structured. It's actually more work for me to download & build a recent
>> > kernel, then update & build the DRM drivers against it that it is to simply
>> > update the DRM drivers and build against my current kernel (or just updating
>> > a theoretical DRM kernel tree & building for that matter).
>> > So really I don't think keeping compat *in-tree* for old kernels gives us
>> > extra testing. It's really no harder or easier to do the same thing with a
>> > full kernel tree, just different. IMO anyway.
>> Yeah, we could keep the BC code around if we moved the drivers
>> in-tree, and that would let you compile the drivers against an older
>> kernel using something like:
> First you said this :)..
>> Another benefit from having the DRM repo structured as linux kernel
>> tree is that changes from upstream linux development (janitorial
>> stuff, tree-wide api changes) only takes a 'git merge' to carry over
>> to the DRM tree. In other words, making it easier to push changes
>> upstream works both ways, it also becomes easier to pull down changes
>> from upstream that touches the DRM subystem. Hm, I guess that's what
>> your saying in 4).
> Then this, the thing is to keep it building you need compat code, code
> that can't go into Linus tree, so we end up with a tree that isn't like
> Linus tree, and we still have to patch manage transitions so we don't save
> anything doing this over what we have now.
I was thinking that having the BC code in-tree might be acceptable.
As far as I remember, the old firewire stack did that for a while, but
maybe they've tightened up the policy on that.
>> So, I very much agree with your proposal and don't feel I can add
>> much, except to point out that a migration to in-tree drm development
>> doesn't need to be a big and painful process. Basically, we just
>> decide to do it, and designate a kernel tree on freedesktop.org that
>> we work from and start with the current state of upstream drm. There
>> will be some work in moving things over from drm.git to the kernel
>> tree, but we were going to do that *anyway* as part of getting it
>> upstream. What will be different is that Dave won't have to do all
>> that work, we can split it up between us and all Dave will need to do
>> is to merge the branch and push it to Linus. This is of course what
>> Eric is already doing with GEM in people.fd.o/~anholt/linux-2.6, and
>> that would be a great way to get the vblank rework upstream too.
> If we do this, I'm going to introduce new rules for features/patches that
> will put a lot more work on people.
> 1. Nobody gets commit access to master branch except me.
> 2. All work is done in topic branches that are throwaway once
> complete. So when the branch owner decides the work is upstreamable,
> They create a set of clean patches against the current master,
> send them to dri-devel for review, if they pass review then the
> branch owner creates a new clean branch and asks me to merge it,
> it also includes Signed-off-by lines.
> Some people say we want the history, Linus wants bisectable history
> so invariable when a feature reaches a useful stage it should go
> upstream in clean s-o-b patches that are bisectable and pass
> checkpatch.pl, not in a 50 separate patches with fixes in it.
> We can generate a throwaway drm-next tree that merges all the topic
> branches currently in play if people want to have some superview.
> 3. All API changes to go to the list as soon as possible (should be done
That all sounds good to me, I think we will benefit from a little
stricter process instead of the free-for-all drm.git repo we have now.
And topic branches sounds very promising; if GEM had been done in a
topic branch off of the upstream linux tree, preparing the patch would
literally be one git diff command, instead of having to sort out the
GEM changes from drm.git. Similarly, Ian's XGI work wouldn't have
used the ttm fences and gotten upstream faster.