From owner-svn-src-head@FreeBSD.ORG Mon Nov 15 17:59:42 2010 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 7A386106566B; Mon, 15 Nov 2010 17:59:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id 534A68FC19; Mon, 15 Nov 2010 17:59:42 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAFHxcmn017417; Mon, 15 Nov 2010 09:59:40 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id B83412D6017; Mon, 15 Nov 2010 09:59:36 -0800 (PST) Message-ID: <4CE1750A.6040404@freebsd.org> Date: Mon, 15 Nov 2010 09:59:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Luigi Rizzo References: <201011121302.oACD2Qjt009385@svn.freebsd.org> <20101115171016.GB20524@onelab2.iet.unipi.it> In-Reply-To: <20101115171016.GB20524@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Luigi Rizzo , src-committers@freebsd.org, Ivan Voras Subject: Re: svn commit: r215178 - in head: lib/libc/sys sys/kern sys/sys 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: Mon, 15 Nov 2010 17:59:42 -0000 On 11/15/10 9:10 AM, Luigi Rizzo wrote: > On Mon, Nov 15, 2010 at 12:56:29PM +0100, Ivan Voras wrote: >> On 12 November 2010 14:02, Luigi Rizzo wrote: >>> Author: luigi >>> Date: Fri Nov 12 13:02:26 2010 >>> New Revision: 215178 >>> URL: http://svn.freebsd.org/changeset/base/215178 >>> >>> Log: >>> ??This commit implements the SO_USER_COOKIE socket option, which lets >>> ??you tag a socket with an uint32_t value. The cookie can then be >>> ??used by the kernel for various purposes, e.g. setting the skipto >>> ??rule or pipe number in ipfw (this is the reason SO_USER_COOKIE has >>> ??been implemented; however there is nothing ipfw-specific in its >>> ??implementation). >> While at it, why not intptr_t? It would be marginally more useful and >> almost free. > several reasons, some generic, some specific to this application: > > 1. [generic] over time i have become more and more a fan of fixed-size, > arch-indepentent fields in defining APIs/ABIs. I think this > greatly improves code portability and reduces the chance of bugs > induced by compilers or headers. > > 2. [generic] passing pointers between userland and kernel > requires remapping the pointer when going up or down. > As the mapping would be application specific, i don't > see much use in allowing room for a pointer without kernel code > to map userland<-> kernel pointers. > > 3. [specific] use of signed vs unsigned, of course the two choices are > completely equivalent but since i needed an unsigned value i > saw no reason to go for an int instead of uint; > > 4. [specific] choosing 64 bit might have given perhaps more > flexibility, but then again a) the reason for introducing this > change only needed 32-bit operand, and b) the use of 64-bit would > make the code marginally bigger/slower for 32-bit architectures. also it's supposed to take the place of a tablearg which is 32 bits is it not? > I think #3 and #4 are completely debatable, but #1 and #2 are in > my opinion a compelling reason to avoid intptr_t and int vs int32_t > in an API. > > cheers > luigi > cheaper for 32-bit ma >