[Intel-gfx] [PATCH] [i915] avoid infinite retries in GuC/HuC loading

[Alexandre Oliva]

On Mar 31, 2023, John Harrison <john.c.harrison at 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! :-(


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>