>> Rather than doing it only in Ubuntu, how would you feel about making
>> such a change upstream first?
>
> That's a daunting task :-)
Yeah it's a lot of front loaded work, but the maintenance payoff is very
big. It could mean that the moment that new firmware is uploaded it's
required that the new "YAML" WHENCE file has the fields filled out
properly and every time there is a cherry pick or rebase your work of
figuring out what architectures, what subsystem, whether firmware is
needed is done for you.
>
>
>>
>> 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 don't think it needs to be 100% correct on a commit that converts
WHENCE to YAML. Sure, try to but don't break your back doing it.
We can use some hints like Debian packaging do for firmware that is for
all architectures (ie keyword 'all'). I think initially unless it's
blatantly obvious most firmware should be marked that way.
If subsystems "aren't known" we can have a keyword 'unknown' initially,
and then collectively get it corrected.
Likewise for kernel version just pick the oldest supported LTS for now.
Then we can have a call to arms for firmware owners to come help correct
the metadata.
>
>>
>> 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.
Great!
>
>>
>> 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
Yes this sounds great. Basically if the subsystem firmware size is
getting unwieldy (<cough> nvidia) then split it up by vendors. If it's
relatively small just call it by subsystem.
> ...
>
>
>>
>> Thanks,
>
> Thanks for the feedback. It's much appreciated.
>
> ...Juerg
Sure.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
