[Xen-devel] Ping: Re: [PATCH] replace bogus -ENOSYS uses

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.16 at 13:02, <JBeulich@xxxxxxxx> wrote:

Ping:

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

Does this address your concerns? I'm still hoping to get a formal
ack/nak on this one ...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel