cvs commit: src/sys/sys protosw.h src/sys/kern
uipc_domain.cuipc_socket2.c
Andre Oppermann
andre at freebsd.org
Tue Oct 19 15:30:30 PDT 2004
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
More information about the cvs-src
mailing list