[PATCH] Introduce Tyr
Daniel Almeida
daniel.almeida at collabora.com
Mon Jun 30 15:22:52 UTC 2025
Hi Miguel,
>> Hmm, I must say I did not know that this was a thing.
>>
>> Why is it better than [#allow] during the development phase?
>
> I have some notes at:
>
> https://docs.kernel.org/rust/coding-guidelines.html#lints
>
> Generally speaking, we default to `expect` unless there is a reason
> not to (I list some possible reasons in the link), because `expect`
> forces us to clean it when unneeded.
>
> Not sure what you mean by "development phase" -- even if Tyr is under
> development, it should still try to conform to the usual guidelines.
> Of course, if a particular `expect` would be a pain, then please feel
> free to use `allow`. But is that case here? i.e. you will want to
> remove the `allow` anyway when you add the new code, no?
>
> Thanks!
>
> Cheers,
> Miguel
When I said "in development"I was referring to "dead_code" specifically, as we
will invariably have some of that until the other parts of the driver land.
Just as an example: IMHO it doesn't make much sense to only introduce the
register definitions used for this patch if we know for sure that:
a) the currently unused definitions will be used once the subsequent parts land,
b) they will not change, as they're derived from the hardware itself
It makes more sense to just sit down and transcribe this part of the spec at
once. It lowers the chance of copy and paste errors too.
As I said, I was unfamiliar with "expect". Can it be made to work on a module
level? Anyway, I can try to make this work with "expect" instead of “allow", no
worries :)
— Daniel
More information about the dri-devel
mailing list