Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jan 2009 20:10:40 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, Attila Nagy <bra@fsn.hu>, Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org
Subject:   Re: svn commit: r186955 - in head/sys: conf netinet
Message-ID:  <49697140.30205@elischer.org>
In-Reply-To: <alpine.BSF.2.00.0901102331510.16794@fledge.watson.org>
References:  <200901091602.n09G2Jj1061164@svn.freebsd.org> <4967A500.30205@fsn.hu> <4967B6D9.90001@elischer.org> <4967C539.2060803@fsn.hu> <d763ac660901091411x40eb8084v134f0ab2189afddb@mail.gmail.com> <49686A30.4000205@fsn.hu> <alpine.BSF.2.00.0901101026220.16794@fledge.watson.org> <d763ac660901101012icb544b1v3ff940bd39f1abb6@mail.gmail.com> <alpine.BSF.2.00.0901102331510.16794@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> 
> On Sat, 10 Jan 2009, Adrian Chadd wrote:
> 
>> 2009/1/10 Robert Watson <rwatson@freebsd.org>:
>>
>>> I think Julian's analysis, that this is more of an inet option than a 
>>> socket-layer option, seems more appropriate to me, the benefits of 
>>> portability in adopting the API used by OpenBSD/BSDI/etc seem more 
>>> compelling.  We should make sure that, if we move to the socket 
>>> option used on those systems, we block setting it on non-supporting 
>>> protocols, or confusion will result.  In particular, Adrian's change 
>>> only modified IPv4, not IPv6, so until it's implemented on IPv6 it 
>>> shouldn't be possible to set the option.
>>
>> 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..

> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49697140.30205>