From owner-cvs-src@FreeBSD.ORG Fri Dec 15 23:57:08 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAD8E16A403; Fri, 15 Dec 2006 23:57:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBB443CBA; Fri, 15 Dec 2006 23:55:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4F7CA46C6C; Fri, 15 Dec 2006 18:57:01 -0500 (EST) Date: Fri, 15 Dec 2006 23:57:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randall Stewart In-Reply-To: <45831767.1080908@cisco.com> Message-ID: <20061215235407.H72986@fledge.watson.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , src-committers@FreeBSD.org, Julian Elischer , 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 23:57:09 -0000 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