Date: Fri, 15 Dec 2006 23:57:01 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Randall Stewart <rrs@cisco.com> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, src-committers@FreeBSD.org, Julian Elischer <julian@elischer.org>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/net Makefile.inc sctp_sys_calls.c src/sys/sys param.h Message-ID: <20061215235407.H72986@fledge.watson.org> In-Reply-To: <45831767.1080908@cisco.com> References: <200612151201.kBFC1qEv006825@repoman.freebsd.org> <4582A1E0.1050503@freebsd.org> <4582A6C9.8010009@FreeBSD.org> <20061215055704.A65183@xorpc.icir.org> <20061215145655.GA13912@crodrigues.org> <4582FC91.2030205@elischer.org> <45831767.1080908@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Dec 2006, Randall Stewart wrote: > 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 > :-) I'd really rather we didn't try to fit these sorts of things into socket options myself: the current blend of system calls and socket options for the new interfaces appears right to me. Especially with respect to in-kernel consumers of socket interfaces, having the socket option code make assumptions about file descriptor arrays on the current process, etc, would not be the right thing. Socket options work well for simple get/set interfaces, but going too much further is just asking for trouble. It also makes handling issues like binary compatibility for ABI changes a lot more tricky: we have a mature mechanism for handling versioning of system calls, but not for socket options. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061215235407.H72986>