[PATCH 1/3] util: Introduce virAcpi module

[Andrea Bolognani]

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