enhancing module info to allow grouping of firmwares

[Jani Nikula]

On Thu, 16 Mar 2023, Dave Airlie <airlied at gmail.com> wrote:
> Hey moduly/firmware people,
>
> We are facing a problem in the future of NVIDIA providing giant
> firmwares for their devices that are version locked with unstable
> APIs. Even if they weren't version locked we'd likely have to support
> multiple major versions over time.
>
> Now this becomes a problem because when you generate multiple
> initramfs and stick them into /boot over time the number of firmwares
> MODULE_FIRMWARE will match will increase and dracut will shove them
> all into the initramfs.
>
> I think one way to mitigate that would be to provide some sort of
> grouping of module firmwares that are acceptable, and having dracut
> only pick one from the list to provide in the initramfs (hopefully the
> latest one). That way the driver can provide a list of MODULE_FIRMWARE
> lines and userspace knows they are a group.
>
> I've just little idea how we could expose this via current module
> info, happy to try and come up with an enhanced scheme maybe with a
> fallback to just include all of them but was just wanting to get some
> feedback on whether this was something that anyone has ever considered
> before now.

A related problem is platform (or hardware generation) specific firmware
blobs that are listed with MODULE_FIRMWARE, and thus added to the
generic initramfs. What if there was a way to limit them to the specific
platform you have? Sure, a generic initramfs would need them all, but
the vast majority of installs would only need the firmware for the
hardware on the system.

See 'ls /lib/firmware/i915/ | grep -o "^..." | sort | uniq'

I don't want to distract you from your original goal, but if you're
adding some grouping mechanism, maybe try to keep an avenue open for
grouping and filtering like that too?


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center