Re: [PATCH] build-sys: fix win32 compilation with --target-list=''

["Marc-André Lureau" <marcandre.lureau@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Hi

On Thu, Dec 17, 2020 at 3:47 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 17/12/20 12:32, Claudio Fontana wrote:
> > Is the root cause elsewhere though?
> >
> > I don't like stubs very much, because often they are introduced as the
> easy way out of a problem instead of doing the necessary refactoring,
> > and they end up confusing the hell out of someone trying to understand
> what is actually used where, never mind trying to debug the linker errors.
> >
> > There is already an bunch of #ifndef _WIN32, #else , ... in
> util/main-loop.c (quite a bunch of them really),
> > is that what actually needs reworking, and putting the pieces together
> in the build system in a way that makes sense?
>
> qemu_fd_register is almost not needed at all, since we have
>
>          WSAEventSelect(node->pfd.fd, event, bitmask);
>
> in aio_set_fd_handler.  I think we can remove the call to
> qemu_fd_register from qemu_try_set_nonblock, and that should fix the
> issue as well.
>

That's tricky to say whether this won't introduce regression. For most fds
from qemu, if they use aio_set_fd_handler, that should be ok.

But what about other fds? For examples, the ones from slirp? In fact, I
don't understand how it could work today. We are passing socket() fd
directly to g_poll(). But according to the documentation:

 * On Win32, the fd in a GPollFD should be Win32 HANDLE (*not* a file
 * descriptor as provided by the C runtime) that can be used by
 * MsgWaitForMultipleObjects. This does *not* include file handles
 * from CreateFile, SOCKETs, nor pipe handles. (But you can use
 * WSAEventSelect to signal events when a SOCKET is readable).

And MsgWaitForMultipleObjects doesn't mention SOCKET as being valid handles
to wait for.

But when I run qemu with slirp, with or without qemu_fd_register, I don't
see any error or regression.

Am I missing something?

[-- Attachment #2: Type: text/html, Size: 2441 bytes --]