On Fri, 16 Aug 2019 12:11:26 +0200 Michal Suchánek <msuchanek@suse.de> wrote:
On Sat, 10 Aug 2019 15:41:02 +0200 Takashi Iwai <tiwai@suse.de> 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@suse.de> 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@suse.de> 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.
Why do you need to do anything this complicated? If the module is installed it will pull in the 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. If not you get everything by default.
Or in other words where do we do any selection of modules to install, at all? The only case is - select kernel-default, kernel-default-base or any other kernel-deafult-foo - select any additional KMP to install In any of these cases the package you select for installation can depend on required firmware on its own without any additional scripting, shuffling modaliases between packages, manually created tables that are bound to get outdated, etc. Or what am I missing? Thanks Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org