From owner-svn-src-head@FreeBSD.ORG Wed Jan 14 15:43:32 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0C9106581D; Wed, 14 Jan 2009 15:43:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF25F8FC1B; Wed, 14 Jan 2009 15:43:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6317F46B03; Wed, 14 Jan 2009 10:43:31 -0500 (EST) Date: Wed, 14 Jan 2009 15:43:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <49697140.30205@elischer.org> Message-ID: References: <200901091602.n09G2Jj1061164@svn.freebsd.org> <4967A500.30205@fsn.hu> <4967B6D9.90001@elischer.org> <4967C539.2060803@fsn.hu> <49686A30.4000205@fsn.hu> <49697140.30205@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Attila Nagy , Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r186955 - in head/sys: conf netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 15:43:34 -0000 On Sat, 10 Jan 2009, Julian Elischer wrote: >>> I'm happy to (eventually) also implement the BSDI API once I actually >>> spend time looking at what the difference in behaviours are. If we're >>> lucky, the only difference is where the socket option hooks in and the >>> actual network behaviour is the same. >>> >>> (Meanwhile, I think I have to go off and implement this particular >>> behaviour in Squid, and see if the OpenBSD support indeed does function as >>> advertised.) >> >> If the API turns out to be effectly semantically the same, or better, then >> I think the suggestion is to entirely replace, rather than supplement, the >> socket option you just added with it. There's no point in having >> pointlessly divergent APIs where it can be avoided. > > I think just making the name the same should be enough.. Well, I think that depends. If it's a SOL_SOCKET-layer option, we still need some way for the protocol layer to either accept or veto setting the option, depending on whether it supports it. For example, I think SPX sockets should reject the option being set if they don't support it, so we'll need to figure out something there to either pass down the SOL_SOCKET option explicitly, or check with the protocol somehow as to whether or not to accept it. Robert N M Watson Computer Laboratory University of Cambridge