Date: Wed, 20 Oct 2004 00:30:33 +0200 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Max Laier <max@love2party.net> Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c Message-ID: <41759589.B2EE8BA9@freebsd.org> References: <Pine.NEB.3.96L.1041019181643.81058G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41759589.B2EE8BA9>