Re: getsockopt(2)

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

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

Ok.

>
>>>  Selectively copy out optval for setsockopt(2):
>>
>>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.

So we don't want this. But it is starting to become the only viable option.

>>>  Add new syscall to read/write optval:
>
>It would be messy within the kernel to have to use setsockopt(2) to set
>them and ioctl(2) to get them.

Yes the asymmetry sucks... I meant use ioctl for both get and set then.

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

That can be done. You can pass a struct to it and the struct can contain
pointers... 

>>>  sctp_peeloff():
>>
>>Perhaps map it into ioctl, instead? Ioctl, the swiss knife syscall.
>
>I think this will work.

That's the easy part though.

christos