[Qemu-devel] Set SO_REUSEADDR at the right time

[Qemu-devel] Set SO_REUSEADDR at the right time

[Nickolai Zeldovich]

It looks like qemu (at least version 0.7.2, which is what I'm running
here) doesn't set SO_REUSEADDR before calling bind(), which makes that
fairly useless.  This obvious patch moves up setting SO_REUSEADDR to the
right place, just before bind().

Apologies if this is already fixed in 0.8.0.

-- kolya

--- slirp/socket.c.orig	2006-01-16 15:54:40.993024000 -0800
+++ slirp/socket.c	2006-01-16 15:55:06.049849000 -0800
@@ -573,6 +573,7 @@
 	addr.sin_port = port;

 	if (((s = socket(AF_INET,SOCK_STREAM,0)) < 0) ||
+	    (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) ||
 	    (bind(s,(struct sockaddr *)&addr, sizeof(addr)) < 0) ||
 	    (listen(s,1) < 0)) {
 		int tmperrno = errno; /* Don't clobber the real reason we failed */
@@ -587,7 +588,6 @@
 #endif
 		return NULL;
 	}
-	setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)&opt,sizeof(int));
 	setsockopt(s,SOL_SOCKET,SO_OOBINLINE,(char *)&opt,sizeof(int));

 	getsockname(s,(struct sockaddr *)&addr,&addrlen);

Re: [Qemu-devel] Set SO_REUSEADDR at the right time

[John R. Hogerhuis]

Hi,

On Mon, 2006-01-16 at 16:03 -0800, Nickolai Zeldovich wrote:
> It looks like qemu (at least version 0.7.2, which is what I'm running
> here) doesn't set SO_REUSEADDR before calling bind(), which makes that
> fairly useless.  This obvious patch moves up setting SO_REUSEADDR to the
> right place, just before bind().
> 

FYI, Fabrice has a hard enough time tracking patches. I have no data to
back this up, but you might have more luck if you mark the subject of
your email with [PATCH]. Then we he goes looking for a batch of patches
to apply he can find them.

-- John.

Re: [Qemu-devel] Set SO_REUSEADDR at the right time

[Michael Renzmann]

Hi.

On Sun, 2006-01-22 at 15:32 -0800, John R. Hogerhuis wrote:
> FYI, Fabrice has a hard enough time tracking patches.

That sounds familiar. We (MadWifi, that is) had similar problems about
half a year ago. Due to the preferences of the previous maintainer of
this driver we did nearly everything by e-mail: patch submission, bug
reports, feature requests, stuff like this. It was quite hard and very
time consuming to follow all items and answer questions like "what is
the current state of this bug", "is anyone working on integrating that
patch" or "this patch has not yet been integrated, why?".

Most of these problems have been solved by starting to use Trac [1]. It
combines a wiki, a ticket engine, a webbased SVN repository browser and
some other goodies. Works like a charm, freed up a lot of resources and
help to improve the transparency of the project. We don't want to miss
it anymore.

Basically, I'd suggest to consider using some webbased software to
manage things like bug reports, patches and feature requests. Trac might
not fit the need of this project, but there are other tools around for
similar tasks. 

My 0.02 Euro.

Bye, Mike