On 23/12/2024 11:06, Julien Grall wrote:
> 
> 
> Hi Michal,
> 
> On 23/12/2024 07:58, Michal Orzel wrote:
>>
>>
>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>
>>>
>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>> but forgot to update the 'struct kernel_info' initialiser, while
>>> it doesn't lead to failures because the field is not currently
>>> used while managing kernel_info structures, it's good to have it
>>> for completeness.
>> The last part "good to have it" does not sound like we need a Fixes tag.
> 
> Reading the discussion, it sounds like ".type" is not always set and
> this is not properly documented. This means that in the future we may
> write a patch that requires to use ".type" and needs backported.
> 
> But this would depend on this patch which was not tagged appropriately.
> Therefore, I would argue it needs a fixes tag (even though this is a
> latent bug) or at least a backport request.
Ok, sounds good. But first, let's settle on what we actually want to do here, 
if at all.
I would be ok with just documenting that .type field is for now only used with 
bootinfo
related structures (after all, today it's used only in one bootfdt function). 
Setting
explicitly a type for structures not requiring it, does not seem beneficial for 
me.

~Michal


Reply via email to