On Mar 31, 2023, John Harrison john.c.harrison@intel.com wrote:
I'm not sure that is really a valid use case that the driver code should be expected to support.
It's most certainly not. As I wrote, I'd be happy to keep on carrying the patch that adjusts the code to cope with our changes. I just thought the same issue could come up by, say, mistakenly applying a patch twice to add support for a new card, a circumstance in which one might not have the card readily available to try it out.
Not following this argument.
I was talking about downstream backporting, e.g. random users or small-distro maintainers attempting to backport support for certain cards without realizing it's already there.
Oh, no, the driver loads just fine even without those blobs, and that's much nicer of you than other drivers for hardware that doesn't really require blobs, but that insist on bailing out if the firmware can't be loaded. i915 hasn't been hostile like that.
That situation won't last...
:-(
I would consider that a bug that should never make it past either pre-merge CI or code review.
Agreed.
And if you really do need to remove the firmware files from the compiled binary completely, then replacing them with unique names would also work - '/*(DEBLOBBED_1)*/', '/*(DEBLOBBED_2)*/', etc.
That is not doable with our current deblob-check implementation, unfortunately. There are long-term plans to switch to a different approach, but we're not there yet. So I guess we'll have to use custom code to disable blob loading on i915, while that's still possible, when the stricter table checking hits.
Also, is this string unification thing a part of the current gcc toolchain?
Yeah, compilers and linkers have been unifying (read-only) string literals for a very long time.
That's what I would have assumed. Which is why I was confused that you were saying 'if you use a toolchain that does this'. It seemed that you were implying that most don't and this was a special situation.
Oh, no, sorry, it's just that compilers can't be dependent on for string literal unification. It's an optimization, not a language-imposed requirement.
Thanks for considering the patch, and for the heads up about darker days coming for users of Intel video cards! :-(