On Mon, 2 Jun 2025 14:49:36 -0500 Mario Limonciello <[email protected]> wrote:
> On 6/2/2025 11:04 AM, Juerg Haefliger wrote: > > Hi, > > > > linux-firmware is ever growing and I'd like to entertain the thought of > > splitting it up. Not as fine grained as Debian but only split out the bigger > > GPU blobs (for now): > > > > - linux-firmware (provides the bulk of the blobs) > > - linux-<vendor>-graphics (similar to Debian, provides vendor specific > > graphics related firmwares) > > > > This obviously can't break users so I'm trying to understand which pieces > > need to be updated for seamless release upgrades and new installations. I > > think this means that we need to detect what's in the system and install the > > relevant linux-<vendor>-graphics package(s). Is this > > ubuntu-release-upgrader? > > subiquity? ubuntu-drivers? All of them? Anything else? > > > > Image generation and seeds would probably be affected by this as well. > > > > Does anyone see any (other) issues with this? > > > > Thanks > > ...Juerg > > > > > > Rather than doing it only in Ubuntu, how would you feel about making > such a change upstream first? That's a daunting task :-) > > My thought is that WHENCE doesn't have enough detail. > * We don't know what host architectures firmware is for. > * We don't know what kernel version is a minimum requirement for a firmware. > * We don't know what kernel driver a given firmware goes with (to even > decide if it should be packaged!) > * We don't know what subsystem a given firmware goes with. Yes to all of them. But compiling that information and maintaining it is quite an effort. In the past I had this naive pipe dream of using modinfo data but as you're likely aware it provides insufficient and incomplete information. I did try to add some MODULE_FIRMWARE globs to drivers that construct the firmware names at runtime based on HW info but some subsystem maintainers didn't like it whereas it's common practice in other places. IIRC. > > I feel like if we switched WHENCE to a (more) machine readable format > like YAML we can also encode new mandatory fields all of this information. Sounds good to me. I'll play around with it some. > > By doing it this way there will be less delta for Ubuntu to maintain, > and we can even end up with firmware packages that are architecture > specific. > > You can turn linux-firmware into a metapackage that depends upon all of > the subpackages. Yes. That is part of the plan but I realize it's not what I wrote initially. > > IMO picking a new package name for "graphics" firmware is wrong though. > There are plenty of firmwares in the drm subsystem that enable other > kinds of accelerators and have their own firmware. > > So I'm personally akin to making package names match subsystems. > > IE: > > linux-firmware-drm > linux-firmware-sound > linux-firmware-platform I'm not (yet) very attached to any particular grouping and/or naming. As long as people have the ability to uninstall packages with big blobs that they don't need. So maybe linux-firmware-drm is another metapackage that depends on: linux-firmware-drm-amd linux-firmware-drm-intel ... > > Thanks, Thanks for the feedback. It's much appreciated. ...Juerg
pgpAtYvwRCwtz.pgp
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
