Re: [PATCH] Make XEN_FW_EFI_MEM_INFO easier to use

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature