On Fri, 16 Aug 2019 16:50:53 +0200 Takashi Iwai <tiwai@suse.de> wrote:
On Fri, 16 Aug 2019 16:13:07 +0200, Michal Suchánek wrote:
On Fri, 16 Aug 2019 15:58:47 +0200 Takashi Iwai <tiwai@suse.de> wrote:
On Fri, 16 Aug 2019 15:44:55 +0200, Michal Suchánek wrote:
On Fri, 16 Aug 2019 15:39:54 +0200 Takashi Iwai <tiwai@suse.de> wrote:
On Fri, 16 Aug 2019 15:32:26 +0200, Michal Suchánek wrote:
On Fri, 16 Aug 2019 13:34:58 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 16 Aug 2019 12:17:30 +0200, > Michal Suchánek wrote: > > > > 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? > > As mentioned in the previous post, there is no mapping between device > info and firmware files provided in a form that can be used by > resolver at the point you install these kernel modules.
It is, in the dependencies of the package containing the kernel modules.
Sorry, I don't get your point.
Suppose you're installing kernel-default.rpm on your laptop and you want to install only the firmware for WiFi chip on the machine. How would the installer find it out only from the package information?
And you are running what on the laptop when the installer is running? Do you not have a kernel?
The installer doesn't have to load the module at the installation time.
And why would you want to do that, anyway? If you replace the WiFi card you lose connectivity.
This action is what many users have demanded for long time. The selected firmware installation is the only way to reduce the installation size significantly, after all.
Selected, yes. Selected per device, no.
Ifsomething missing in future, of course you'll need either net or media access. But it's often not that fatal. If there is a net or media access, all you need is to run "zypper install-recommends".
It will be like Windows. Your network card died, you replace it, and you do not have the firmware for the new card. You can plug in an USB network card but don't have the firmware for that either. So in the end you will frantically search for a thumb drive, download some package using the web browser on another computer with no security verification whatsoever and manually force-feed it to the defunct system. Great, isn't it?
You have the rescue media in that case. It's like Windows, so why not? Users are used to that ;)
(And how often does it happen nowadays? Most of cheap USB network devices run fine without firmware...)
In anyway, we won't mandate this installation scenario. The default should be still install-all mode.
And of course "zypper install-recommends" cannot fix it. If it did the firmware would be there to start with because installing recommends is the default.
The Supplements with modalias would still match even if you lock out kernel-firmware. So the kernel-firmware-xxx sub package would match and be installed accordingly via zypper inr.
What you might want to do is put drivers like liquidio or amdgpu that have huge firmware into a separate package and not install them at all if you do not need them.
Well, it's exactly the goal of the new kernel-firmware packaging...
So it needs to be matched with kernel module packaging.
Yes, and the frequency of the modalias changes isn't that high, so we can follow manually. It was the reason I took this approach for now. I know this is pretty sub-optimal, so no need to go deeper wrt this point.
Don't get me wrong: I don't push this installation mode as default. But at least it allows users to do that (only manually, so far).
You can manually do it without supplement tables. Remove firmware you don't want, lock it, done.
And how can a novice user know which firmware file, and more important,y which corresponding kernel-firmware-xxx package is required and which not? The manual inspection isn't always trivial.
That's where I see room for improvement. Providing commandline tool that does the inspection would be nice.
Does not need to be integrated into the installer, either. It's not like a freshly installed system is supposed to be so tight on disk space that a few hundred MB extra firmware files won't fit.
I can't agree with that; a few hundreds MB is a few hundreds MB, not a nut. It's still huge.
And, comparing with other distros regarding this area (storage saving), I'm afraid that we are pretty much behind them.
That's where a firmware cleanup tool comes in. If space is a concern you can do it. If not you need not be bothered. It can be integrated into yast and whatnot if the interface is sane and there is user demand for the feature. Thanks Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org