On Thu, 2008-07-31 at 19:53 -0700, Jesse Barnes wrote: > On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote: > > > Well, if the overhead of merging upstream is a concern, then how about > > > not worrying about bc at all and let people who want to back port deal > > > with it? Oh, and what about just keeping the drm drivers in a linux > > > kernel tree? That'll make upstream merging even easier yet... > > > > The less crap I have to remove from the diffs the better, I have a script > > and it removes stuff mostly fine, maybe someone should actually bring this > > idea up on the list with a proper plan for how to deal with > > > > a) BSD > > I'd like to hear Robert's concerns here, but I've been working with some of > the BSD folks lately, and it seems like the main concerns are: > 1) making it easy for contributors to identify which portions of code are > shared > 2) licensing > Since both the BSDs and Linux effectively copy code out of the DRM repo and > into their respective kernel trees at this point, having the actual repo > based on one of them shouldn't be an issue as long as both 1 and 2 are > handled. The remaining compat macros could probably just be wrapped in some > sort of Linux equivalent (DRM_SPINUNLOCK->spin_unlock, what's the > difference?), or we could annotate things for the BSD guys to run scripts > over. As it stands, they still have to go over things by hand anyway...
As an ex-BSD kernel maintainer, I stood against moving to a linux
kernel-based tree for a long time. For a long time I felt like I was
the only guy holding back the move. I couldn't get NetBSD to work in
the "upstream" tree, and it sounds like OpenBSD's following the same
route, so maybe I was doing it wrong all along in trying to have one
tree for all OSes to share.
Entries 1 and 2 in the list were of concern to me for quite some time,
as those championing the move to a linux tree were doing it primarily
for GPL and style motivations (at least vocally). I didn't like the GPL
motivation, and felt like we had other avenues to fix the style
motivation (which I eventually worked on, and was about half done with I
think).
The other problem as a BSD maintainer was how to merge code. Originally
all I had available was CVS and cp, so the shared-code system we had was
useful -- I just worked in the DRM tree and periodically copied changes
over and cvs committed. Eventually I got perforce access, and was
trying to use that to manage merges, but CVS IDs and perforce diff
formatting and performance issues made it more work than copying diffs
by hand. I settled on a series of seds on the DRM tree and cping it to
the BSD tree, which worked reasonably well.
Luckily, those times are past. We've got git now. If I was doing BSD
at this point, I would probably rather set it up as a branch of a
linux-2.6 kernel tree that I merged from:
Initial setup today:
cd linux-2.6
git-checkout -b freebsd-drm
cd drivers/gpu/drm
cp ~/src/drm/bsd-core/drm*.[ch] .
cp ~/src/drm/bsd-core/i915/Makefile i915/
cp ~/src/drm/bsd-core/i915*.[ch] i915/
(etc)
git-add .
git-commit -a -v
Next merges:
git-merge origin/master
(resolve conflicts and make it compile again as linux-specific bits
trickle in)
git commit -a
Then I could use my old script for copying an external tree into the
FreeBSD repo and continue doing mega-commits as before. The advantage
here is that since I'm merging the linux-specific OS side, I don't have
to go and read the two side-by-side all the time to make sure they
haven't drifted too far apart, which was almost all of the time I spent
working on the BSD code. This is assuming that the two codebases stay
close enough together for the merger to do something sane, but I think
that would be the case for the most part. To improve that, I'd add more
compat macros to leave the FreeBSD side more linux-looking. FreeBSD's
grown a layer for taking osol code mostly as-is for the ZFS and dtrace
ports, and I think growing some compatibility for taking mostly
linux-looking code would probably be a sensible plan for maintaining
this codebase, and would probably help various other potential FreeBSD
projects as well.
I don't think anyone is proposing changing the licensing of DRM code
this time around, so with this plan as a BSD guy I wouldn't even care
which parts of the code were "shared" versus "os-specific".
> > b) backwards compat for using updated DRM drivers on older kernels.
Since I'm now maintaining a linux-2.6 tree for getting my GEM work
merged, I'm having to deal with backporting concerns already. The plan
I'm proposing for our project is for us to do topic branches like other
linux kernel developers, propose them for merge either through you or
directly, and maintain one branch for "all the things I want on top of
current linux kernel to get what we need." As we head towards our
quarterly release, I'll prepare a branch against the latest released
kernel of everything we need for the quarterly release, which is then
the stuff that backporters would take up and integrate into whatever
ancient-yet-doesn't-resemble-any-release-ever mess they've got.
This gets us better merge process ("here's my short patch series on top
of linus"), something believable for our project's stable release (full
kernel, not a pile of kernel code that might work as long as you've
added our kernel subsystem patches and you're not running a distro
that's patched in changes to other function arguments anyway), and a
clear message for backporters of what they need for the new hotness.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
