From owner-svn-src-all@FreeBSD.ORG Mon Nov 15 17:16:42 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA4A106566C; Mon, 15 Nov 2010 17:16:42 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7E58FC13; Mon, 15 Nov 2010 17:16:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A3D8973098; Mon, 15 Nov 2010 18:10:16 +0100 (CET) Date: Mon, 15 Nov 2010 18:10:16 +0100 From: Luigi Rizzo To: Ivan Voras Message-ID: <20101115171016.GB20524@onelab2.iet.unipi.it> References: <201011121302.oACD2Qjt009385@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@FreeBSD.org, Luigi Rizzo , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r215178 - in head: lib/libc/sys sys/kern sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 17:16:42 -0000 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. 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