Subject: Re: the path from nathanw_sa -> newlock2
To: Bucky Katz <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 02/15/2007 18:15:49
-----BEGIN PGP SIGNED MESSAGE-----
On Feb 15, 2007, at 16:24, Bucky Katz wrote:
>> Hmm, usually cvs update does a pretty good job merging changes.
>> Certainly works for me ( with occasional conflict solving of course )
> We use perforce internally and have a *lot* of changes to the kernel
> that we haven't submitted. They include proprietary filesystems that
> I can't submit, power management for embedded systems, MI drivers that
> conflict with drivers that were submitted after we finished ours but
> before we could submit ours, a MI layer for NAND support that we
> haven't decided if there's any value in submitting, and
> NetBSD-as-USB-Device USB kernel subsystem that's not ready to submit
> yet, and bug fixes that I simply haven't had time to turn into
> Once a month, I put the tarball snapshots from CVS, make sure they
> build, run a regression of them on an omap target, import them into
> our "NetBSD vendor tree" in perforce and then integrate from there
> into our NetBSD development tree. (My "most of a day" starts at the
Ah, that explains it ( sorry, was just curious )
>>> The problem with a pullup is that we'd have to rebase all of our
>>> stuff back onto 4.0 I believe that rebase would be more work than
>>> coping with the 1:1 change will be.
>> Really? 4.0 was rebranched pretty recently, it can't be that far from
>> HEAD-before-newlock2. I'd almost bet the OMAP stuff hasn't been
> I could be wrong. I was thinking of how much change happened since the
> original 4.0 branch and not the rebranch.
Ah yes, not many people were happy with the first branch.
> But as you can see from the above it's not just OMAP stuff. We've
> tracked changes to the filesystem interfaces for example that I
> believe aren't in 4.0 but are in -current.
There was a lot of work in the vfs area, mainly about locking issues I
think but I could be wrong - not my work area or anything I feel
competent enough to comment on.
>>> We've adapted libpthread to support userlevel thread priorities,
>>> our application needs, and we'll have to redo that adaptation.
>>> the patch I sent Andrew to review.)
>> Seriously - did you even look at the 4.0 branch? Or am I missing
>> something here?
> We've been working in -current for over a year. If I recall correctly,
> the original 4.0 branch was in November. Maybe the rebranch would make
> it easier.
I'm pretty sure it will.
> But the other aspect of our staying in -current was my (possiblly
> incorrect) understanding that if we submitted new bits, such as the
> USB device subsystem, they'd go in current and not a stable branch.
They'd go first into -current.
> Given that you now know that we intend to submit some large chunks of
> functionality should we be working in -current?
That would certainly be easier for us.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----