qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOCh


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32
Date: Thu, 10 Mar 2016 18:36:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 10/03/2016 18:26, Daniel P. Berrange wrote:
> This series started out as an attempt to fix the Win32 problems
> identified by Andrew Baumann
> 
>    https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg01343.html
> 
> It turned into a significantly larger cleanup of some chardev
> and osdep win32 portability code.
> 
> Patch 1 addresses Andrew's 2nd stated problem - handling of
> getpeername() failures, by fixing errno handling on Win32.
> 
> Patches 2-7 do some fixes in the test-io-channel-socket test
> case so that it is able to run on Win32.
> 
> Patches 8-12 are some fixes for the QIOChannel code
> 
> Patch 13 is the big one that changes QIOChannelSocket so that
> it uses a Win32 specific GSource implementation for creating
> watches. This is the key fix for Andrew's 1st stated problem.
> 
> At this point tests/test-io-channel-socket passes and
> 
>   qemu-system-x86_64.exe  -serial tcp:127.0.0.1:9000,server,nowait -device 
> sga -display non
> 
> works on win32 once more.
> 
> Patches 14-16 are some cleanups to the chardev code to improve
> its clarity. They are not required for fixing any real problem
> 
> Patches 17-18 change the way we provide Win32 portability for
> sockets APIs inside QEMU. These do fix a number of bugs in the
> QEMU code related to mistaken use of errno instead of
> socket_error(). None of these bugs appear to be critical issues.
> 
> Based on this, I'm proposing 1-13 for QEMU 2.6 release as they
> fix critical win32 bugs.
> 
> Patches 14-18 can either be included in 2.6 or 2.7 - I'm
> ambivalent on which, since they're cleanups / minor fixes.

Thanks, please submit all of them in a pull request for 2.6.

We can then clean up EAGAIN vs. EWOULDBLOCK and add a checkpatch rule to
prevent further introduction of EWOULDBLOCK.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]