[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.



On Fri, Apr 29, 2016 at 04:11:47PM +0100, Andrew Cooper wrote:
> On 29/04/16 16:02, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> >> Avoid using system errno values when comparing with Xen errno values.
> >>
> >> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >> ---
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >> Cc: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> >> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> >> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> >> ---
> >> Using errno values inside of hypercall structs is not right IMHO, but there
> >> are already several occurrences of this. Although I'm adding the correct 
> >> XEN_
> >> prefixes here, it's very likely that new additions/modifications to this
> >> file will not take this into account, breaking it for OSes != Linux.
> > This seems to be a rather thorny issue.
> >
> > I have a gut feeling that returning XEN_ errno to userspace program is
> > layering violation. They should always be translated to OS level errno
> > by privcmd driver.
> >
> > Aren't FreeBSD and NetBSD already doing that?
> 
> It is not practical for the privcmd driver to do this translation, as
> most hypercalls through the privcmd driver are toolstack calls, and have
> an unstable layout.
> 

If what you mean is what Roger said in his other reply then I agree
translating in privcmd is not doable.

> Another thorny issue is that the ioctl() call for privcmd returns errors
> via errno, which may be in system errno space, or xen errno space
> depending on the source of the errno.
> 
> This is very large swamp in desperate need of some attention.
> 

Indeed.

Wei.

> ~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.