Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Nov 2010 09:59:38 -0800
From:      Julian Elischer <julian@freebsd.org>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Luigi Rizzo <luigi@freebsd.org>, src-committers@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject:   Re: svn commit: r215178 - in head: lib/libc/sys sys/kern sys/sys
Message-ID:  <4CE1750A.6040404@freebsd.org>
In-Reply-To: <20101115171016.GB20524@onelab2.iet.unipi.it>
References:  <201011121302.oACD2Qjt009385@svn.freebsd.org> <AANLkTinpfy-V79k0mgezJV6QpuUWMG3uOZ0hTY2tN4Rf@mail.gmail.com> <20101115171016.GB20524@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
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<luigi@freebsd.org>  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
>




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