Re: vendor imports beyond the committers guide?

From: Warner Losh <imp_at_bsdimp.com>
Date: Wed, 06 Mar 2024 23:51:11 UTC
Hey Bjoern,

On Wed, Mar 6, 2024 at 11:44 AM Bjoern A. Zeeb <bz@freebsd.org> wrote:

> On Wed, 6 Mar 2024, Warner Losh wrote:
>
> > On Wed, Mar 6, 2024 at 10:19 AM Bjoern A. Zeeb <bz@freebsd.org> wrote:
> >
> >> On Wed, 6 Mar 2024, Warner Losh wrote:
> >>
> >>> On Wed, Mar 6, 2024 at 8:59 AM Gleb Smirnoff <glebius@freebsd.org>
> >> wrote:
> >>>
> >>>>   Bjoern,
> >>>>
> >>>> On Wed, Mar 06, 2024 at 12:37:07AM +0000, Bjoern A. Zeeb wrote:
> >>>> B> > These details likely need to be documented, but what's the
> details
> >>>> here that
> >>>> B> > you need to do?
> >>>> B>
> >>>> B> I may want to track the (unchanged) versions of the LinuxKPI based
> >> wifi
> >>>> drivers
> >>>> B> in sys/contrib/dev so we can more easily diff against the latest
> >>>> upstream
> >>>> B> import and ship changes back etc.
> >>>>
> >>>> Can you please give an example, e.g. this the the directory in our
> tree
> >> and
> >>>> this is the origin we want to make the vendor import from.  I will
> >>>> experiment
> >>>> and produce a sequence of git commands you'd need to do to make proper
> >>>> subtree import. Warner will check me :)
> >>>>
> >>>
> >>> He wants to do this with the Linux drivers we have in the tree...
> >>>
> >>> So we should get the version he started with, import that into the
> vendor
> >>> branch (for each driver, since they are separately released and
> >> versioned).
> >>> Once we do that, we can do a subtree merge, but we may have to jump
> >> through
> >>> some hoops so we wind up back to the current files. I have ideas how to
> >> do
> >>> this, but haven't done it yet. Once we have those, we can switch to
> >> updating
> >>> them via the standard vendor import stuff....
> >>>
> >>> So I know I skipped an email in this change... if you, Bjorn, have the
> >>> files / pointers
> >>> or whatever that you started with, I can import those, do the merge,
> then
> >>> we can look
> >>> at updating. I'm hoping the number of changes are relatively small...
> >>
> >> I can probably produce (for each driver) a set of the original
> >> unmodified files which then went into FreeBSD with modifications
> >> if we do need the entire history and not just the set from the latest
> >> import?
> >>
> >
> > How many versions are there?
>
> - iwlwifi I think it is 5 full versions (and 3 or 4 "remote cherry picks"
> in
>    between in case it matters)
>
> - rtw88 probably 3 versions
>
> - the others {rtw89, ath10k, ath11k, ath12k, mt76} I think it was only 2
> each.
>

It might be useful to have all the versions imported. At this point, though,
I do not know how to add the dependency arc to the right point between these
and the now-historical imports. There's extensions to add parents, but I
don't
think it would work for this.

So, the minimum we need is the latest versions. Creating a 'as merged' tree
from
them will help future imports, which is the primary goal, I'd argue, for
the vendor
trees.

If we imported each of the versions (exclusive of the cherry-picks). in
order and
then merged, this would give us a better history. The commit messages of
the old
versions could include the hash where it was committed to the tree's main
branch.
This might be wise, since it would allow us to add these links in the
future if that
functionality is added to git (or someone cures me of my ignorance). I
think that
if these versions were trivial to get, we should do it. If they are a
hassle, then we
can forego them. The possible future benefit is speculative at best, so if
there's
more than a tiny amount of hassle, we should skip doing each version.

Warner