On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <[email protected]> wrote: > > 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.
I wrote some macros in my nova-core-experiments, had chipset_before/after/range I think Dave.
