| Message ID | 1461939680-32574-2-git-send-email-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: > According to the POSIX standard for error codes [0], ENODATA is both > obsolescent (so it may be removed in the future) and optional. It being optional still doesn't preclude us using it. > Replace it's > usage with ENOENT, which seems like the closest match. Both FreeBSD and > OpenBSD don't have this error code in the native errno.h headers. There's no rule saying that Xen's errno set must match any other OS'es. That's one of the reasons why we (finally) separated ours. > --- a/xen/include/public/errno.h > +++ b/xen/include/public/errno.h > @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG, 36) /* File name too long */ > XEN_ERRNO(ENOLCK, 37) /* No record locks available */ > XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ > XEN_ERRNO(ENOSYS, 38) /* Function not implemented */ > -XEN_ERRNO(ENODATA, 61) /* No data available */ > XEN_ERRNO(ETIME, 62) /* Timer expired */ > XEN_ERRNO(EBADMSG, 74) /* Not a data message */ > XEN_ERRNO(EOVERFLOW, 75) /* Value too large for defined data type */ And in absolutely no case can you unconditionally remove _anything_ from other than the tools-only parts of the public interface. Jan
On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: > >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: > > According to the POSIX standard for error codes [0], ENODATA is both > > obsolescent (so it may be removed in the future) and optional. > > It being optional still doesn't preclude us using it. > > > Replace it's > > usage with ENOENT, which seems like the closest match. Both FreeBSD and > > OpenBSD don't have this error code in the native errno.h headers. > > There's no rule saying that Xen's errno set must match any other OS'es. > That's one of the reasons why we (finally) separated ours. I understand that, but doing this means that then on the toolstack side we need to start doing ifdefery in order to match values that are not present in the native OS. For example a check was added to libxl against XENVER_build_id returning ENODATA, this means that then on libxl I would have to add a: #ifdef __FreeBSD__ #define ENODATA ENOENT #endif I think this adds more complexity, when we could solve it by only using error codes that are part of the POSIX standard, and that are present on all UNIX systems. > > --- a/xen/include/public/errno.h > > +++ b/xen/include/public/errno.h > > @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG, 36) /* File name too long */ > > XEN_ERRNO(ENOLCK, 37) /* No record locks available */ > > XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ > > XEN_ERRNO(ENOSYS, 38) /* Function not implemented */ > > -XEN_ERRNO(ENODATA, 61) /* No data available */ > > XEN_ERRNO(ETIME, 62) /* Timer expired */ > > XEN_ERRNO(EBADMSG, 74) /* Not a data message */ > > XEN_ERRNO(EOVERFLOW, 75) /* Value too large for defined data type */ > > And in absolutely no case can you unconditionally remove _anything_ > from other than the tools-only parts of the public interface. Right, the problem with leaving it there is that I'm quite certain it's going to be used again as a return value from a hypercall. Roger.
>>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: >> > According to the POSIX standard for error codes [0], ENODATA is both >> > obsolescent (so it may be removed in the future) and optional. >> >> It being optional still doesn't preclude us using it. >> >> > Replace it's >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and >> > OpenBSD don't have this error code in the native errno.h headers. >> >> There's no rule saying that Xen's errno set must match any other OS'es. >> That's one of the reasons why we (finally) separated ours. > > I understand that, but doing this means that then on the toolstack side we > need to start doing ifdefery in order to match values that are not present > in the native OS. For example a check was added to libxl against > XENVER_build_id returning ENODATA, this means that then on libxl I would > have to add a: > > #ifdef __FreeBSD__ > #define ENODATA ENOENT > #endif You ought to be using XEN_NODATA there anyway. Jan
On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote: > >>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: > > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: > >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: > >> > According to the POSIX standard for error codes [0], ENODATA is both > >> > obsolescent (so it may be removed in the future) and optional. > >> > >> It being optional still doesn't preclude us using it. > >> > >> > Replace it's > >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and > >> > OpenBSD don't have this error code in the native errno.h headers. > >> > >> There's no rule saying that Xen's errno set must match any other OS'es. > >> That's one of the reasons why we (finally) separated ours. > > > > I understand that, but doing this means that then on the toolstack side we > > need to start doing ifdefery in order to match values that are not present > > in the native OS. For example a check was added to libxl against > > XENVER_build_id returning ENODATA, this means that then on libxl I would > > have to add a: > > > > #ifdef __FreeBSD__ > > #define ENODATA ENOENT > > #endif > > You ought to be using XEN_NODATA there anyway. No, the privcmd driver is the one that performs the translation from Xen error codes into the OS error code space, so the tools just see error codes in the OS space. No tools at all use XEN_* error codes directly. This is because privcmd does the translation, and because it would be impossible to differentiate if the errno returned by the ioctl belongs to Xen space or to the OS space. Roger.
>>> On 29.04.16 at 18:34, <roger.pau@citrix.com> wrote: > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote: >> >>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: >> >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: >> >> > According to the POSIX standard for error codes [0], ENODATA is both >> >> > obsolescent (so it may be removed in the future) and optional. >> >> >> >> It being optional still doesn't preclude us using it. >> >> >> >> > Replace it's >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and >> >> > OpenBSD don't have this error code in the native errno.h headers. >> >> >> >> There's no rule saying that Xen's errno set must match any other OS'es. >> >> That's one of the reasons why we (finally) separated ours. >> > >> > I understand that, but doing this means that then on the toolstack side we >> > need to start doing ifdefery in order to match values that are not present >> > in the native OS. For example a check was added to libxl against >> > XENVER_build_id returning ENODATA, this means that then on libxl I would >> > have to add a: >> > >> > #ifdef __FreeBSD__ >> > #define ENODATA ENOENT >> > #endif >> >> You ought to be using XEN_NODATA there anyway. > > No, the privcmd driver is the one that performs the translation from Xen > error codes into the OS error code space, so the tools just see error codes > in the OS space. No tools at all use XEN_* error codes directly. That's the supposed behavior for return values, but not for structure contents. The structures are Xen-specific, so them holding Xen-specific values is known to the callers, and they should (be made) cope. > This is because privcmd does the translation, and because it would be > impossible to differentiate if the errno returned by the ioctl belongs to > Xen space or to the OS space. Exactly - I agree for the return values. Jan
On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote: > >>> On 29.04.16 at 18:34, <roger.pau@citrix.com> wrote: > > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote: > >> >>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: > >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: > >> >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: > >> >> > According to the POSIX standard for error codes [0], ENODATA is both > >> >> > obsolescent (so it may be removed in the future) and optional. > >> >> > >> >> It being optional still doesn't preclude us using it. > >> >> > >> >> > Replace it's > >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and > >> >> > OpenBSD don't have this error code in the native errno.h headers. > >> >> > >> >> There's no rule saying that Xen's errno set must match any other OS'es. > >> >> That's one of the reasons why we (finally) separated ours. > >> > > >> > I understand that, but doing this means that then on the toolstack side we > >> > need to start doing ifdefery in order to match values that are not present > >> > in the native OS. For example a check was added to libxl against > >> > XENVER_build_id returning ENODATA, this means that then on libxl I would > >> > have to add a: > >> > > >> > #ifdef __FreeBSD__ > >> > #define ENODATA ENOENT > >> > #endif > >> > >> You ought to be using XEN_NODATA there anyway. > > > > No, the privcmd driver is the one that performs the translation from Xen > > error codes into the OS error code space, so the tools just see error codes > > in the OS space. No tools at all use XEN_* error codes directly. > > That's the supposed behavior for return values, but not for > structure contents. The structures are Xen-specific, so them > holding Xen-specific values is known to the callers, and they > should (be made) cope. And the usage of ENODATA I'm trying to fix here is from the direct return of an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I just think it would be better to simply replace the usage of ENODATA with something else, so I could avoid adding more ifdefery to the tools. Would you be fine with me just adjusting xen_build_id (in xen/common/version.c) to return ENOENT instead of ENODATA? Roger.
>>> On 29.04.16 at 18:52, <roger.pau@citrix.com> wrote: > On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote: >> >>> On 29.04.16 at 18:34, <roger.pau@citrix.com> wrote: >> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote: >> >> >>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: >> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: >> >> >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: >> >> >> > According to the POSIX standard for error codes [0], ENODATA is both >> >> >> > obsolescent (so it may be removed in the future) and optional. >> >> >> >> >> >> It being optional still doesn't preclude us using it. >> >> >> >> >> >> > Replace it's >> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and >> >> >> > OpenBSD don't have this error code in the native errno.h headers. >> >> >> >> >> >> There's no rule saying that Xen's errno set must match any other OS'es. >> >> >> That's one of the reasons why we (finally) separated ours. >> >> > >> >> > I understand that, but doing this means that then on the toolstack side we > >> >> > need to start doing ifdefery in order to match values that are not present > >> >> > in the native OS. For example a check was added to libxl against >> >> > XENVER_build_id returning ENODATA, this means that then on libxl I would >> >> > have to add a: >> >> > >> >> > #ifdef __FreeBSD__ >> >> > #define ENODATA ENOENT >> >> > #endif >> >> >> >> You ought to be using XEN_NODATA there anyway. >> > >> > No, the privcmd driver is the one that performs the translation from Xen >> > error codes into the OS error code space, so the tools just see error codes > >> > in the OS space. No tools at all use XEN_* error codes directly. >> >> That's the supposed behavior for return values, but not for >> structure contents. The structures are Xen-specific, so them >> holding Xen-specific values is known to the callers, and they >> should (be made) cope. > > And the usage of ENODATA I'm trying to fix here is from the direct return of > > an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I > just think it would be better to simply replace the usage of ENODATA with > something else, so I could avoid adding more ifdefery to the tools. > > Would you be fine with me just adjusting xen_build_id (in > xen/common/version.c) to return ENOENT instead of ENODATA? Well, I wouldn't be particularly happy, but I'd also not be as heavily opposed as to removing that error code altogether. In general (and I probably should have said this in the first reply, despite there having been the other more important reason to object) I don't view ENOENT as a good replacement for ENODATA. The two really mean different things, but in this particular case it would seem a reasonable replacement. But how would that help you? Would you mean to monitor future patches for not again introducing some use of ENODATA that the tool stack wants to explicitly check for? That would be quite tedious a task... Jan
On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote: > >>> On 29.04.16 at 18:52, <roger.pau@citrix.com> wrote: > > On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote: > >> >>> On 29.04.16 at 18:34, <roger.pau@citrix.com> wrote: > >> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote: > >> >> >>> On 29.04.16 at 17:06, <roger.pau@citrix.com> wrote: > >> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote: > >> >> >> >>> On 29.04.16 at 16:21, <roger.pau@citrix.com> wrote: > >> >> >> > According to the POSIX standard for error codes [0], ENODATA is both > >> >> >> > obsolescent (so it may be removed in the future) and optional. > >> >> >> > >> >> >> It being optional still doesn't preclude us using it. > >> >> >> > >> >> >> > Replace it's > >> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and > >> >> >> > OpenBSD don't have this error code in the native errno.h headers. > >> >> >> > >> >> >> There's no rule saying that Xen's errno set must match any other OS'es. > >> >> >> That's one of the reasons why we (finally) separated ours. > >> >> > > >> >> > I understand that, but doing this means that then on the toolstack side we > > > >> >> > need to start doing ifdefery in order to match values that are not present > > > >> >> > in the native OS. For example a check was added to libxl against > >> >> > XENVER_build_id returning ENODATA, this means that then on libxl I would > >> >> > have to add a: > >> >> > > >> >> > #ifdef __FreeBSD__ > >> >> > #define ENODATA ENOENT > >> >> > #endif > >> >> > >> >> You ought to be using XEN_NODATA there anyway. > >> > > >> > No, the privcmd driver is the one that performs the translation from Xen > >> > error codes into the OS error code space, so the tools just see error codes > > > >> > in the OS space. No tools at all use XEN_* error codes directly. > >> > >> That's the supposed behavior for return values, but not for > >> structure contents. The structures are Xen-specific, so them > >> holding Xen-specific values is known to the callers, and they > >> should (be made) cope. > > > > And the usage of ENODATA I'm trying to fix here is from the direct return of > > > > an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I > > just think it would be better to simply replace the usage of ENODATA with > > something else, so I could avoid adding more ifdefery to the tools. > > > > Would you be fine with me just adjusting xen_build_id (in > > xen/common/version.c) to return ENOENT instead of ENODATA? > > Well, I wouldn't be particularly happy, but I'd also not be as heavily > opposed as to removing that error code altogether. In general (and > I probably should have said this in the first reply, despite there > having been the other more important reason to object) I don't view > ENOENT as a good replacement for ENODATA. The two really mean > different things, but in this particular case it would seem a reasonable > replacement. Right. But since the privcmd driver does the error code translation I think ENOENT is the closest match to ENODATA when doing automatic error translation (I'm open to suggestions if someone knows a better replacement for it). > But how would that help you? Would you mean to monitor future > patches for not again introducing some use of ENODATA that the > tool stack wants to explicitly check for? That would be quite tedious > a task... Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the FreeBSD list of error codes seems quite pointless when there's no in-tree user of it. Roger.
>>> On 02.05.16 at 10:55, <roger.pau@citrix.com> wrote: > On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote: >> But how would that help you? Would you mean to monitor future >> patches for not again introducing some use of ENODATA that the >> tool stack wants to explicitly check for? That would be quite tedious >> a task... > > Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the > FreeBSD list of error codes seems quite pointless when there's no in-tree > user of it. That's a slightly strange way of looking at it: Shouldn't a component sitting on top of another component be capable of dealing with all output of that lower component, i.e. also any of the error codes that one may produce? In which case "no in-tree user" simply becomes a non-argument imo... (For comparison, consider a user mode library not itself using EINVAL: Would you say it's okay for the library to not care about EINVAL coming back from system calls?) Jan
On Mon, May 02, 2016 at 03:06:21AM -0600, Jan Beulich wrote: > >>> On 02.05.16 at 10:55, <roger.pau@citrix.com> wrote: > > On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote: > >> But how would that help you? Would you mean to monitor future > >> patches for not again introducing some use of ENODATA that the > >> tool stack wants to explicitly check for? That would be quite tedious > >> a task... > > > > Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the > > FreeBSD list of error codes seems quite pointless when there's no in-tree > > user of it. > > That's a slightly strange way of looking at it: Shouldn't a component > sitting on top of another component be capable of dealing with all > output of that lower component, i.e. also any of the error codes that > one may produce? In which case "no in-tree user" simply becomes a > non-argument imo... (For comparison, consider a user mode library > not itself using EINVAL: Would you say it's okay for the library to not > care about EINVAL coming back from system calls?) If it wasn't marked as optional and obsolescent I would have added it to FreeBSD without questioning, but the fact that the POSIX standard says that strictly conforming POSIX applications should not use it makes me wonder whether that is the right to do. ENODATA is the only error code that Xen uses that's not part of the core POSIX error codes. IMHO Xen should be a strictly conforming POSIX application, it being a kernel that shares a common interface between a wide variety of different OSes. I don't really want to make this any longer than necessary, so I think I'm going to try to get ENODATA added to the FreeBSD errno.h header, but I wouldn't be surprised if I found some resistance there, and TBH, I don't think I will be able to make a good point. Roger.
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index c39d745..0dcc06f 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -5361,7 +5361,7 @@ static const int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info *info, r = xc_version(CTX->xch, XENVER_build_id, build); switch (r) { case -EPERM: - case -ENODATA: + case -ENOENT: case 0: info->build_id = libxl__strdup(NOGC, ""); break; diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 8cb6e9e..980b4a1 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1274,14 +1274,14 @@ static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h) printk(XENLOG_G_WARNING "HVM%d.%d restore: not enough data left to read xsave descriptor\n", d->domain_id, vcpuid); - return -ENODATA; + return -ENOENT; } if ( desc->length + sizeof (*desc) > h->size - h->cur) { printk(XENLOG_G_WARNING "HVM%d.%d restore: not enough data left to read %u xsave bytes\n", d->domain_id, vcpuid, desc->length); - return -ENODATA; + return -ENOENT; } if ( desc->length < offsetof(struct hvm_hw_cpu_xsave, save_area) + XSTATE_AREA_MIN_SIZE ) @@ -1402,14 +1402,14 @@ static int hvm_load_cpu_msrs(struct domain *d, hvm_domain_context_t *h) printk(XENLOG_G_WARNING "HVM%d.%d restore: not enough data left to read MSR descriptor\n", d->domain_id, vcpuid); - return -ENODATA; + return -ENOENT; } if ( desc->length + sizeof (*desc) > h->size - h->cur) { printk(XENLOG_G_WARNING "HVM%d.%d restore: not enough data left to read %u MSR bytes\n", d->domain_id, vcpuid, desc->length); - return -ENODATA; + return -ENOENT; } if ( desc->length < HVM_CPU_MSR_SIZE(1) ) { diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c index a61c926..ca1a026 100644 --- a/xen/arch/x86/microcode_amd.c +++ b/xen/arch/x86/microcode_amd.c @@ -342,7 +342,7 @@ static int container_fast_forward(const void *data, size_t size_left, size_t *of *offset += size; if ( !size_left ) - return -ENODATA; + return -ENOENT; } return 0; @@ -454,7 +454,7 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf, break; error = container_fast_forward(buf, bufsize - offset, &offset); - if ( error == -ENODATA ) + if ( error == -ENOENT ) { ASSERT(offset == bufsize); break; diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c index 4e06c13..6ce76e2 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -3729,7 +3729,7 @@ int shadow_track_dirty_vram(struct domain *d, dirty_vram->last_dirty = NOW(); /* Tell the caller that this time we could not track dirty bits. */ - rc = -ENODATA; + rc = -ENOENT; } else if (dirty_vram->last_dirty == -1) /* still completely clean, just copy our empty bitmap */ diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c index 0ed86a7..9d1896e 100644 --- a/xen/common/device_tree.c +++ b/xen/common/device_tree.c @@ -204,7 +204,7 @@ int dt_property_read_string(const struct dt_device_node *np, if ( !pp ) return -EINVAL; if ( !pp->value ) - return -ENODATA; + return -ENOENT; if ( strnlen(pp->value, pp->length) >= pp->length ) return -EILSEQ; diff --git a/xen/common/domctl.c b/xen/common/domctl.c index e43904e..d07114a 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -901,7 +901,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) v == current ) /* no vcpu_pause() */ goto getvcpucontext_out; - ret = -ENODATA; + ret = -ENOENT; if ( !v->is_initialised ) goto getvcpucontext_out; diff --git a/xen/common/version.c b/xen/common/version.c index 0f96849..1bffb3e 100644 --- a/xen/common/version.c +++ b/xen/common/version.c @@ -74,7 +74,7 @@ static unsigned int build_id_len __read_mostly; int xen_build_id(const void **p, unsigned int *len) { if ( !build_id_len ) - return -ENODATA; + return -ENOENT; *len = build_id_len; *p = build_id_p; @@ -91,7 +91,7 @@ int xen_build_id_check(const Elf_Note *n, unsigned int n_sz, { /* Check if we really have a build-id. */ if ( NT_GNU_BUILD_ID != n->type ) - return -ENODATA; + return -ENOENT; if ( n_sz <= sizeof(*n) ) return -EINVAL; @@ -107,7 +107,7 @@ int xen_build_id_check(const Elf_Note *n, unsigned int n_sz, /* Sanity check, name should be "GNU" for ld-generated build-id. */ if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 ) - return -ENODATA; + return -ENOENT; if ( len ) *len = n->descsz; @@ -124,11 +124,11 @@ static int __init xen_build_init(void) /* --build-id invoked with wrong parameters. */ if ( __note_gnu_build_id_end <= &n[0] ) - return -ENODATA; + return -ENOENT; /* Check for full Note header. */ if ( &n[1] > __note_gnu_build_id_end ) - return -ENODATA;; + return -ENOENT; sz = (void *)__note_gnu_build_id_end - (void *)n; diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c index 892260d..7ed59b0 100644 --- a/xen/drivers/acpi/pmstat.c +++ b/xen/drivers/acpi/pmstat.c @@ -95,7 +95,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op) if ( !pxpt || !pxpt->u.pt || !pxpt->u.trans_pt ) { spin_unlock(cpufreq_statistic_lock); - return -ENODATA; + return -ENOENT; } pxpt->u.usable = pmpt->perf.state_count - pmpt->perf.platform_limit; diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c index dd2031f..685c2cd 100644 --- a/xen/drivers/acpi/tables.c +++ b/xen/drivers/acpi/tables.c @@ -319,7 +319,7 @@ acpi_parse_entries(char *id, unsigned long table_size, if (entry->length < sizeof(*entry)) { printk(KERN_ERR PREFIX "[%4.4s:%#x] Invalid length\n", id, entry_id); - return -ENODATA; + return -ENOENT; } if (entry->type == entry_id diff --git a/xen/include/public/errno.h b/xen/include/public/errno.h index ebb853a..070f834 100644 --- a/xen/include/public/errno.h +++ b/xen/include/public/errno.h @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG, 36) /* File name too long */ XEN_ERRNO(ENOLCK, 37) /* No record locks available */ XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ XEN_ERRNO(ENOSYS, 38) /* Function not implemented */ -XEN_ERRNO(ENODATA, 61) /* No data available */ XEN_ERRNO(ETIME, 62) /* Timer expired */ XEN_ERRNO(EBADMSG, 74) /* Not a data message */ XEN_ERRNO(EOVERFLOW, 75) /* Value too large for defined data type */
According to the POSIX standard for error codes [0], ENODATA is both obsolescent (so it may be removed in the future) and optional. Replace it's usage with ENOENT, which seems like the closest match. Both FreeBSD and OpenBSD don't have this error code in the native errno.h headers. [0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Tim Deegan <tim@xen.org> Cc: George Dunlap <george.dunlap@eu.citrix.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Julien Grall <julien.grall@arm.com> --- tools/libxl/libxl.c | 2 +- xen/arch/x86/hvm/hvm.c | 8 ++++---- xen/arch/x86/microcode_amd.c | 4 ++-- xen/arch/x86/mm/shadow/common.c | 2 +- xen/common/device_tree.c | 2 +- xen/common/domctl.c | 2 +- xen/common/version.c | 10 +++++----- xen/drivers/acpi/pmstat.c | 2 +- xen/drivers/acpi/tables.c | 2 +- xen/include/public/errno.h | 1 - 10 files changed, 17 insertions(+), 18 deletions(-)