[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: doc getsockopt, setsockopt

From: Greg Troxel
Subject: Re: doc getsockopt, setsockopt
Date: 30 Sep 2005 11:58:11 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Kevin Ryde <address@hidden> writes:

> I'm looking to combine the getsockopt and setsockopt descriptions and
> add the available constants, including the new IP_ADD_MEMBERSHIP and
> IP_DROP_MEMBERSHIP, especially since you need to know to pass a pair
> for those (and for SO_LINGER).

Thanks (I sent in IP_ADD_MEMBERSHIP without doc fixes...).

> I'm not sure if SOL_IP is meant to be used directly.  You'd think so
> from the name, but the getsockopt man page refers to getprotoent().

I'm guessing you mean 'the man page on some version of Linux', but I
checked on NetBSD-current, and it says the same thing.

I read NetBSD-current kernel sources, and the basic system call checks
against SO_SOCKET, and if so processes the setsockopt.  Otherwise, it
dispatches to the protocol control output routine for the protocol of
the socket.  In the UDP control output routine, it checks against
IPPROTO_UDP and if so handles it there, and if not forwards to
ip_ctloutput.  ip_ctloutput insists on level IPPROTO_IP.

NetBSD does not define SOL_IP.  SOL_SOCKET is 0xffff.  So from the
NetBSD point of view, the right thing to do is define
IPPROTO_{IP,UDP,TCP} as (constant) variables.

NetBSD's Linux compatibility code indicates that SOL_IP is 0, but has
a comment that these values can vary by architecture (details FWIW,
which I think is not much):

in compat/linux/socket.h:

#define LINUX_SOL_IP            0
#define LINUX_SOL_TCP           6
#define LINUX_SOL_UDP           17

src/sys/compat/linux > egrep LINUX_SOL_SOCKET arch/*/*
arch/alpha/linux_socket.h:#define LINUX_SOL_SOCKET      0xffff
arch/amd64/linux_socket.h:#define LINUX_SOL_SOCKET      1
arch/arm/linux_socket.h:#define LINUX_SOL_SOCKET        1
arch/i386/linux_socket.h:#define LINUX_SOL_SOCKET       1
arch/m68k/linux_socket.h:#define LINUX_SOL_SOCKET       1
arch/mips/linux_socket.h:#define LINUX_SOL_SOCKET       0xffff
arch/powerpc/linux_socket.h:#define LINUX_SOL_SOCKET 1

> I think I'll change socket.c from IPPROTO_IP to SOL_IP.  The two are
> the same value, but best to ensure the code matches the docs.

I think the docs are wrong here, and SOL_IP is not defined on NetBSD
and thus may be Linux specific.

After defining IPPRPOTO_{IP,UDP,TCP} as variables, it seems like
removing SOL_IP, SOL_TCP and SOL_UDP is in order, since they aren't
portable and guile should behave the same on all machines to the
extent possible/reasonable.

It would be interesting to hear what variables the Linux kernel
actually compares to - IPPROTO_IP or SOL_IP.

>      For `SOL_IP' level the following options are defined (when
>      provided by the system).  See `man 7 ip' for what they mean.

'man 7 ip' is Linux specific (it's ip(4) on BSD).  Perhaps "Consult
operating system documentation for these calls".

Hmm, I would have thought UDP, but my code (for which I added these)
says '0' for level, which is IPPROTO_IP.

>       -- Variable: IP_ADD_MEMBERSHIP
>       -- Variable: IP_DROP_MEMBERSHIP
>           These can be used only with `setsockopt', not `getsockopt'.
>           VALUE is a pair of integer IPv4 addresses `(MULTIADDR .
>           INTERFACEADDR)' (*note Network Address Conversion::).

How about just adding:

MULTIADDR is the multicast group to be joined or left, and
INTERFACEADDR is an IP adddress by which an interface will be found to
perform the join/leave operation.  INTERFACEADDR may be INADDR_ANY in
which case the default interface will be used. These values are simply
passed to the underlying system call, so extensions on some systems to
specify interface by ifindex may be available.

Or skip the last sentence, or the second half of it.  People who
understand specifying interfaces by ifindex will hopefully realize the
portability issues of that.

        Greg Troxel <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]