Re: getsockopt(2)

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

christos%astron.com@localhost (Christos Zoulas) wrote:
>In article <x7r2s0vlwx.fsf%ren.fdy2.co.uk@localhost>,
>Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>>
>>christos%astron.com@localhost (Christos Zoulas) wrote:
>>>In article <x7tvwxuezy.fsf%ren.fdy2.co.uk@localhost>,
>>>Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>>>>
>>>>christos%astron.com@localhost (Christos Zoulas) wrote:
>>>>>In article <x7bmjabmv3.fsf%ren.fdy2.co.uk@localhost>,
>>>>>
>>>>>So depending on the contents of the sockval we do something different?
>>>>
>>>>FreeBSD does. The calls to copy in or out the data are scattered
>>>>throughout the network stack.
>>>
>>>Is sockval always an int? 
>>
>>Do you mean optname or optval ?
>
>optval.

Ok. No it isn't always an int.

An example of setting something bigger than this would be
IP_IPSEC_POLICY in sys/netinet/ip_output.c line 1206.

The data for accept filters is bigger than an int too.

>>The operation required for setsockopt() is to mostly set things but in
>>certain cases to return an int value that results from setting stuff.
>
>I've lost track of what we are trying to achieve :-( Can you please
>post an example?

There are two categories of extra things that we need to support:

1) Some "get" operations require an extra parameter to select the
correct thing to return.

The "get" side of IP_IPSEC_POLICY is currently wrapped in #ifdef 0
as it won't work without an extra parameter.

SCTP can have multiple endpoints defined for each socket, identified
by an "association" handle, in order to get the correct socket value(s)
the association needs to be passed in as well as the optname that
identifies which type of value is required.

2) In the SCTP code there are extra operations defined that are really
extensions to the socket API, these could be mapped onto new syscalls
but have mostly been implemented by being triggered by setsockopt(2)
requests.

>Also lets compile a table of choices that has:
>
>- description of what's done
>- which os implemented it (if any)
>- pros
>- cons

KAME:

  Added code to sys/kern/uipc_syscalls.c to copy optval contents in and
  out for both setsockopt(2) and getsockopt(2) when built for NetBSD.

  Implements draft of SCTP API.

  Added syscall for sctp_peeloff() operation.

  Other SCTP operations map onto setsockopt(2) requests.

FreeBSD

  Copies optval into kernel as well as out for some getsockopt() and
  setsockopt() requests, code is scattered throughout network stack.

  Manpages don't match implementation, optval shown as 'const' in
  manpage but isn't in kernel source.

  Implements RFC 6458 SCTP API.

  Has sctp_peeloff() as syscall.

  Other SCTP operations map onto setsockopt(2) requests.

Linux:

  Copies optval into kernel as well as out for getsockopt() but only
  for SCTP protocol sockets.
  
  Implements RFC 6458 SCTP API.

  sctp_peeloff() is done through setsockopt() not a syscall.

  Return value of setsockopt(2) used to copy back an int value
  for extra SCTP socket operations:
  <https://sourceforge.net/p/lksctp/mailman/message/18962336/>

  Manpages nearly match implementation, missing is description of
  meaning of positive return value from setsockopt(2) and that
  getsockopt(2) can sometimes copy in optval.

NetBSD:

  Conforms strictly to standard for getsockopt(2) and setsockopt(2).

  Manpages match implementation.

  I suspect that the "get" of IP_IPSEC_POLICY has never worked since we
  imported the IPSEC code.

  Doesn't yet have way to pass extra parameter to "get" socket options.

  Doesn't yet have sctp_peeloff().

  Doesn't have a way of triggering extra SCTP socket operations and
  getting results back to userland.



Options for NetBSD:

  Copy in optval for getsockopt(2):

    Pro: Allows "get" of IP_IPSEC_POLICY using original KAME API.
    Con: Diverges from standard. Broken KAME API hasn't been a problem.

    Wouldn't be too much work to move SCTP operations that were
    triggered by setsockopt() requests in KAME sources to be triggered
    by getsockopt() requests instead.

  Selectively copy out optval for setsockopt(2):

    Pro: no change to SCTP code.
    Con: Breaks standard API. Need small change to all other protocols.

  Add new syscall to read/write optval:

    Pro: Doesn't break standard for [set/get]sockopt() API.
    Con: Doesn't fix IPSEC userland API.

    Could map onto PRCO_GETOPT within the kernel to minimize changes
    to protocol code.

  sctp_peeloff():

    Add syscall for it:

      Pro: Code from KAME builds under -current and is ready to commit.
      Con: Adds a new syscall.

    Map it onto a [set/get/update]sockopt() request:

      Pro: Doesn't need a new syscall.
      Con: Would need to rewrite implementation. Operation needs to do
           file descriptor manipulation which doesn't belong in network
           protocol code.