[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses
>>> On 12.08.16 at 12:34, <george.dunlap@xxxxxxxxxx> wrote: > On 11/08/16 19:10, Andrew Cooper wrote: >> On 09/08/16 11:40, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/mtrr/main.c >>> +++ b/xen/arch/x86/cpu/mtrr/main.c >>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >>> printk(KERN_WARNING >>> "mtrr: your processor doesn't support >>> write-combining\n"); >>> - return -ENOSYS; >>> + return -EOPNOTSUPP; >> >> Will this break the classic-xen MTRR code? ISTR it was very picky, from >> the cpuid work. Also, as some further cleanup, that printk should >> become a print-once. >> >> The others look ok. > > That does bring up a good general point though -- the return value is > part of the ABI. Are you reasonably confident that none of the callers > will be confused when this return value changes? If so, a note in the > commit message justifying this confidence would be helpful I think. I don't think specific return values can be considered part of the ABI, or else we couldn't e.g. change the order in which certain checks get performed. And then please also consider a hypothetical future hypervisor with the MTRR operations simply ripped out - that would return -ENOSYS or -EOPNOTSUPP then too, without a way for the caller to tell that more generic error condition from the more specific one here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |