On Sat, 10 Aug 2019 15:41:02 +0200, Takashi Iwai 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
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
wrote: Hello, Hi,
- The firmware files are split into a bunch of sub-packages (e.g. kernel-firmware-iwlwifi, kernel-firmware-media, etc), so that user can install only a small set of firmware files. Each firmware file is compressed in XZ format, hence these packages 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 prone 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 build.
Clearly the packages containing kernel modules know their aliases and required firmware at build time, and the firmware packages know the firmware they contain at build time too. So providing/recommending the 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 thing 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 need:
- 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.
And I have no idea whether whole this procedure can be integrated into any existing package installation phase. Or, would we schedule another script at post(trans) and there we'll rerun zypper again for the requested firmware files?
Also I don't know what's the easiest implementation for the first item. Any existing framework for that?
Anyways, I pushed my current work to OBS Kernel:HEAD and submitted to Factory now, so that it can be included in SLE15-SP2 / Leap 15.2. The suggested changes would be nicer, but it requires the additional stuff in other packages, so it'd take more time. Since the current modalias stuff won't conflict with it, we can switch to it later gracefully once after it's actually implemented. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org