From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAnca-0003yV-Cy for qemu-devel@nongnu.org; Thu, 22 Mar 2012 15:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAncY-0006yX-Cl for qemu-devel@nongnu.org; Thu, 22 Mar 2012 15:24:27 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:58748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAncY-0006yL-3x for qemu-devel@nongnu.org; Thu, 22 Mar 2012 15:24:26 -0400 Received: by wgbfm10 with SMTP id fm10so1648421wgb.10 for ; Thu, 22 Mar 2012 12:24:24 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4F6B7C65.6080201@redhat.com> Date: Thu, 22 Mar 2012 20:24:21 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1332374573-6137-1-git-send-email-pbonzini@redhat.com> <1332374573-6137-2-git-send-email-pbonzini@redhat.com> <4F6B38CB.8080400@siemens.com> In-Reply-To: <4F6B38CB.8080400@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] slirp: clean up conflicts with system headers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org Il 22/03/2012 15:35, Jan Kiszka ha scritto: >> @@ -167,9 +164,6 @@ int inet_aton(const char *cp, struct in_addr *ia); >> #include "bootp.h" >> #include "tftp.h" >> >> -/* osdep.c */ >> -int qemu_socket(int domain, int type, int protocol); >> - >> #define ETH_ALEN 6 >> #define ETH_HLEN 14 >> >> diff --git a/slirp/tcp.h b/slirp/tcp.h >> index b3817cb..8299603 100644 >> --- a/slirp/tcp.h >> +++ b/slirp/tcp.h >> @@ -45,6 +45,7 @@ typedef uint32_t tcp_seq; >> * TCP header. >> * Per RFC 793, September, 1981. >> */ >> +#define tcphdr slirp_tcphdr > > Nice :). What about s/tcphdr/bsd_tcphdr/ or so for all slirp files? Well, we have a precedent here: /* Avoid conflicting with the libc insque() and remque(), which have different prototypes. */ #define insque slirp_insque #define remque slirp_remque > Even better would be enabling slirp to use an existing declaration. But that > looks trickier in first sight. Yep, especially with no Autoconf. >> struct tcphdr { >> uint16_t th_sport; /* source port */ >> uint16_t th_dport; /* destination port */ >> @@ -58,12 +59,6 @@ struct tcphdr { >> th_off:4; /* data offset */ >> #endif >> uint8_t th_flags; >> -#define TH_FIN 0x01 >> -#define TH_SYN 0x02 >> -#define TH_RST 0x04 >> -#define TH_PUSH 0x08 >> -#define TH_ACK 0x10 >> -#define TH_URG 0x20 >> uint16_t th_win; /* window */ >> uint16_t th_sum; /* checksum */ >> uint16_t th_urp; /* urgent pointer */ >> @@ -71,6 +66,16 @@ struct tcphdr { >> >> #include "tcp_var.h" >> >> +#ifndef TH_FIN >> +#define TH_FIN 0x01 >> +#define TH_SYN 0x02 >> +#define TH_RST 0x04 >> +#define TH_PUSH 0x08 >> +#define TH_ACK 0x10 >> +#define TH_URG 0x20 >> +#endif >> + >> +#ifndef TCPOPT_EOL >> #define TCPOPT_EOL 0 >> #define TCPOPT_NOP 1 >> #define TCPOPT_MAXSEG 2 >> @@ -86,6 +91,7 @@ struct tcphdr { >> >> #define TCPOPT_TSTAMP_HDR \ >> (TCPOPT_NOP<<24|TCPOPT_NOP<<16|TCPOPT_TIMESTAMP<<8|TCPOLEN_TIMESTAMP) >> +#endif > > Is there no portable header that offers those defines for us? That would be netinet/tcp.h, but the problem is that there are some differences. For example TCP_MSS is usually 512. BTW the same could happen for ip.h, it's only that we never include it. We need to include netinet/tcp.h outside slirp for TCP_NODELAY. >> /* >> * Default maximum segment size for TCP. >> @@ -95,10 +101,13 @@ struct tcphdr { >> * >> * We make this 1460 because we only care about Ethernet in the qemu context. >> */ >> +#undef TCP_MSS >> #define TCP_MSS 1460 >> >> +#undef TCP_MAXWIN >> #define TCP_MAXWIN 65535 /* largest value for (unscaled) window */ >> >> +#undef TCP_MAX_WINSHIFT >> #define TCP_MAX_WINSHIFT 14 /* maximum window shift */ >> >> /* > > Same here. > > The direction is appreciated a lot, but I'm measuring only a moderate > overall hack-level reduction. ;) Agreed, but one step at a time... this patch sticks to what it promises, "clean up conflicts with system headers". :) Paolo