NAK/cmmt: [PATCH V2 0/6][SRU][OEM-5.14/Jammy/OEM-5.17/Unstable] build backport-iwlwifi-dkms as linux-modules-iwlwifi-ABI

Tue Apr 26 15:20:51 UTC 2022

Overall this is good, and imho is almost ready to land into
linux-unstable. But some tweaks are still required to make a V3 patch
series:

1) rename the flag standalone=1 to type=standalone (mentioned in
another email as reply to patch 5/6)

2) correctly mark existing modules as type=built-in and the iwlwifi
one as type=standalone (see reply to patch 5/6)

3) drop metapackage from src:linux; provide a new patch to build
linux-modules-MODULE-FLAVOUR-VARIANT from src:linux-meta (or explain
why that meta works)

4) fix dkms module install paths for type=built-in and type=standalone

5) all of the dkms-versions changes should be collected together, as a
single commit, against
https://git.launchpad.net/~canonical-kernel/+git/kernel-versions/tree/dkms-versions/jammy:main
and we should test existing kernel builds that adding all of these
key=value pairs doesn't affect existing builds (it shouldn't). This
will start propagating the dkms-versions updates in a kernel cycle to
all the kernels, without actually changing anything.

6) Submit patch to
https://git.launchpad.net/~canonical-kernel/+git/kernel-versions/tree/update-dkms-versions
such that debpath is updated correctly (as mentioned in the other
email). One can test this by setting a given dkms version to a lower
version in both column 2 and debpath=, rerun the script locally and
observe that it correctly updates version number in both column two
and debpath.

7) then the rest of debian/* stuff can be committed as a single patch,
on top of a tree with updated dkms-versions. To convert a given kernel
from the old one-by-one dkms way, to this unified and declarative way.
Starting with linux-unstable, then linux-oem-5.17 & jammy:linux

In a force majeure situation, dkms-versions will be able to just stay
the same / unchanged, and one would be able to revert a single patch
of the kernel tree & recrank if somehow these changes do not produce
equivalent results to before for the rest of the things.

Hopefully that's it =/ but maybe new issues will be found when reviewing V3.

--
okurrr,

Dimitri

On Fri, 22 Apr 2022 at 18:11, You-Sheng Yang <vicamo.yang at canonical.com> wrote:
>
> From: "You-Sheng Yang (vicamo)" <vicamo.yang at canonical.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1969434
>
> [Impact]
>
> Intel AX211 iwlwifi -64 firmware may fail to init under reboot stress,
> and -67 is immune. FW API -64 supported by oem-5.14, and -67 in v5.16.
> Not reproducible on every platform with AX211 installed, and the chances
> of such failures vary from one to another.
>
> [Fix]
>
> A few solutions were considered. The very first one is to ask Intel to
> fix -64 firmware directly, and the answer is a solid no claimed -64 is
> not the planned production version of AX211.
>
> It's also possible to backport FW API from v5.16, but while iwlwifi FW
> API is more or less a black box to us and the new FW APIs also depends
> on updates on the wireless stack, this is going to be very risky and
> actually we had regressions before after such backports.
>
> The last viable solution is to run backport-iwlwifi-dkms >= rev 8580 on
> the effected platforms. This means oem-5.14 and its migration target,
> hwe-5.15 will not be able to drive this piece of hw flawlessly without
> backport-iwlwifi-dkms installed.
>
> However, while we need secureboot to be enabled on these platforms,
> backport-iwlwifi-dkms must also be signed somehow. There are two
> possible method to achieve this, too. One, to prebuild this dkms as zfs
> and v4l2loopback does. However, while backport-iwlwifi-dkms generates
> kernel modules with exactly the same name as the in-tree ones, when
> prebuilt, they'll be available directly from the linux-modules package
> and therefore overrides the in-tree ones always, turning the in-tree
> driver completely useless and risk the stability of all other generic
> installations.
>
> The second one is to build backport-iwlwifi-dkms as nvidia graphic
> drivers in the linux-restricted-modules source package. In this way,
> affected platforms may install the corresponding packages when needed
> without interfering others. However, l-r-m is for restricted modules
> that needs special care of redistribution of its binaries, and
> backport-iwlwifi-dkms is GPL licensed.
>
> Here a similar but simpler process in the main kernel tree is
> re-implemented. Two additional packages,
> linux-modules-MODULE-PKGVER-ABINUM-FLAVOUR and its meta package
> linux-modules-MODULE-FLAVOUR will be created.
>
> [Test Case]
>
> Test builds:
> ./jammy/amd64/linux-modules-iwlwifi-5.15.0-27-generic_5.15.0-27.28_amd64.deb
> ./jammy/amd64/linux-modules-iwlwifi-generic_5.15.0-27.28_amd64.deb
> ./unstable/amd64/linux-modules-iwlwifi-5.17.0-8-generic_5.17.0-8.8_amd64.deb
> ./unstable/amd64/linux-modules-iwlwifi-generic_5.17.0-8.8_amd64.deb
> ./oem-5.17/amd64/linux-modules-iwlwifi-5.17.0-1003-oem_5.17.0-1003.3_amd64.deb
> ./oem-5.17/amd64/linux-modules-iwlwifi-oem_5.17.0-1003.3_amd64.deb
> ./oem-5.14/amd64/linux-modules-iwlwifi-5.14.0-1033-oem_5.14.0-1033.36_amd64.deb
> ./oem-5.14/amd64/linux-modules-iwlwifi-oem_5.14.0-1033.36_amd64.deb
>
> [Where problems could occur]
>
> Different from nvidia packages built from l-r-m, the generated package
> names do not carry an additional short version string, e.g. nvidia-410,
> as there is no such necessity to build multiple versions of iwlwifi.
> The modules are installed to /lib/modules/<kver>/kernel/iwlwifi, not
> iwlwifi-9858/.
>
> V2:
> * extend debian/dkms-versions to carry all the module specific
>   parameters. Also rewrite debian/scripts/control-create a bit to lookup
>   module name automatically.
> * add arch=foo in debian/dkms-versions. This also removes do_<module>
>   settings in $DEBIAN/rules.d/<arch>.mk. Their initial values will be
>   assigned automatically if not already specified.
> * add rprovides=foo in debian/dkms-versions.
> * support dkms_include and dkms_exclude settings. When enlisted, a
>   specified module will become available to the current arch if not
>   explicitly excluded again in dkms_exclude.
> * rewrite those do_<module>_disable as well.
> * indentation and white spaces.
> * fix build failure when multiple standalone modules are involved.
> * bump backport-iwlwifi-dkms version.
> * remove do_standalone_dkms from V1 as we don't need it.
>
> You-Sheng Yang (vicamo) (6):
>   UBUNTU: [Packaging] refactor dkms-versions to carry modulename
>   UBUNTU: [Packaging] add debpath= in dkms-versions
>   UBUNTU: [Packaging] add rprovides= in dkms-versions
>   UBUNTU: [Packaging] add arch= in dkms-versions
>   UBUNTU: [Packaging] support build dkms as standalone package
>   UBUNTU: [Packaging] support building backport-iwlwifi-dkms as
>     standalone modules
>
>  debian.master/rules.d/amd64.mk       |  2 --
>  debian.master/rules.d/arm64.mk       |  1 -
>  debian.master/rules.d/ppc64el.mk     |  1 -
>  debian.master/rules.d/s390x.mk       |  2 --
>  debian/control.d/flavour-module.stub | 30 ++++++++++++++++++++
>  debian/dkms-versions                 |  5 ++--
>  debian/rules                         | 25 ++++++++---------
>  debian/rules.d/0-common-vars.mk      | 36 ++++++++++++++++++++++++
>  debian/rules.d/2-binary-arch.mk      | 42 ++++++++++++++++++++++------
>  debian/scripts/control-create        | 28 +++++++++++++++++++
>  10 files changed, 143 insertions(+), 29 deletions(-)
>  create mode 100644 debian/control.d/flavour-module.stub
>
> --
> 2.34.1
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team