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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list