From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:27:53 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89B7588D; Tue, 15 Jan 2013 20:27:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 62B0063F; Tue, 15 Jan 2013 20:27:53 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C860B9AD; Tue, 15 Jan 2013 15:27:52 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Tue, 15 Jan 2013 14:16:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141550.13577.jhb@freebsd.org> <50F5181D.6020508@freebsd.org> In-Reply-To: <50F5181D.6020508@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151416.07231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:52 -0500 (EST) Cc: Lawrence Stewart , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:53 -0000 On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote: > On 01/15/13 07:50, John Baldwin wrote: > > The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are > > currently defined as hex values that are individual bits. However, socket > > options are never masked together, they are used as a simple enumeration of > > discrete values. Using a bitmask forces us to run out of bits and makes it > > harder for vendors to try to use a high range of values for local custom > > options (hoping that they never conflict with a new option value added in > > stock FreeBSD). > > Yup. Should we be explicitly #defining the boundary between "bits > reserved for FreeBSD" and "bits for private vendor use"? Oh, we could if you wanted. I'm using 0x1000 locally for both TCP and UDP, but those are completely arbitrary values. Saner ones might be 0x8000000 if we want to do that explicitly. We could perhaps just say that is true for all socket option levels (that is, just define one SO_VENDOR constant or some such but say it applies to all levels)? -- John Baldwin