Date: Wed, 6 Mar 2024 15:51:11 -0800 From: Warner Losh <imp@bsdimp.com> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: freebsd-git@freebsd.org Subject: Re: vendor imports beyond the committers guide? Message-ID: <CANCZdfrsY93UyEGo=_6X%2BpmSfAKV2LgnUZHbC6x-po0mJv0KCg@mail.gmail.com> In-Reply-To: <q31p1656-6r83-0099-495p-7or9377s4131@serrofq.bet> References: <n4p4714r-2n97-psq3-34p2-887qq0o1354q@SerrOFQ.bet> <CANCZdfpDDx=riEdExdpzmr6DHy7%2Bgpifm_1aJMcmGiSYAeVrgw@mail.gmail.com> <5pps4nrs-or51-9018-sqp4-7q69s4780r61@serrofq.bet> <Zeig9nKD-Onc58T1@cell.glebi.us> <CANCZdfqxF-oQvc_W1jMKs=F5SE13_NmtvFOnPetr5JH6fBcPaA@mail.gmail.com> <nr98n9r4-58r6-rn91-1p01-58q56260rn66@serrofq.bet> <CANCZdfpyDQPcm2O6tzF4M91u7Pw_XhA5ihpCMON8=w7-YLezpw@mail.gmail.com> <q31p1656-6r83-0099-495p-7or9377s4131@serrofq.bet>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000d611ab061306a240
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey Bjoern,
On Wed, Mar 6, 2024 at 11:44=E2=80=AFAM Bjoern A. Zeeb <bz@freebsd.org> wro=
te:
> On Wed, 6 Mar 2024, Warner Losh wrote:
>
> > On Wed, Mar 6, 2024 at 10:19=E2=80=AFAM Bjoern A. Zeeb <bz@freebsd.org>=
wrote:
> >
> >> On Wed, 6 Mar 2024, Warner Losh wrote:
> >>
> >>> On Wed, Mar 6, 2024 at 8:59=E2=80=AFAM 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 base=
d
> >> 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 prop=
er
> >>>> 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 th=
e
> >>> 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 thes=
e
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
--000000000000d611ab061306a240
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hey Bjoern,<br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 6, 2024 at 11:=
44=E2=80=AFAM Bjoern A. Zeeb <<a href=3D"mailto:bz@freebsd.org">bz@freeb=
sd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Wed, 6 Mar 2024, Warner Losh wrote:<br>
<br>
> On Wed, Mar 6, 2024 at 10:19=E2=80=AFAM Bjoern A. Zeeb <<a href=3D"=
mailto:bz@freebsd.org" target=3D"_blank">bz@freebsd.org</a>> wrote:<br>
><br>
>> On Wed, 6 Mar 2024, Warner Losh wrote:<br>
>><br>
>>> On Wed, Mar 6, 2024 at 8:59=E2=80=AFAM Gleb Smirnoff <<a hr=
ef=3D"mailto:glebius@freebsd.org" target=3D"_blank">glebius@freebsd.org</a>=
><br>
>> wrote:<br>
>>><br>
>>>>=C2=A0 =C2=A0Bjoern,<br>
>>>><br>
>>>> On Wed, Mar 06, 2024 at 12:37:07AM +0000, Bjoern A. Zeeb w=
rote:<br>
>>>> B> > These details likely need to be documented, but=
what's the details<br>
>>>> here that<br>
>>>> B> > you need to do?<br>
>>>> B><br>
>>>> B> I may want to track the (unchanged) versions of the =
LinuxKPI based<br>
>> wifi<br>
>>>> drivers<br>
>>>> B> in sys/contrib/dev so we can more easily diff agains=
t the latest<br>
>>>> upstream<br>
>>>> B> import and ship changes back etc.<br>
>>>><br>
>>>> Can you please give an example, e.g. this the the director=
y in our tree<br>
>> and<br>
>>>> this is the origin we want to make the vendor import from.=
=C2=A0 I will<br>
>>>> experiment<br>
>>>> and produce a sequence of git commands you'd need to d=
o to make proper<br>
>>>> subtree import. Warner will check me :)<br>
>>>><br>
>>><br>
>>> He wants to do this with the Linux drivers we have in the tree=
...<br>
>>><br>
>>> So we should get the version he started with, import that into=
the vendor<br>
>>> branch (for each driver, since they are separately released an=
d<br>
>> versioned).<br>
>>> Once we do that, we can do a subtree merge, but we may have to=
jump<br>
>> through<br>
>>> some hoops so we wind up back to the current files. I have ide=
as how to<br>
>> do<br>
>>> this, but haven't done it yet. Once we have those, we can =
switch to<br>
>> updating<br>
>>> them via the standard vendor import stuff....<br>
>>><br>
>>> So I know I skipped an email in this change... if you, Bjorn, =
have the<br>
>>> files / pointers<br>
>>> or whatever that you started with, I can import those, do the =
merge, then<br>
>>> we can look<br>
>>> at updating. I'm hoping the number of changes are relative=
ly small...<br>
>><br>
>> I can probably produce (for each driver) a set of the original<br>
>> unmodified files which then went into FreeBSD with modifications<b=
r>
>> if we do need the entire history and not just the set from the lat=
est<br>
>> import?<br>
>><br>
><br>
> How many versions are there?<br>
<br>
- iwlwifi I think it is 5 full versions (and 3 or 4 "remote cherry pic=
ks" in<br>
=C2=A0 =C2=A0between in case it matters)<br>
<br>
- rtw88 probably 3 versions<br>
<br>
- the others {rtw89, ath10k, ath11k, ath12k, mt76} I think it was only 2 ea=
ch.<br></blockquote><div><br></div><div>It might be useful to have all the =
versions imported. At this point, though,</div><div>I do not know how to ad=
d the dependency arc to the right point between these</div><div>and the now=
-historical imports. There's extensions to add parents, but I don't=
</div><div>think it would work for this.</div><div><br></div><div>So, the m=
inimum we need is the latest versions. Creating a 'as merged' tree =
from</div><div>them will help future imports, which is the primary goal, I&=
#39;d argue, for the vendor</div><div>trees.</div><div><br></div><div>If we=
imported=C2=A0each of the versions (exclusive of the cherry-picks). in ord=
er and</div><div>then merged, this would give us a better history. The comm=
it messages of the old</div><div>versions could include the hash where it w=
as committed=C2=A0to the tree's main branch.</div><div>This might be wi=
se, since it would allow us to add these links in the future if that</div><=
div>functionality is added to git (or someone cures me of my ignorance). I =
think that</div><div>if these versions were trivial to get, we should do it=
. If they are a hassle, then we</div><div>can forego them. The possible fut=
ure benefit is speculative at best, so if there's</div><div>more than a=
tiny amount of hassle, we should skip doing each version.</div><div><br></=
div><div>Warner</div></div></div>
--000000000000d611ab061306a240--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrsY93UyEGo=_6X%2BpmSfAKV2LgnUZHbC6x-po0mJv0KCg>