Splitting up linux-firmware

[Juerg Haefliger]

On Mon, 2 Jun 2025 14:49:36 -0500
Mario Limonciello <superm1 at kernel.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20250604/6a5e6860/attachment.sig>