Re: vendor imports beyond the committers guide?
- Reply: Gleb Smirnoff : "Re: vendor imports beyond the committers guide?"
- In reply to: Bjoern A. Zeeb: "Re: vendor imports beyond the committers guide?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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