In article <[email protected]>, Robert Swindells <[email protected]> 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
