Re: [RFC PATCH 12/25] xen: Replace sysctl/readconsole with autogenerated version

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Hello,

Le 26/11/2024 à 14:20, Jan Beulich a écrit :
>>> Signed-ness of plain char doesn't really matter as long as it's used only 
>>> for
>>> what really are characters (or strings thereof). And that looks the be 
>>> pretty
>>> much the case throughout the public headers.
>> Maybe. Still, as a general principle caller and callee ought to agree on 
>> size,
>> alignment and sign for every type. I'd rather not make exceptions for that
>> invariant unless truly well motivated. And in this case it's a case of
>> requiring trivial non-functional changes.
> In how far they're non-functional will need to be seen. You also need to keep
> consumers in mind: They may face sudden type disagreement that compilers may
> complain about. Yet "stable" for the public headers means not just the ABI
> itself being stable, but updated headers also being usable as drop-in
> replacements for older versions.

I don't think we currently enforce stability on all Xen headers
(especially not those control-domain related).
For instance

Commit 21e3ef57e0406b6b9a783f721f29df8f91a00f99
x86: Rename {domctl,sysctl}.cpu_policy.{cpuid,msr}_policy fields

actually modifies the name of some fields in a struct of sysctl.h, so I
suppose modifying the type of fields with more defined variants is
acceptable.

One thing remain is that if the user is not careful of this change and
char is silently replaced by uint8_t, could that break something by
possibly changing the signed-ness ?

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech