On 11/8/21 22:36, Miroslav Suchý wrote:
In the recent discussion about saving space (in the ELF thread) there poped up linux-firmware topic several time. Let's kick it off as separate thread.I have several question and I am unable to find the answer for them. 1. How do I find which firmware package I need? On my workstation I have: $ rpm-qa|grepfirmware |wc-l 27I seriously doubt I need all of them. I definitely do not need them on server, where I never add any new HW. But how do I know which one is in use and which not?
From my (fairly limited) knowledge, you'll have to look at `modinfo` for loaded modules or `MODULE_FIRMWARE` and `request_firmware.*` API usage within the kernel sources. I'm not aware if that documents all the firmware files in use, but hopefully someone from kernel or linux-firmware maintenance teams can chime in.
AFAIK, there is no information about the mapping of device ids -> fw files available. I.e., let's say, `iwlwifi` in 5.15.0 declares 47 unique firmware files and 77 supported PCI ids. But each of those PCI ids would require only a small subset of these 47 firmware binaries. Thus, the `iwl.*-firmware` packages can be split in a way it is done right now and installed/removed as necessary.
It should possible to collect the data from the kernel source manually, but imagine the effort to do that and to keep it up-to-date...
---I considered proposing to use rpm metadata for the very same purpose, something like
Supplements: device(pci:8086:a0f0) >= rev20
Supplements: device(usb:8087:0026)
or
Provides: firmware(pci:8086:a0f0)
Provides: firmware(usb:8087:0026)
but we'd really want to have that autogenerated, and there's no input
data readily available for that.
Also, you'd want to expose the hardware information from the rpm side as
well, which is a whole another problem. I believe we still can't get CPU
hwcaps exposed, and this would add lspci/lsusb information to the mix.
2. How the firmware packages actually work? Do I need them to be present every time? Or when module is loaded? Or something else? (sorry if this too naive question).
A module can load a firmware binary with the `request_firmware` API at any moment of it's lifetime. Usually, this happens when the module is initialized or discovers a new supported device, but I don't believe that is a strictly enforced rule.
The process itself is complicated enough (I recall it used to involve udev as an intermediary to access the filesystem), and may have a place for on-demand firmware package installation. But that's prone to breaks and won't function offline. Also, see above for required device id -> firmware files mapping.
3. The linux-firmare has 100MB. And cca 280 MB extracted. Is it about the time to split the package? Here are the biggest space eater of the space:18M /usr/lib/firmware/amdgpu 18M /usr/lib/firmware/qcom 28M /usr/lib/firmware/intel 31M /usr/lib/firmware/mrvl 47M /usr/lib/firmware/mellanox
You can slightly reduce the installation footprint if you have minimum/maximum supported kernel version. Some of the firmware binaries have an API version, and the kernel will use only currently supported API (I'll point to `iwlwifi` as an example again. It's what lead me to a rabbit hole of firmware loaders, after all). The rest are kept there only to support older kernels. But that doesn't apply to all the firmware files and drivers, and again, the compat database has to be collected and updated manually.
Miroslav _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Best regards, Aleksei Bavshin
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
