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

Re: [win-pv-devel] [PATCH] Add a user mode library wrapper for XENIFACE IOCTLs

Hash: SHA1

On 2015-11-05 22:12, Rafał Wojdyła wrote:
> On 2015-11-05 17:55, Paul Durrant wrote:
>>> -----Original Message----- From:
>>> win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx
>>> [mailto:win-pv-devel- bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
>>> Of Rafal Wojdyla Sent: 05 November 2015 14:22 To:
>>> win-pv-devel@xxxxxxxxxxxxxxxxxxxx Subject: [win-pv-devel]
>>> [PATCH] Add a user mode library wrapper for XENIFACE IOCTLs
>>> Signed-off-by: Rafal Wojdyla <omeg@xxxxxxxxxxxxxxxxxxxxxx> --- 
>>> include/xencontrol.h                         | 342 ++++++++++ 
>>> src/xencontrol/xencontrol.c                  | 915 
>>> +++++++++++++++++++++++++++ src/xencontrol/xencontrol.rc
>>> |  24 + src/xencontrol/xencontrol_private.h          |  49 ++ 
>>> vs2013/xencontrol.props                      |  84 +++ 
>>> vs2013/xencontrol/xencontrol.vcxproj         |  62 ++ 
>>> vs2013/xencontrol/xencontrol.vcxproj.filters |  13 + 
>>> vs2013/xeniface.sln                          |  38 ++ 8 files
>>> changed, 1527 insertions(+) create mode 100644
>>> include/xencontrol.h create mode 100644
>>> src/xencontrol/xencontrol.c create mode 100644
>>> src/xencontrol/xencontrol.rc create mode 100644
>>> src/xencontrol/xencontrol_private.h create mode 100644
>>> vs2013/xencontrol.props create mode 100644
>>> vs2013/xencontrol/xencontrol.vcxproj create mode 100644
>>> vs2013/xencontrol/xencontrol.vcxproj.filters
>> I also notice that there's no update to the xeniface package to
>> deliver the new DLL. Did you omit that for a reason? (I have no
>> objection to you adding the DLL to the package... I'm happy to
>> fix up the VS2012 vcxproj files if you don't have the older tools
>> to hand).
>> Paul
> Yeah, that's another thing I forgot about since I don't have VS2012
> at hand.
I got sidetracked a bit lately but would like to finish "upstreaming"
this if possible. I have a new discussion point though, regarding code
duplication with the Linux xenvchan implementation.

It turns out that my xenvchan implementation has a subtle bug that was
fixed some time ago in the Xen implementation. I had based my version
off the current Linux xenvchan which has the bug fixed, but in the
process of making it MSVC compatible I reintroduced the bug. My
colleague Marek (cc) suggested that we maybe could somehow use the
original Linux source with just some patches that make it Windows
compatible. I think you already pull some Xen sources (mainly
includes) for pvdrivers, so maybe it's possible.

This would require that the usermode xeniface bindings were as close
to Linux libxc as possible. I'm not liking the idea that a Windows DLL
would only export Linux-flavored APIs, but I could easily make
additional exports that look mostly like libxc. The main difference is
that Linux APIs don't use event objects like Windows, and use
different return values.

I admit I have some concerns that identically named functions *will*
be different at least in some places (Linux libxc vs Windows). We
can't make the API 100% identical due to fundamental OS differences,
but I agree with Marek that code duplication is an issue and should be
avoided when possible. Thoughts? :)

- -- 
Rafał Wojdyła
Qubes Tools for Windows developer


win-pv-devel mailing list



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