Mailinglist Archive: opensuse-kernel (43 mails)

< Previous Next >
Re: [opensuse-kernel] Planned restructuring of kernel-firmware package
On Fri, 16 Aug 2019 12:11:26 +0200,
Michal Suchánek wrote:

On Sat, 10 Aug 2019 15:41:02 +0200
Takashi Iwai <tiwai@xxxxxxx> wrote:

On Sat, 10 Aug 2019 10:35:18 +0200,
Takashi Iwai wrote:

On Sat, 10 Aug 2019 10:04:36 +0200,
Michal Suchánek wrote:

On Sat, 10 Aug 2019 09:31:02 +0200
Takashi Iwai <tiwai@xxxxxxx> wrote:

On Fri, 09 Aug 2019 21:40:30 +0200,
Michal Suchánek wrote:

On Fri, 09 Aug 2019 17:57:02 +0200
Takashi Iwai <tiwai@xxxxxxx> wrote:

- The firmware files are split into a bunch of sub-packages (e.g.
kernel-firmware-iwlwifi, kernel-firmware-media, etc), so that
can install only a small set of firmware files.
Each firmware file is compressed in XZ format, hence these
are supported only by 5.3 or later kernel.
And each package contains Supplements rpm tag for module aliases
that are generated from our current and past kernel binaries, so
that the sub-package your hardware requires may be installed
automatically via zypper install-recommends.

I think importing aliases from different package is fragile and
to getting outdated. What is the advantage?

The package dependency. kernel-firmware itself is noarch, and yet we
need the modaliases from all kernel archs and flavors. If we extract
the modaliases at the build time, we'd need to fetch all these at each

Clearly the packages containing kernel modules know their aliases
required firmware at build time, and the firmware packages know the
firmware they contain at build time too. So providing/recommending
firmware files should give working drivers so long as a package that
contains the firmware is available.

Yes, this direction of the firmware requirement would work as well.
OTOH, a downside is that this will bring all firmwares of the
installed driver modules that aren't used -- e.g. when you install
kernel-default, it'd drag effectively all kernel firmware files even
if you don't use all of them.

In anyway, both mechanisms aren't mutual exclusive, we can implement
both for completeness.

With the necessity to shuffle data between different packages the
is going to break, especially if we ever want to use one firmware
package on multiple codestreams.

Well, we may provide an option:

- Install firmware per recommends from kernel binary:
this will install lots of unneeded files but safer. This can be the
default behavior of the installer. Almost equivalent with the
current state, too (kernel-default recommends kernel-firmware).

- Install firmware per modaliases:
the system would set up the appropriate locks to kernel-firmware and
kernel-firmware-all, and prune the unneeded firmware packages.
Maybe this is a feature implemented on YaST, I don't know whether we
can do by any other smart method.

For this you don't need the modaliases in the firmware, though. You will
know which modules are used by modalias and infer which firmware is
needed from module requirements. I suppose writing a separate tool for
this is OK. yast can integrate it if desired.

Right, it's about the timing when the modalias <-> firmware mapping
needs to be generated.

Rethinking on the suggested idea, I believe the biggest obstacle is
how to trigger this new post-installation. For the new way, we'll

- Read modules.alias or whatever and list up the modules that match
with the running system configuration (PCI, USB, etc).

- Read modinfo output (or some static mapping for extra) for the
listed modules and install the firmware files;
the firmware files can be found as firmware($FILE) Provides of
kernel-firmware-* package rpms.

Why do you need to do anything this complicated? If the module is
installed it will pull in the firmware.

... by Recommends: kernel-firmware, and it enforces all firmware

If you customize the list of
modules to install (eg. you list modules by modalias, append that to
kernel-default-base.spec, and rebuild it) then you get potentially less
firmware files.

No, the mapping between modalias and the corresponding firmware is
completely missing in the package level. That's the whole point. The
Supplements with modalias is essentially device-info -> f/w mapping.

If not you get everything by default.


So, in the current situation, you'll get everything in anyway, nothing
different from today.

However, you can still do zypper addlock kernel-firmware
kernel-firmware-all to avoid the catch-all packages. Then you'd need
some mechanism to choose which firmware to install. The modalias is
one of the ways that have been confirmed to work over a decade.

The maintenance of the modalias is yet another question, yes, and as
already mentioned, I'm not sticking with this. But, as of today,
there is nothing better way than a static mapping.

That said, the current static modalias is a stop-gap solution until
the other better way becomes ready.


To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kernel+owner@xxxxxxxxxxxx

< Previous Next >