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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Wed, Apr 22, 2026 at 11:16:48AM +0200, Roger Pau Monné wrote:
> 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.

Yeah, let's just use ENODEV on every platform in this case.

We already have ENODATA translated to ENOENT in libxl (for privcmd), so
let's not add a different translation here.

So patch looks fine to me as is:
Acked-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>

As for the error message, patch welcome ;-).

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech