On 11/18/25 11:45 AM, Joel Fernandes wrote:
On 11/18/2025 8:04 AM, Alexandre Courbot wrote:
On Tue Nov 18, 2025 at 8:10 AM JST, Joel Fernandes wrote:
On Fri, Nov 14, 2025 at 05:30:42PM -0600, Timur Tabi wrote:
...
On principle, I tend to agree. In practice, we will probably never have
more than these two variants, so we need to balance the benefit of a
trait against the overhead of defining it in the first place (there are
quite a few methods in there).
I don't know if we'll never have more than one more variant really, its hard to
take a call on that. If a third variant comes into being, then the match arms
increase more.
I can help here: remember that the firmware team is moving rapidly toward
simplifying the bootloading--a lot--from the kernel driver point of view.
Not-so-distant future GSP+bootloader firmware will require little more than
request_firmware() to load files into kernel memory, and then write to a
register to say "make it so", and then just wait for GSP to report that
it is ready.
So we will be out of this business, and there is no need to invest in
allowing for more variants.
Trait objects come with their own complications, i.e. you need to store
them on the heap if you need more than a short-lived reference - but in
our case the short-lived reference should be what we need anyway.
Yeah, true. AFAICS though, and as you mentioned, in Timur's case it looks like
that is not an issue and we do not need an allocation.
So, with the rough, and probably accurate assumption that this is all
the version we need to support, I'd suggest comparing line counts between
the competing ways of coding it up. Maybe that could help as a tiebreaker,
if not everyone agrees on which is more readable (I'm trying to avoid
weighing in on that point--you're welcome, haha).
thanks,
--
John Hubbard
