cvs commit: src/lib/libc/net Makefile.inc sctp_sys_calls.c src/sys/sys param.h

[Randall Stewart]

Julian Elischer wrote:
> Craig Rodrigues wrote:
> 
>> On Fri, Dec 15, 2006 at 05:57:04AM -0800, Luigi Rizzo wrote:
>>
>>> i think Andre's question was this:
>>> normally we use {set|get}sockopt() to configure the socket
>>> as desired for special features (e.g. multicast is one).
>>>
>>> Why is it undesirable to use the same kind of overloading
>>> for sctp ?
>>
>>
>> I think some of the reasons for why a new sockets API
>> was introduced for SCTP was outlined in:
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-14.txt
> 
> 
> which says:
> --------------
> 8.  New Interfaces
> 
>    Depending on the system, the following interface can be implemented
>    as a system call or library function.
> ---------------
> The latter is what I'd expect..
> 
> syscalls is 'unusual' and unique to this protocol.
> 
> 
>>
>> ...but I'll let Randall chime in too. :)
>>
> 
There are only 4 new system calls..

a) sctp_generic_sendmsg()
b) sctp_generic_sendmsg_iov()
c) sctp_generic_recvmsg()
d) sctp_peeloff()

Peeloff is a lot like accept() .. it returns a new
socket. It could be move to a socket option petty
easily.. Michael Tuexen already did one for Apple :-)

a/b are the same in reality its just one accepts an
IOV which I anticipate will get added to the socket api
eventually.

In general a/b/c are there for efficency.. an app hits
these heavily.. and going through socket options OR
packing and unpacking CMSG structures (both in the
user land library and in the kernel) is a HUGE cpu
waste...

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)