Re: getsockopt(2)

[christos%astron.com@localhost (Christos Zoulas)]

In article <x7lgi6uze1.fsf%ren.fdy2.co.uk@localhost>,
Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>
>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.


Thanks for documenting all of this!

>
>
>
>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.

Well, are the semantics though such as to "set" things? While the getsockopt
call change the state? If yes, perhaps this is not the most intuitive way.
How many calls are we talking about? I think leaving the source the same
is a big plus, or coming up with a macro that works for both NetBSD and
FreeBSD.

>  Selectively copy out optval for setsockopt(2):
>
>    Pro: no change to SCTP code.
>    Con: Breaks standard API. Need small change to all other protocols.

I don't like breaking the API, or changing the other protocols. Too intrusive.

>  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.

We could use ioctl instead too :-)

>  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.

Perhaps map it into ioctl, instead? Ioctl, the swiss knife syscall.

christos