Re: [PATCH 1/3] util: Introduce virAcpi module
On Thu, Apr 06, 2023 at 12:02:01PM +0200, Michal Prívozník wrote:
On 4/6/23 11:20, Andrea Bolognani wrote:
> On Thu, Apr 06, 2023 at 10:20:46AM +0200, Michal Prívozník wrote:
>>>> +typedef enum {
>>>> + VIR_IORT_NODE_TYPE_UNKNOWN = -1,
>>>
>>> Do we need this? virIORTNodeHeader.type is defined as unsigned.
>
> You didn't answer this one :)
That's because I removed it in v2 ;-)
I hadn't realized you had posted that already O:-)
> What about renaming @reference_id to @mappings_offset though,
to
> match the corresponding fields for nodes in virIORTHeader?
I can do that, but then again - it's named 'Reference to ID Array' in
the spec. And since I renamed SMMU_V1_2 to match whatever was in the
spec I figured staying close to the standard is key. Or how do we decide
when to stay true to the standard an when not?
If anything, it should be named reference_to_id_array. But I believe
that anybody who will extend this implementation will do the same as I
did - open the code and the spec next to each other and try to find a
match between tables in spec and structs in our code. At that point,
whether this field is named 'reference_id', 'mappings_offset' or
'reference_to_id_array' doesn't really matter.
Yeah, it's unfortunate that the standard itself didn't adopt a
reasonable and consistent naming convention. Let's stick to what
they've chosen for now.
--
Andrea Bolognani / Red Hat / Virtualization