On Thu, Aug 07, 2008 at 04:08:49PM -0700, Eric Anholt wrote:
> > > 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.
As the OpenBSD maintainer it's probably time I mention my reasons for
working "out of tree". It's quite simple really, In my experience of
porting over the code, I found that the BSDs, while similar, are no
where near identical, and in the end the level of #ifdefing in the
bsd-core area just got insane, it made maintainance a nightmare. So I
started working out of tree. If i find a general bug, I reformat
against git and send the patch upstream. Otherwise, I watch what happens
to git and merge it into my kernel tree along with any OpenBSD specific
changes i've needed. This is more like the way the BSDs have shared code
for a while now. I know myself and Robert differ on our opinions here,
though. I find it better to be able to go over things by hand, it means
I better understand what I'm merging, anyway.
For that reason, i'm not against master going to a linux kernel tree,
since it would change my process very minimally. As long as the
licensing doesn't change (IMHO drm is essentially a part of X, and thus
should be X11/MIT licensed), I'm fine with it.
Process-wise, I'm in agreement with Dave Airlie, that master should
track what's in linus' tree, with the rest on branches. Also, I think
vblank-rework is now stable enough to go upstream, i've found it has
started to work quite nicely.
Just my 2p,
-0-
--
There's no easy quick way out, we're gonna have to live through our
whole lives, win, lose, or draw.
-- Walt Kelly
-------------------------------------------------------------------------
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
