vendor/illumos merges

[Mark Johnston]

On Sat, Apr 24, 2021 at 12:44:40PM +0200, Ulrich Spörlein wrote:
> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote:
> >Hi,
> >
> >Now that FreeBSD uses OpenZFS as the upstream for ZFS, vendor/illumos is
> >mostly unused.  However, we still use illumos as an upstream for CTF
> >tools and DTrace, though there haven't been any imports in a while.
> >
> >illumos has put a lot of work into their CTF toolchain, and I'd like to
> >import that.  There are a couple of snags that I'd appreciate some
> >guidance on.
> >
> >First, I believe I should delete now-unused ZFS code from the vendor
> >branch and merge the result to main.  I did this locally and got an
> >empty merge, which is what I'd expect.  Is there any problem with this?
> 
> Why would you record this empty merge? If you clean up vendor/foo, just 
> do that but don't merge a no-op back into main (nothing changed, after 
> all).

Ok, I guess there is no reason to merge that change separately.  It
will end up being merged with subsequent imports though.

> >Second, with Subversion we had both vendor/illumos and
> >vendor-sys/illumos, and now we just have the former, seemingly with
> >sys/* bits imported from vendor-sys.  Some of the upstream commits touch
> >both userspace and kernel bits, but the merge targets for these in
> >FreeBSD are different: cddl/contrib/opensolaris vs.
> >sys/cddl/contrib/opensolaris.  How should I merge into main in this
> >case?  I don't really see any options other than to split each offending
> >upstream commit into two parts, one for userspace and one for the
> >kernel, and merge them separately.
> >
> >If it helps to look at the branch where I staged the upstream commits,
> >I've pushed it to vendor/illumos2 in https://github.com/markjdb/freebsd
> >.
> 
> Can you clarify why the merging of the two might be an issue? Note that 
> unlike subversion, in git there's no "merge a certain subtree" handling, 
> all that is recorded is a tree of some form and then a set of parents or 
> ancestor commits. (git is a content tracker, not really a VCS :)
> 
> I was under the impression that userland and kernel imports/merges need 
> to happen at the same time anyway, so I assume you would import all the 
> bits under vendor/foo in 1 commit and then merge them in 1 commit into 
> main. Is that not how it goes?

How can I do that with git subtree merge?  Suppose an illumos commit
modifies cmd/dtrace/foo.c (userspace) and uts/common/dtrace/foo.c
(kernel).  That maps to cddl/contrib/opensolaris/cmd/dtrace/foo.c and
sys/cddl/contrib/opensolaris/uts/common/dtrace/foo.c in FreeBSD,
respectively.  So to do a subtree merge, I need to use distinct prefixes
depending on whether I'm importing userspace or kernel changes.  When
they are mixed together, it's not clear to me how I can merge at all.

I see that for OpenZFS we keep all code, including userspace code, under
sys/contrib/openzfs, so it doesn't have this problem.