On 10/17/24 19:58, Andrew Cooper wrote:
> On 17/10/2024 6:02 pm, Daniel P. Smith wrote:
>> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
>> index 18281d80fa97..e8ba9390a51f 100644
>> --- a/xen/arch/x86/include/asm/bootinfo.h
>> +++ b/xen/arch/x86/include/asm/bootinfo.h
>> @@ -39,6 +39,9 @@ struct boot_module {
>> */
>> unsigned long headroom;
>> enum bootmod_type type;
>> +
>> + uint32_t flags;
>> +#define BOOTMOD_FLAG_X86_RELOCATED (1U << 0)
>
> There are two parts to this request. First, there's nothing X86
> specific about any of the flags added (in this series at least), and the
> FLAG infix doesn't feel as if it adds much.
>
> But, looking over the code, I get the feeling it would be better as simply:
>
> /*
> * Misc flags XXX docs
> */
> bool relocated:1;
> bool consumed:1;
>
> (Possibly with an enclosing struct { ... } flags; but I don't think
> that's necessary either.)
I see no reason why not a bitfield, and as you state, will make code
simpler (and possibly shorter) elsewhere.
> because flags is never operated on as a unit of multiple things, or
> passed around separately from a bm-> pointer. For misc independent
> flags like this, bitfields lead to far more legible code because you're
> not having to express everything as binary operators in the logic.
>
> I know this will be a moderately invasive change, but I suspect the
> improvement will speak for itself. (Assuming there isn't a need to keep
> it as a plain flags field later.)
Yah it will be a bit painful, but I would rather have cleaner and easier
to read code.
v/r,
dps