svn commit: r215178 - in head: lib/libc/sys sys/kern sys/sys

[Luigi Rizzo]

On Mon, Nov 15, 2010 at 12:56:29PM +0100, Ivan Voras wrote:
> On 12 November 2010 14:02, Luigi Rizzo <luigi at 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.

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