From owner-cvs-all@FreeBSD.ORG Mon Jun 14 19:46:36 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD8B16A4CF; Mon, 14 Jun 2004 19:46:36 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 149C643D45; Mon, 14 Jun 2004 19:46:36 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B9D5B5C83F; Mon, 14 Jun 2004 12:46:13 -0700 (PDT) Date: Mon, 14 Jun 2004 12:46:13 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20040614194613.GI61448@elvis.mu.org> References: <20040614190209.GE61448@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c uipc_socket.c uipc_syscalls.c uipc_usrreq.c src/sys/net raw_cb.c raw_usrreq.c src/sys/netatm atm_socket.c src/sys/netatalk ddp_pcb.c src/sys/netgraph ng_ksocket.c src/sys/netgraph/bluetooth/socket ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 19:46:36 -0000 * Robert Watson [040614 12:24] wrote: > > We chose to maintain the existing naming scheme for sockets present in the > code since it's origins in BSD, and consistent with other BSD platforms. > Otherwise, I generally agree :-). Given the volume of other changes going > in here, I was reluctant to introduce non-functional changes in order to > ease merging. Once we have the basic version of locking in place, we will > have the opportunity to revisit this (and a great many other things). > > One thing I should point out, though, is that the reference counting in > sockets isn't a simple reference count, since in addition to so_count, > there's also a flag indicating whether a file descriptor reference is > present, and an un-counted reference from the pcb to the socket, which is > also considered "real". The various > sofree()/sotryfree()/sorele()/soref()/.. APIs reflect this complexity, > and hence some inconsistency with a more simple API. Thank you, I am familiar with SS_NOFDREF. :( -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684