[PATCH] tools/xenpm: fix FreeBSD build

[PATCH] tools/xenpm: fix FreeBSD build

[Roger Pau Monne]

ENODATA is not defined on FreeBSD:

xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
 1380 |         errno = ENODATA;
      |                 ^
1 error generated.

Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 tools/misc/xenpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 87107bd6c617..ecb39c911d84 100644
--- 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;
 
     case 1:
-- 
2.53.0

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

[Andrew Cooper]

On 21/04/2026 4:32 pm, Roger Pau Monne wrote:
> ENODATA is not defined on FreeBSD:
>
> xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
>  1380 |         errno = ENODATA;
>       |                 ^
> 1 error generated.
>
> Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

[Jan Beulich]

On 21.04.2026 17:32, Roger Pau Monne wrote:
> ENODATA is not defined on FreeBSD:
> 
> xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
>  1380 |         errno = ENODATA;
>       |                 ^
> 1 error generated.
> 
> Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  tools/misc/xenpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> index 87107bd6c617..ecb39c911d84 100644
> --- 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.

Jan

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

[Roger Pau Monné]

On Tue, Apr 21, 2026 at 05:35:57PM +0200, Jan Beulich wrote:
> On 21.04.2026 17:32, Roger Pau Monne wrote:
> > ENODATA is not defined on FreeBSD:
> > 
> > xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
> >  1380 |         errno = ENODATA;
> >       |                 ^
> > 1 error generated.
> > 
> > Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  tools/misc/xenpm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> > index 87107bd6c617..ecb39c911d84 100644
> > --- 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.  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.

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.

Thanks, Roger.

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

[Teddy Astie]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Le 21/04/2026 à 17:36, Roger Pau Monne a écrit :
> ENODATA is not defined on FreeBSD:
> 
> xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
>   1380 |         errno = ENODATA;
>        |                 ^
> 1 error generated.
> 
> Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>   tools/misc/xenpm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> index 87107bd6c617..ecb39c911d84 100644
> --- 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;
>   
>       case 1:

I wasn't aware ENODATA wasn't available on some BSDs. Even though it's 
supposed to be a part of POSIX.

Regardless,
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

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

[Roger Pau Monné]

On Tue, Apr 21, 2026 at 05:58:02PM +0200, Teddy Astie wrote:
> Le 21/04/2026 à 17:36, Roger Pau Monne a écrit :
> > ENODATA is not defined on FreeBSD:
> > 
> > xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
> >   1380 |         errno = ENODATA;
> >        |                 ^
> > 1 error generated.
> > 
> > Fixes: edb657887a60 ("xenpm: Add get-core-temp subcommand")
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >   tools/misc/xenpm.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> > index 87107bd6c617..ecb39c911d84 100644
> > --- 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;
> >   
> >       case 1:
> 
> I wasn't aware ENODATA wasn't available on some BSDs. Even though it's 
> supposed to be a part of POSIX.

Not in the last version I think?

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/errno.h.html

Regards, Roger.

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

[Jan Beulich]

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)?

>  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?

Jan

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

[Roger Pau Monné]

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.

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

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

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@vates.tech>

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

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech