[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
-----BEGIN PGP SIGNED MESSAGE----- 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 https://www.qubes-os.org/ -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWeH1hAAoJEIWi9rB2GrW7ulYH/1K2ylCHxSGwBAzWkbG5ZW4e RK6a9Q164jYq7++SDekfK43wddtniXJv91Ie3RYcIiHJZRi0XORVVsOQcJ+9YK03 eBtGvQqj73ptVbiIPXlldx+SDTXyEbCLwIwoYHQ/wamq/qJDklmbs3g97NT7ossf aNhG4sRdM/Kwr1t7pHTlnFdHSeZnoWonwlopWZwnaoPkr6Qh0/gvF5Zd8unMI19T yT3jQutcxRes6h+HbrItty0J//TQe/GwWHVBPLWeWXzOPSbAKfrk7bXdBnpjYX18 0t1jHqaEEZ+9H+/xLQYUd84nYGt5OP6/Ny5dbBByCo4equpONFxDOd69n2+yAlI= =7tr2 -----END PGP SIGNATURE----- _______________________________________________ win-pv-devel mailing list win-pv-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |