Re: getsockopt(2)

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

christos%astron.com@localhost (Christos Zoulas) wrote:
>In article <x7lgi6uze1.fsf%ren.fdy2.co.uk@localhost>,
>Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>>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.

There are about 40 options defined by SCTP. I would need to go through
the list to see how many of them were of which type.

There isn't any source shared between FreeBSD and NetBSD anymore, their
stack has diverged a lot from KAME.

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

I'm not really in favour of this myself, I was just listing all the
alternatives.

>>  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 :-)

I would need to check which options are defined to work with
setsockopt(2).

It would be messy within the kernel to have to use setsockopt(2) to set
them and ioctl(2) to get them.

One possible problem is that some of them are defined as taking variable
sized arguments, are there other ioctl(2) requests that do this ?

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

I think this will work.