unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@ir.bbn.com>
Subject: Re: doc getsockopt, setsockopt
Date: 30 Sep 2005 11:58:11 -0400	[thread overview]
Message-ID: <rmiirwi35v0.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <87k6h0g9qd.fsf@zip.com.au>

Kevin Ryde <user42@zip.com.au> 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 <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2005-09-30 15:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-28 21:31 doc getsockopt, setsockopt Kevin Ryde
2005-09-30 15:58 ` Greg Troxel [this message]
2005-09-30 23:06   ` Kevin Ryde
2005-10-02 23:09     ` Greg Troxel
2005-10-03  1:10       ` Kevin Ryde
2005-10-03 23:46         ` Greg Troxel
2005-10-11 22:54           ` Kevin Ryde
2005-10-12 14:30             ` Greg Troxel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmiirwi35v0.fsf@fnord.ir.bbn.com \
    --to=gdt@ir.bbn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).