Re: [PATCH] tools/xenpm: fix FreeBSD build

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Apr 22, 2026 at 09:15:56AM +0200, Jan Beulich wrote:
> On 21.04.2026 17:51, Roger Pau Monné wrote:
> > On Tue, Apr 21, 2026 at 05:35:57PM +0200, Jan Beulich wrote:
> >> On 21.04.2026 17:32, Roger Pau Monne wrote:
> >>> --- a/tools/misc/xenpm.c
> >>> +++ b/tools/misc/xenpm.c
> >>> @@ -1377,7 +1377,7 @@ static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *te
> >>>      {
> >>>      case 0:
> >>>          /* This CPU isn't online or can't query this MSR */
> >>> -        errno = ENODATA;
> >>> +        errno = ENODEV;
> >>>          return -1;
> >>
> >> "No such device", however, isn't quite what we want to convey here. If no
> >> better error code can be found that's available on FreeBSD and Linux, I'm
> >> inclined to suggest that we stick to ENODATA where available.
> > 
> > Seems like a lot of complexity, for very limited usefulness.
> 
> What's complex about
> 
> #ifndef ENODATA
> # define ENODATA ENODEV
> #endif
> 
> (perhaps with a brief comment)?

IMO it's best if we can avoid instances of ENODATA in the toolstack
code base, specially if it's individual ones like this that can be
fixed.  Otherwise new instances might appear elsewhere, and we don't
want to be adding this bodge everywhere if avoidable.

If we had a sizable usage of ENODATA in the code base I would indeed
recommend such define approach.

> >  The only
> > usage of errno is to be printed in the error message, and for the
> > purposes of this function ENODEV is already unique in the function, as
> > ENODATA was.
> 
> Right, but "No data available" is more precise than "No such device".
> 
> > FWIW, I think ENODEV is not that far fetched: the CPU being offline
> > or the MSR not being present seems like what you would convey by using
> > ENODEV.
> 
> Yes, there is a connection. Hence I'm not outright opposed, yet I think
> we can do better.
> 
> Formally Anthony is the maintainer of the file, so in a case like this
> one maybe he ought to have the final say?

I'm fine with letting Anthony resolve.

Thanks, Roger.