On Mon, 2 Jun 2025 14:49:36 -0500
Mario Limonciello <superm1@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
