From owner-cvs-all@FreeBSD.ORG Tue Oct 19 22:30:30 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 B9E3E16A4CE for ; Tue, 19 Oct 2004 22:30:30 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF33743D46 for ; Tue, 19 Oct 2004 22:30:29 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 62729 invoked from network); 19 Oct 2004 22:29:25 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2004 22:29:25 -0000 Message-ID: <41759589.B2EE8BA9@freebsd.org> Date: Wed, 20 Oct 2004 00:30:33 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Julian Elischer 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-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: Tue, 19 Oct 2004 22:30:30 -0000 Robert Watson wrote: > > 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. No no. Even unloading high volume protocols is not that difficult. When giant protects the manipulations of the protosw[] we can be certain that no new requests will come in for the unregistered protocol. What we are not certain about is whether there still is some previous process inside our functions. But this is something the protocol has to deal with. There is no general solution as there are so many different protocols doing so many different things. In general a protocol that wants to unload first has to stop any new sockets from popping up (from above and below) and then it has to properly close/clear/shutdown all existing sockets. Once this is done it can unregister itself and proceed with unloading. This whole thing is not as bleak as some might think it is. :-) And unloading TCP through a SSH session is certainly not recommended. ;-) -- Andre