Re: [Xen-devel] [PATCH RFC] make error codes a formal part of the ABI

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.01.15 at 17:40, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/01/15 16:21, Jan Beulich wrote:
>> Now that we have two cases where patches against hvmloader got
>> submitted needing to include the hypervisor's errno.h (for the host's
>> system header not necessarily reflecting the correct numbers), take
>> this as a strong sign that we need to make the error return values part
>> of the hypervisor ABI (which de-fact they've always been).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> There's on small block commented with TBD left in the public header.
>> This is the main reason for the submission being RFC. While we don't
>> currently use these error codes, I'm not sure if we should leave all
>> or some of them out for the time being.
> 
> I would suggest that we drop any error codes not in use.  We can always
> add them back in in the future if they are needed.
> 
> I would also suggest that we note the heritage, being taken from Linux
> 2.$mumble, which will act as a guide for introducing new codes in the
> future.

Good idea - I added a respective note.

> Finally, I would suggest that we assign the Xen meaning (e.g. EACCES =
> bad tool interface) rather than Linux meanings.

Looking through the uses, EACCES isn't solely used for that purpose,
and hence I'd like to keep the comment as is (assuming that it's the
comments associated with each entry that your remark was about).

>> +#ifdef XEN_ERRNO
>> +
>> +XEN_ERRNO(EPERM,     1)     /* Operation not permitted */
>> +XEN_ERRNO(ENOENT,    2)     /* No such file or directory */
>> +XEN_ERRNO(ESRCH,     3)     /* No such process */
>> +#ifdef __XEN__
>> +XEN_ERRNO(EINTR,     4)     /* Interrupted system call */
>> +#endif
> 
> Why is EINTR (and ERESTART lower) hidden from non-xen consumers but
> still in the public api?  Would it not be better to keep these in
> xen/errno.h rather than public/errno.h ?

As said in the reply to Ian - to avoid the risk of introducing conflicting
definitions later, I'd like to keep them all in a single place.

Jan


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