devfs
[Top] [All Lists]

Re: changing shared objects

To: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: changing shared objects
From: Russell Coker <russell@xxxxxxxxxxxx>
Date: Sat, 11 May 2002 10:03:41 +1000
Cc: devfs@xxxxxxxxxxx
In-reply-to: <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca>
References: <20020510113548.1007F3283@lyta.coker.com.au> <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca>
Reply-to: Russell Coker <russell@xxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
On Sat, 11 May 2002 01:51, Richard Gooch wrote:
> > I think that there should be a way to tell devfsd to unload shared
> > objects from CFUNCTION/MFUNCTION entries and reload them.  This
> > would allow me to replace the shared object with a new version
> > without requiring that devfsd be restarted.
> >
> > I know that the devfsd would need to be restarted if I was trying to
> > fix a serious bug in the module (IE memory corruption), but for
> > minor issues (changing logging messages or adding new functions) it
> > should not be necessary to stop and restart devfsd entirely IMHO.
>
> So you're not even happy with sending SIGHUP to devfsd? What's the
> harm in doing that?
>
> While I could define another signal to reload shared objects, there
> are a number of things I don't like about that:
> - code bloat
> - consumes yet another signal
> - requires struct shared_object to record the path to the library
> - code bloat.
>
> And besides that, it would require more code. Oh, and did I mention
> code bloat? Unless you can show me why this feature is so much better
> than just sending SIGHUP, I'm reluctant to add code to do this.

SIGHUP didn't seem to do it last time I checked.  I'll test again next month.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

<Prev in Thread] Current Thread [Next in Thread>