В Птн, 10.05.2002, в 19:51, Richard Gooch написал:
> Russell Coker writes:
> > 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
Why? The only thing that needs to be done is to dlclose() handle and
free shared_object. It will be reloaded on next access.
> - 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.
>
One example is pam_console_etc shared object. It parses
/etc/security/console.perms. When this file is changed (by user or as
result of RPM update) you have three alternatives:
1. Do nothing and let sysadmin manually restart devfsd
2. Check mtime on every call into shared object and reparse it
3. Reload shared object.
I intended to do 2 but forgot :-) 3 is better as it avoids overhead.
Of course the main problem is, shared object must be prepared to be
unloaded. It must free any allocated memory it may have. I am not aware
how to do it automatically - it means, it has to export some cleanup
function and devfsd needs to call it ... now _that_ tends to become
messy and too error prone.
Really I do not think restarting devfsd is as bad.
Oh, and it reminds me. When devfsd comes up (or as result of HUP) it
generates synthetic REGISTER events. Unfortunately it generates it for
_every_ single name it finds under /dev - including those that has never
been actually registered. Mandrake even includes code that is based on
this buggy assumption and works only because devfsd gets HUP during
startup.
Is there any chance to restrict those synthetic REGISTERs only to
actually registered nodes?
-andrej
|