cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c

[Andre Oppermann]

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