>>> On 04.12.18 at 10:10, <christopher.w.cl...@gmail.com> wrote: > On Mon, Dec 3, 2018 at 7:42 AM Jan Beulich <jbeul...@suse.com> wrote: >> >> >>> On 01.12.18 at 02:32, <christopher.w.cl...@gmail.com> wrote: >> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html >> > describes these codes thus: >> > EMSGSIZE : "Message too large" >> > ECONNREFUSED : "Connection refused". >> >> If you were to go solely by what POSIX mandates to have, more >> additions would be necessary afaict. We had limited ourselves to >> some basic set, so selective additions need further rationale put >> here. The more that for both added error codes the use case in >> the hypervisor isn't immediately obvious. > > Thanks for reviewing the series and the previous iterations of this work. > > I note your other message indicating a preference for including these > changes at point of first use and I will do so in the next revision.
Actually, for the error code additions here I wouldn't insist on them getting folded into patches using them, as long as it is explained well here why the additions are desired. > An aside before the rationales below: part of the motivation for > selection of these error codes is to continue alignment with the > modern v4v implementation in uxen where possible. > > EMSGSIZE: > > This series proposes to return EMSGSIZE for a sendv operation (patch > #15) where an excess amount of data, across all iovs, has been > supplied, exceeding either the statically configured maximum size of a > transmittable message, or the (variable) size of the ring registered > by another domain. Ah yes, for a send-like operation I can see its use. > ECONNREFUSED: > > This series proposes to return ECONNREFUSED whenever a remote domain > is specified that either does not exist or is not argo-enabled. > This affects both the ring registration and sending data operations. > (register op, patch #13; sendv op, patch #15) > > ECONNREFUSED seems plausible for this use as it is determined by the > remote domain state within the hypervisor. Makes sense for the not argo-enabled case. The domain not existing case, however, is nothing argo-specific, and we use a pretty consistent -ESRCH in such cases, I think. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
