On Mar 31, 2023, John Harrison <john.c.harrison@xxxxxxxxx> 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>
