From owner-freebsd-arch@FreeBSD.ORG Mon Jul 24 00:24:37 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84A816A4DA; Mon, 24 Jul 2006 00:24:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 557B243D49; Mon, 24 Jul 2006 00:24:37 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6O0OUSj019926; Sun, 23 Jul 2006 17:24:31 -0700 (PDT) Date: Mon, 24 Jul 2006 09:24:22 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20060723171734.K35186@fledge.watson.org> References: <20060723171734.K35186@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: sosend/soreceive consistency improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 00:24:38 -0000 At Sun, 23 Jul 2006 19:57:56 +0100 (BST), rwatson wrote: > Rather than continue in this "in between state", in which the > uio/mbuf chain sosend and soreceive are reached via the protocol > switch in each occurrence, I propose a change: sosend() and > soreceive() will now be the formal APIs for sending and receiveing > on sockets within the kernel, as is the case with many other so*() > functions, and they will perform the protocol switch dereference. > The existing functions are renamed to sosend_generic() and > soreceive_generic(), and in most cases are never referenced by > protocols since our protocol domain registration already uses > sosend() and soreceive() as the defaults today. The new code > strikes me as quite a bit more readable, and likely easier for > socket consumers to use. > > Any thoughts and/or objections? > Makes sense to me. Can we document these? That is, is there a man page in section 9 we could add these to? Later, George