From owner-cvs-src@FreeBSD.ORG Tue Oct 19 22:19:21 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2901416A4CF for ; Tue, 19 Oct 2004 22:19:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8D4143D41 for ; Tue, 19 Oct 2004 22:19:20 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9JMJAKf083088; Tue, 19 Oct 2004 18:19:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9JMJAQa083085; Tue, 19 Oct 2004 18:19:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 19 Oct 2004 18:19:10 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <41759110.6010005@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Sam Leffler cc: Max Laier Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 19 Oct 2004 22:19:21 -0000 On Tue, 19 Oct 2004, Julian Elischer wrote: > >>Another point: If you really want to keep the possibility to remove a > >>protocol, you have to introduce some busy counter that pervents removal while > >>the kernel is inside a protocol function. This has to be handled by the > >>protocol itself, but it has to be taken care of somehow. > > each protocol array entry could have either a mutex or a refcount or > both.. The trick here is to get just enough synchronization to not break, but not enough to hurt. That's one of the reasons why I feel like the heavier weight approaches taken elsewhere may not be appropriate here. I guess no one is talking about loading UDP, but at the same time if we're going to have generic loadable protocol support, it would be nice to get a pretty clean API that would meet the requirements of higher volume protocols. As I mentioned in a previous e-mail, it might almost be desirable to say "no unloading" and simply avoid the hard problems, since atomic add is easy whereas atomic remove is hard. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research