Re: [PATCH] Make XEN_FW_EFI_MEM_INFO easier to use

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.08.2022 20:15, Demi Marie Obenour wrote:
> On Fri, Aug 26, 2022 at 09:18:50AM +0200, Jan Beulich wrote:
>> On 25.08.2022 22:36, Demi Marie Obenour wrote:
>>> On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
>>>> On 24.08.2022 23:04, Demi Marie Obenour wrote:
>>>>> Fix both of these problems by unconditionally setting the memory region
>>>>> size
>>>>
>>>> If you were to report a larger ending address, why would you not also
>>>> report a smaller starting address?
>>>>
>>>> But before you go that route - I don't think we can change the API
>>>> now that it has been in use this way for many years. If a "give me
>>>> the full enclosing range" variant is wanted, it will need to be
>>>> fully separate.
>>>
>>> Does anyone use this API?
>>
>> The XenoLinux forward port of ours did, and upstream Linux still wrongly
>> doesn't. The two functions efi_mem_type() and efi_mem_attributes() still
>> wrongly fail there when running on Xen.
>>
>> But how does this matter? Even if we were unaware of any users of the API,
>> we can't know there are none.
>>
>> As an aside: Something's odd with your reply. When I opened the window to
>> write this reply, Marek and the list were put into To: (instead of Cc:)
>> and you were dropped altogether. I can only guess that this is what
>> Thunderbird made of the Mail-Followup-To: tag which your mail has.
> 
> Probably?  Mutt generated the header because I had (incorrectly)
> told it that I am subscribed to xen-devel.  Is it best to leave this
> header unset?

Probably, seeing that it results in misguidance of at least on commonly
used (I believe) frontend.

Jan