[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] xen: Implement hypercall for tracing of program counters
>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 07/31/17 2:01 PM >>> >On 31/07/17 12:58, Paul Durrant wrote: >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Ian >> Jackson >> Sent: 31 July 2017 12:14 >>> Wei Liu writes ("Re: [Xen-devel] [PATCH v2] xen: Implement hypercall for >>> tracing of program counters"): >>>> On Mon, Jul 31, 2017 at 09:22:35AM +0100, Julien Grall wrote: >>>>> Should not it be -EOPNOTSUPP to match return error when >>> CONFIG_TRACE_PC is >>>>> not? >>>> AIUI EOPNOTSUPP means "This is a valid operation but I am not configured >>>> to support it" while EINVAL means "This is an invalid value >>>> (operation)". >>> EOPNOTSUPP means "someone somewhere might think this is valid, but I >>> don't understand it". It can be used, for example, for unknown >>> operation numbers. >>> >>> "ENOSYS" is used in exactly the same situation, but where the enum >>> whose value is not understood is precisely the syscall number. In the >>> context of the hypervisor I think ENOSYS is used for "unknown >>> hypercall number". I haven't checked whether it is used for "unknown >>> operation number" but I suspect that the hypervisor users EOPNOTSUPP >>> for that. >> Nope. It's ENOSYS for that case too (certainly for hvm and memory ops... >> which is what I checked). > >History has been poor to us. Quite a few of the ENOSYS should be >EOPNOTSUPP, but we can't change them for ABI reasons. Right, but the result here ought to be that we at least don't introduce any new bogus uses of ENOSYS or EINVAL. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |