> > > > 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.
Not allowed anymore, including version.h is a red flag nowadays.. > 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. Well XGI isn't going upstream as last I heard from IBM it still didn't work, and they scrapped the XGI plan and bought a bunch of X1650s once Ben and myself fixed the endianness issues. While I'd like to believe preparing the patch would be one git diff away, I suspect it would have been 15 cherry-picks, a couple of merges, a few interactive rebases and a batch of checkpatch.pls away. Nothing is ever a git diff away from upstream. So we would need to find a way to get all the compat hacks into two/three files with no version checks in the actual code. Sounds "icky". Or someone who cared enough would need to maintain a separate repo for old kernels. Dave. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
