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 packages. > 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. Yes. > [1] https://backports.wiki.kernel.org/index.php/Documentation/packaging (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 (gentree.py) 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. > :) johannes
