Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Owain Ainsworth <zerooa <at> googlemail.com>
Subject: Re: [PATCH 1/1] Adapt on_each_cpu
Newsgroups: gmane.comp.video.dri.devel
Date: Friday 8th August 2008 09:08:35 UTC (over 9 years ago)
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=/
--
 
CD: 16ms