tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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.

FreeBSD has 32 options that require an input parameter to be able to
get them, we don't implement all of them yet.

There are only a couple of options that are really new socket
operations, they are used to implement the sctp_connectx() function
described in the lkml thread. They copy in an array of sockaddr structs
and return a uint32_t.

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

What is wrong with your idea of updatesockopt(2) ? Or maybe call it
getsockopt2() and only use it for the "get with extra argument" case.

All the calls to it would be hidden in the userland SCTP library
functions.

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

The API defined in RFC 6458 only provides an alternative function to
"get" options, to set them you have to use setsockopt(2), it isn't
possible to avoid the asymmetry.

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

I found an example to copy in sys/dev/ic/ath.c.

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

I have done this bit. Not tested yet as it needs the other stuff.



Home | Main Index | Thread Index | Old Index