< Changes
(mark change as ready) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 14: | Line 14: | ||
== Current status == | == Current status == | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 21: | Line 21: | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
[[Category:ChangePageIncomplete]] | |||
* Targeted release: [[Releases/37 | Fedora Linux 37]] | * Targeted release: [[Releases/37 | Fedora Linux 37]] | ||
| Line 30: | Line 31: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7VDQXGCI2DA4H3A5UGD2UPO6ODWUHUPD/ devel thread] | |||
* FESCo issue: <will be assigned by the Wrangler> | * FESCo issue: <will be assigned by the Wrangler> | ||
* Tracker bug: <will be assigned by the Wrangler> | * Tracker bug: <will be assigned by the Wrangler> | ||
| Line 35: | Line 37: | ||
== Detailed Description == | == Detailed Description == | ||
The `linux-firmware` RPM is very large (175M src.rpm, 287M *.noarch.rpm per 20211027-126) that bundles most of the system firmware loaded by the kernel, regardless of whether it’s actually needed. Some additional firmwares are already split up into individual subpackages. This change would extend that, splitting out most | The `linux-firmware` RPM is very large (175M src.rpm, 287M *.noarch.rpm per 20211027-126) that bundles most of the system firmware loaded by the kernel, regardless of whether it’s actually needed. Some additional firmwares are already split up into individual subpackages. This change would extend that, splitting out most firmware into appropriate subpackages. The Change would also make the subpackages `Supplements` the appropriate `modalias(...)` for the hardware they support and `Provides` `firmware(kmodname/firmwarefile.bin)` | ||
Candidates for splitting out: | Candidates for splitting out: | ||
| Line 48: | Line 50: | ||
A DNF plugin will be written to make use of the `Supplements` metadata to automatically install the appropriate firmware packages based on the hardware present on the system (see openSUSE's `libzypp`: https://github.com/openSUSE/libzypp/blob/a34d857dbe3b16d4a7e0219cd213cc5a87966538/zypp/target/modalias/Modalias.cc and https://github.com/openSUSE/libzypp/blob/7f345ea4892fd02345e8de47c2a08ab5b174650b/doc/autoinclude/Modalias.doc) | A DNF plugin will be written to make use of the `Supplements` metadata to automatically install the appropriate firmware packages based on the hardware present on the system (see openSUSE's `libzypp`: https://github.com/openSUSE/libzypp/blob/a34d857dbe3b16d4a7e0219cd213cc5a87966538/zypp/target/modalias/Modalias.cc and https://github.com/openSUSE/libzypp/blob/7f345ea4892fd02345e8de47c2a08ab5b174650b/doc/autoinclude/Modalias.doc) | ||
== Feedback == | == Feedback == | ||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
Latest revision as of 17:02, 23 November 2022
Linux Firmware Minimization
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
Split linux-firmware into more subpackages, and add the ability to automatically install firmware based on the hardware present
Owner
- Name: Michel Alexandre Salim, Davide Cavalca
- Email: michel@fb.com, dcavalca@fb.com
Current status
- Targeted release: Fedora Linux 37
- Last updated: 2022-11-23
- devel thread
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
The linux-firmware RPM is very large (175M src.rpm, 287M *.noarch.rpm per 20211027-126) that bundles most of the system firmware loaded by the kernel, regardless of whether it’s actually needed. Some additional firmwares are already split up into individual subpackages. This change would extend that, splitting out most firmware into appropriate subpackages. The Change would also make the subpackages Supplements the appropriate modalias(...) for the hardware they support and Provides firmware(kmodname/firmwarefile.bin)
Candidates for splitting out:
- CPU firmwares
- GPU firmwares
- Non-Intel wifi firmwares
- Bluetooth firmwares
Conversely some firmware could probably be grouped together, e.g. have iwlwifi-firmware that pulls in iwl*-firmware (corresponding to openSUSE's kernel-firmware-iwlwifi).
We will also introduce linux-firmware-all that will pull in all subpackages; this will make it easier to manage the firmware packages in different Fedora variants.
A DNF plugin will be written to make use of the Supplements metadata to automatically install the appropriate firmware packages based on the hardware present on the system (see openSUSE's libzypp: https://github.com/openSUSE/libzypp/blob/a34d857dbe3b16d4a7e0219cd213cc5a87966538/zypp/target/modalias/Modalias.cc and https://github.com/openSUSE/libzypp/blob/7f345ea4892fd02345e8de47c2a08ab5b174650b/doc/autoinclude/Modalias.doc)
Feedback
Benefit to Fedora
This would save a lot of disk space on Fedora installations, and make it easier to test individual firmware updates by replacing a single subpackage. It will also bring us into alignment with openSUSE (see their kernel-firmware.spec).
Scope
- Proposal owners:
- Create test COPR with proposed changes
- Add some additional firmware subpackages
- Add the required metadata (supplements, provides)
- Write DNF plugin to make use of supplements
- Write libdnf plugin for PackageKit (and in the future, microdnf)
- refactor comps for F37
- Other developers:
- Validate that installation works with iwl*-firmware replaced by iwlwifi-firmware
- Test the DNF plugin
- If it works well, preinstall the DNF plugin and stop installing iwlwifi-firmware or any of the iwl*-firmware
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
Upgrade/compatibility impact
No compatibility impact.
How To Test
- Enable the test COPR
- Verify that after upgrading, no firmware subpackages are removed
- Install the DNF plugin
- Verify that the DNF plugin works:
dnf mark removea firmware package that is needed, then verify thatdnf autoremovedoes not remove it dnf mark removeall firmware packages, and verify thatdnf autoremoveonly remove the unneeded packages
User Experience
More disk space available, no functional changes.
Dependencies
No dependency, linux-firmware is not required by any package
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?)
If the plugin is not ready in time, the other changes would preserve the status quo. So we can postpone shipping the DNF plugin to F38.
- Contingency deadline:
Decide on whether to postpone the DNF plugin by beta freeze
- Blocks release? No
Documentation
Documentation will be added in this HackMD