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
27
I 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Best regards,
Aleksei Bavshin