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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> >   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.
> 
> Yes, in some cases keeping the same code for different OSes is hard, but
> I think it worth some effort, because managing duplicated code is much
> more pain. For every commit you need to think about whether it should be
> also included in the other copy/copies or not (and also know about
> existence of all the copies!). And surely you will forget about it
> sometimes. The case RafaÅ mentioned was a security bug!

Indeed, it is a worthy goal. But the pain of keeping things in sync has to be 
traded off against the complexity of making the code common.

> 
> The upstream libxc library already have an abstraction for os-specific
> code. Not sure if that is flexible enough to use also for Windows, but
> IMHO it worth consideration. For example places which return FD for
> select/poll could return Event object etc.

It's worth investigating the feasibility of that if there is time to do so. I 
guess ultimately MSVC vcxproj and sln files could also be upstreamed into the 
source base if it can be made to work.

> If not possible to use exactly this one (which would make API 100%
> compatible), IMO it worth pursuing the state where as few functions as
> possible are different. Then, in case of vchan, it would mean separate
> initialization functions (for example init_gnt_evt_posix,
> init_evt_srv_windows), but most of the other code would be the same.
> 

If that is palatable to the maintainers then it sounds plausible.

> Some another idea would be to plug the current interface library into
> libxc OS abstraction. So Windows build of libxc would use (be a wrapper
> of) the current xencontrol library. But still, it would be good idea to
> design the API that way to make it as easy as possible.

Yes indeed.

Cheers,

  Paul

> 
> --
> Best Regards,
> Marek Marczykowski-GÃrecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel