From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ffdfp-0006aG-1J
	for qemu-devel@nongnu.org; Mon, 15 May 2006 10:03:49 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ffdfk-0006WW-Rs
	for qemu-devel@nongnu.org; Mon, 15 May 2006 10:03:48 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ffdfk-0006WQ-Mn
	for qemu-devel@nongnu.org; Mon, 15 May 2006 10:03:44 -0400
Received: from [211.5.2.75] (helo=nm01omta01b.dion.ne.jp)
	by monty-python.gnu.org with smtp (Exim 4.52) id 1FfdiA-0003Wk-Ov
	for qemu-devel@nongnu.org; Mon, 15 May 2006 10:06:15 -0400
Message-ID: <000601c67828$6542a810$0464a8c0@athlon>
From: "Kazu" <kazoo@r3.dion.ne.jp>
References: <000601c6758e$0ffe7ce0$0464a8c0@athlon>
	<44677879.3090809@bellard.org>
Subject: Re: [Qemu-devel] [PATCH] VLAN and Tap for win32
Date: Mon, 15 May 2006 23:03:51 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Monday, May 15, 2006 3:35 AM Fabrice Bellard wrote:

> Kazu wrote:
>> Hi,
>>
>> VLAN and Tap patches for win32 are updated. I added handling for wait
>> objects.
>>
>> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-vlan.patch
>
> I don't undertand this patch: the connect() is meant to be non blocking
> so the 'socket_wait_event' just after is not correct. The wait for the
> connection must be done inside the QEMU main loop as it is done on the
> Unix target (connect() on Unix in non blocking mode usually return
> EINPROGRESS and we can wait for the connection using select()).
>

connect() usually retruns with WSAEWOULDBLOCK and second time it becomes
WSAEINVAL. It doesn't become WSAEINPROGRESS.
Winsock FAQ says that WSAEWOULDBLOCK has a little different meaning with
Unix socket and a header in MinGW says that WSAEINPROGRESS is deprecated in
Winsock2.
MS says that connect() should not be called again for asynchronous socket.
This patch would be better.

http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060515-vlan.patch


>> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-tap.patch
>
> OK for this one. Suppressing all the remaning polling in the win32
> version would be good. In particular, it would be good to be able to
> wait for network events while waiting for other events.
>

I heard that WSAWaitForMultipleEvents is the same as WaitForMultipleObjects
in winsock 2 mailing list. I used it.
I think supressing polling means using win32 thread. Is it OK? I will try to
use threads.

http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060515-tap.patch

Regards,
Kazu