[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:02:33PM +0100, 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.

Yes, the error value returned from the hypercall executed is indeed 
translated into the native OS error space. The problem here is that those 
error codes are returned _inside_ of the specific hypercall struct, which 
sadly privcmd doesn't know anything about.

And of course teaching privcmd about every possible hypercall struct is 
simply impossible, since some of them are not stable (eg: domctls)
 
> Aren't FreeBSD and NetBSD already doing that?

As said above, this is only done for direct return codes, everything inside 
of the struct passed to the hypercall is returned as-is.

This is a complete mess, and TBH, I don't have a clever idea about how to 
solve it.

Roger.

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