On Thu Oct 15, 2026 at 9:49 PM JST, Eliot Courtney wrote: > On Wed Oct 7, 2026 at 3:30 PM JST, Alexandre Courbot wrote: >> On Mon Sep 28, 2026 at 5:42 PM JST, Eliot Courtney wrote: >>> Similar to the typed encoding layer, add some decoding type machinery. >>> Add a simple macro `nvkv_decode!` which implements `Schema` for a struct >>> by composing visit calls to each member. Add some common `Schema` kinds, >>> such as `Array` which collects an array value into a fixed maximum size >>> array, and `Required` which fails a decode if the value is not sent. >>> >>> Signed-off-by: Eliot Courtney <[email protected]> >>> --- >>> drivers/gpu/nova-core/gsp/nvkv.rs | 11 +- >>> drivers/gpu/nova-core/gsp/nvkv/decode.rs | 622 >>> ++++++++++++++++++++++++++++++- >>> 2 files changed, 628 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/gpu/nova-core/gsp/nvkv.rs >>> b/drivers/gpu/nova-core/gsp/nvkv.rs >>> index 7ac3a459a98b..5791df07a7fa 100644 >>> --- a/drivers/gpu/nova-core/gsp/nvkv.rs >>> +++ b/drivers/gpu/nova-core/gsp/nvkv.rs >>> @@ -9,7 +9,7 @@ >>> //! function calls will map to some struct - for example, >>> f(GPU_NAME_STRING_KEY, 0, b"some gpu") >>> //! naturally maps to storing a &str with the GPU name. >>> >>> -#![expect(unused_imports)] >>> +#![cfg_attr(not(CONFIG_KUNIT), expect(unused_imports))] >>> #![cfg_attr(not(CONFIG_KUNIT), expect(unused_macros))] >>> >>> use core::{ >>> @@ -23,7 +23,8 @@ >>> use kernel::{ >>> alloc::{ >>> allocator::KVmalloc, >>> - Allocator, // >>> + Allocator, >>> + ArrayVec, // >>> }, >>> bitfield, >>> num::Bounded, >>> @@ -148,6 +149,12 @@ fn default() -> Self { >>> } >>> } >>> >>> +/// A schema field for an array value under the NVKV key `KEY_ID`. >>> +#[repr(transparent)] >>> +pub(crate) struct Array<T: Default + Copy, const N: usize, const KEY_ID: >>> KeyId> { >>> + vec: ArrayVec<T, N>, >>> +} >> >> I still don't see why this needs to be declared in this module when no >> encoder element ever uses it, and the module reexports everything from >> `decode` anyway. Can this be moved next to the other schema kinds? > > This will be used soon [1] for encoding. The convention I have been > using is if a type is used for both encoding and decoding, I put it in > nvkv.rs (since it doesn't fit obviously in either - the > encoding/decoding related impls can go in there though). If we put > IndexedKey in nvkv.rs as pub crate since we'll use it soon, it's > consistent to keep Array here as well. WDYT?
Sure, if encoding is to use it then let's put it in its eventual destination from the start.
