Hardware registry schema proposal

Hardware registry schema proposal

[Hambardzumyan, Minas]

Hello,

I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.

Please review and share your comments on a proposed schema here:
https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml

along with an example yaml file here:
https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml

In summary, the schema defines following main sections with cross references:

* silicon_vendors: A collection of silicon vendors (processors, SOCs)
* platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
* processors: A collection of processors used on tested platforms
* system_modules: A collection of system modules (SoMs, SiPs) 
* platforms: A collection of platforms tested in labs

Regards,
Minas.

Re: Hardware registry schema proposal

[Ben Copeland]

Hello Minas,

On Wed, 8 Oct 2025 at 22:20, Hambardzumyan, Minas <minas@ti.com> wrote:
>
> Hello,
>
> I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.
>
> Please review and share your comments on a proposed schema here:
> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml
>
> along with an example yaml file here:
> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml
>
> In summary, the schema defines following main sections with cross references:
>
> * silicon_vendors: A collection of silicon vendors (processors, SOCs)
> * platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
> * processors: A collection of processors used on tested platforms
> * system_modules: A collection of system modules (SoMs, SiPs)
> * platforms: A collection of platforms tested in labs

I think it would also make sense to add revisions in.

If you look at LAVA, you can see the messiness of not having revisions
https://gitlab.com/lava/lava/-/tree/master/etc/dispatcher-config/device-types?ref_type=heads

Ben

>
> Regards,
> Minas.
>

Re: Hardware registry schema proposal

[Jan Lübbe]

On Wed, 2025-10-08 at 21:20 +0000, Hambardzumyan, Minas wrote:
> Hello,
> 
> I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.
> 
> Please review and share your comments on a proposed schema here:
> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml
> 
> along with an example yaml file here:
> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml
> 
> In summary, the schema defines following main sections with cross references:
> 
> * silicon_vendors: A collection of silicon vendors (processors, SOCs)
> * platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
> * processors: A collection of processors used on tested platforms
> * system_modules: A collection of system modules (SoMs, SiPs) 
> * platforms: A collection of platforms tested in labs

You have an `id` property which seems to always match the mapping entry name.
Can they be different? If not, it seems redundant and the property could be
removed.

Regards,
Jan

Re: Hardware registry schema proposal

[Minas Hambardzumyan]

On 10/9/25 04:58, Jan Lübbe wrote:
> On Wed, 2025-10-08 at 21:20 +0000, Hambardzumyan, Minas wrote:
>> Hello,
>>
>> I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.
>>
>> Please review and share your comments on a proposed schema here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml
>>
>> along with an example yaml file here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml
>>
>> In summary, the schema defines following main sections with cross references:
>>
>> * silicon_vendors: A collection of silicon vendors (processors, SOCs)
>> * platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
>> * processors: A collection of processors used on tested platforms
>> * system_modules: A collection of system modules (SoMs, SiPs)
>> * platforms: A collection of platforms tested in labs
> 
> You have an `id` property which seems to always match the mapping entry name.
> Can they be different? If not, it seems redundant and the property could be
> removed.

Yes I have set id and yaml key name the same. Intention was include the 
hardware name in each yaml section, such that functions taking it as an 
argument would have access to the name without having to pass an extra 
parameter. I agree this does create a possibility for the two being 
different by mistake.

I think keeping the id would make it easier to use, but I have no 
problem removing it if there is a strong opinion to remove it.

> 
> Regards,
> Jan

Re: Hardware registry schema proposal

[Minas Hambardzumyan]

Hello Ben,

On 10/9/25 03:19, Ben Copeland wrote:
> Hello Minas,
> 
> On Wed, 8 Oct 2025 at 22:20, Hambardzumyan, Minas <minas@ti.com> wrote:
>>
>> Hello,
>>
>> I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.
>>
>> Please review and share your comments on a proposed schema here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml
>>
>> along with an example yaml file here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml
>>
>> In summary, the schema defines following main sections with cross references:
>>
>> * silicon_vendors: A collection of silicon vendors (processors, SOCs)
>> * platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
>> * processors: A collection of processors used on tested platforms
>> * system_modules: A collection of system modules (SoMs, SiPs)
>> * platforms: A collection of platforms tested in labs
> 
> I think it would also make sense to add revisions in.
> 
> If you look at LAVA, you can see the messiness of not having revisions
> https://gitlab.com/lava/lava/-/tree/master/etc/dispatcher-config/device-types?ref_type=heads

I added version to the schema and example -- please review (committed at 
the same URLs above).

Minas

> 
> Ben
> 
>>
>> Regards,
>> Minas.
>>