Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Brian,

> I spoke to Larry off list and considering the cfg80211 and mac80211 
> situation with older kernels further, he wants me to try and get a 
> simple backports setup validated so that people can still
> `make` and `make install`. 

Sure. That should pretty much, after all, we do it many times every day
with iwlwifi with our internal tree :) But yeah, getting it generated
might take a bit of work.

> He is focused on a few other important tasks 
> and will probably get back with us here later, I just wanted to start 
> running downhill with this ASAP so I slid in here.


> I am going to first try a variation of the approach you suggested where 
> I generate backports for Linux versions in the repo in ascending order 
> then have our Makefile detect user's version and install accordingly.

Wait, no, what? You don't need to detect the user's version or anything.

If you generate a single backports from say v6.6-rc6 today, users should
be able to run it on any kernel as far back as 4.something.

The only time you need _multiple_ backports is if you don't want to
stick to v6.6-rc6 (per example), but want to have v6.6-rc7 this week and
v6.6 release next week.

> Again, my understanding is often the bottleneck so I want to first say 
> what I intend to do and then ask a question:
> 1. I want to use wireless-next as the upstream kernel source for 
> building the backports, I would need to build all backports via the 
> "package release" workflow [1]

Not sure I'd say that - the workflow page [1] is written with
instructions for your *users*, not for *you* as the one providing the

>  in order to provide users with a package 
> that they can use without needing the upstream source on their machine, 
> effectively giving them "a patch file" for compatibility for driver 
> specific modifications and the up-to-date 80211 stack. I would then only 
> need to decide which git tags for older kernels to use for the versions 
> we want to support, create the packages, then include those in the 
> repository.


> [1]

(just to keep the link)

> 2. I am trying to figure this out currently, but am not entirely sure 
> how granular the built package versions have to be in order to work with 
> a users kernel version. How do I decide the coverage of an individual 
> package per major-minor version or other variations? You mentioned RCs 
> earlier. For this first PoC, I want to make sure users can get the 
> driver working for any version they are running going back to 5.4.

No no, misunderstanding here I think. You don't need anything granular
at all, *all* your users should be able to use a *single* current
backports-based package.

The granularity question only comes in when you say have a user who
reports that something doesn't work. Now what, how do you get them to
e.g. bisect? Right now you have a git tree they can normally bisect in.

Now, if you
 - release backports tarballs for them to use, or
 - commit the output of backports into a git tree for them to use

*then* you get into the granularity question, which ends up being a
trade-off between what's effectively bisectability (you don't really
need to care about the history, after all, it's preserved upstream), and
effort on your end to generate (and test) them all.

> After that, our Makefile and/or scripts it coordinates will have to 
> detect the user version, then cd into that package, and install it 
> properly. 

No, you should just give them the output of backports (
directly, it does all this.

> I am suspending any upstream commit history shenanigans for a 
> later point as making sure the driver is performant and in-line with the 
> up-to-date wireless stack.

OK, so then you just need to release a single tarball effectively.
Whether as a git branch or a literal tarball is pretty much irrelevant.

> Being able to use those features and have a 
> consistent API across the components is much more of a priority, at the 
> moment.
> Thank you for you help and patience with all of this. You have helped 
> make this process an enjoyable thing to dive into and I am excited to 
> start hacking on backports.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux