John-Mark Gurney wrote:
>
> Andre Oppermann wrote this message on Tue, Oct 19, 2004 at 17:39 +0200:
> > > > Modified files:
> > > > sys/sys protosw.h
> > > > sys/kern uipc_domain.c uipc_socket2.c
> > > > Log:
> > > > Support for dynamically loadable and unloadable protocols within existing protocol
> > > > families.
> > > >
> > >
> > > I don't recall seeing this posted anywhere for comment. I have some
> > > concerns about this general topic and this code seems incomplete (e.g. I
> > > see no locking).
> >
> > Locking is not needed because there are no dead moments in transitioning
> > from unregistered to registered and back. All calls to any of the protocol
> > specific functions will return a valid result (even if it is only EOPNOTSUPP).
> > There is no list manipulation going on.
> >
> > The caller of the function is required to assure that no dangeling sockets,
> > references or memory allocations are left behind after unregistering. It's
> > simply impossible to solve otherwise. For IPDIVERT which I have converted
> > this works very well (it will simply refuse to unload if a divert socket is
> > open).
> >
> > What remaining concerns do you have?
>
> I don't see any GIANT_REQUIRE, or locking around adding a new protocol..
> This means there could be a race where two modules loading a protocol
> get assigned the same slot...
Ok, that makes sense. Luckily loading protocols is a relatively rare
occourence and highly unlikely to bite anyone soon. I'll add the giant
lock just to be sure as you suggest though.
> I had to do this with the kqueue subsystem when dynamicly loading
> filters...
I'll have a look how you solved it there.
--
Andre