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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Rafał Wojdyła [mailto:omeg@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: 21 December 2015 22:30
> To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Marek Marczykowski-Górecki
> Subject: 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.
> 

Hi Rafal,

  I only pull public includes from Xen. They require post-processing (to 
substitute 'long' for 'LONG_PTR' mainly) but no hand editing. I think that 
pulling in actual source modules would be a lot harder (and you'd probably have 
to turn the warning level in MSVC way down to make it happy with all the 
implicit type conversion that usually goes on in Linux source code).

> 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? :)

  It's a tricky one. There's already way more code duplication than I would 
like between the drivers themselves (e.g. a lot of the PnP code is completely 
identical between XENBUS and XENVIF but I keep it separate since the drivers do 
need to be able to evolve separately) so code duplication between different OS 
implementations of an API/protocol is something that I think we just have to 
live with. There is definitely merit in keeping the Windows and Linux APIs 
'aligned' for familiarity when porting an application but, as you say, the OS 
are fundamentally different and trying to use common source is probably going 
to end up mean too much abstraction away from both OS.

  Cheers,

    Paul

> 
> - --
> Rafał Wojdyła
> Qubes Tools for Windows developer
> https://www.qubes-os.org/
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJWeH1hAAoJEIWi9rB2GrW7ulYH/1K2ylCHxSGwBAzWkbG5
> ZW4e
> RK6a9Q164jYq7++SDekfK43wddtniXJv91Ie3RYcIiHJZRi0XORVVsOQcJ+9YK03
> eBtGvQqj73ptVbiIPXlldx+SDTXyEbCLwIwoYHQ/wamq/qJDklmbs3g97NT7ossf
> aNhG4sRdM/Kwr1t7pHTlnFdHSeZnoWonwlopWZwnaoPkr6Qh0/gvF5Zd8un
> MI19T
> yT3jQutcxRes6h+HbrItty0J//TQe/GwWHVBPLWeWXzOPSbAKfrk7bXdBnpjYX
> 18
> 0t1jHqaEEZ+9H+/xLQYUd84nYGt5OP6/Ny5dbBByCo4equpONFxDOd69n2+yA
> lI=
> =7tr2
> -----END PGP SIGNATURE-----

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel