On Wed Nov 19, 2025 at 10:46 AM JST, John Hubbard wrote:
> On 11/6/25 2:24 PM, John Hubbard wrote:
>> On 11/6/25 6:44 AM, Timur Tabi wrote:
>>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>>> let hal = match chipset {
>>>> - GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 |
>>>> AD104 | AD106 | AD107
>>>> => {
>>>> + GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 |
>>>> AD104 | AD106 | AD107
>>>> + | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
>>>> KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn
>>>> FalconHal<E>>
>>>> }
>>>
>>> Maybe combine patches 2 and 3? Also, maybe this should be a range check,
>>> instead of listing
>>> every since version? It seems like everything past GA100 uses the GA102
>>> HAL.
>>>
>>
>> Sure, I can combine the patches.
>>
>> I'm not sure why I've been wary of using ranges for these arch's.
>> I'll try it out.
>
> Now I know. :) Unlike C, Rust does *not* like it when we try to
> treat enums as integers. Casting or other (messier) approaches are
> required, and in no case is the end result a more readable on-screen
> experience. At least not so far.
>
> It is possible to mix in Architecture (Turing, Ampere, etc) checks,
> but I'm not sure that is worth the additional clutter.
>
> Maybe let's just do the long lists of chipsets for now...?
Yeah, I've hit this issue as well. The compiler might remove that
limitation in the future, or maybe we can craft a `chipset_range!()`
macro that hides the messy casting, but this exhaustive listing also has
the benefit of forcing us to consider every critical site whenever we
support a new chipset so I'm actually not too bothered by it.
