Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, Nov 19, 2008 at 01:28:23PM -0500, David Lively wrote:
On Wed, 2008-11-19 at 16:49 +0000, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote:
> > While starting to think about Windows compability, I realized the newly
> > exposed API for registering an external EventImpl is not adequate.
> > Currently it's assuming 32-bit unix fds. But Windows uses a pointer
> > (HANDLE) here. So we need to generalize this interface so it can be
> > implemented for 64-bit Windows. The attached patch does this. (I'm
> > sure it conflicts with work Dan B is doing, so I'm hoping he'll just
> > incorporate this into his changes.)
>
> I'm not sure whether this is actually required. We're using gnulib for
> socket stuff, and that wraps the Winsock socket() call so that it returns
> a real file descriptor rather than a socket handle. It does this calling
> _open_osfhandle which appears to be declared to accept a 'long' and return
> an 'int' - at least in MinGW headers.
That means that the Windows application using libvirt must use gnulib as
well. If the Windows version of libvirt actually exports the gnulib
bindings and headers, then I guess that's not a problem. But does it
export gnulib?
No, the gnulib stuff is internal only - we don't force any apps to also
use gnulib.
It does however mean we should document that the 'fd' arg of the
the virEventAddHandle callback is an file handle, and not a socket
handle on Win32, so apps are clear on what to expect.
If they're not using gnulib themselves, they can trivially convert
back to a true socket handle if desired.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|