devfs
[Top] [All Lists]

Re: changing shared objects

To: Borsenkow Andrej <Andrej.Borsenkow@xxxxxxxxxxxxxx>
Subject: Re: changing shared objects
From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Date: Thu, 23 May 2002 11:32:58 -0600
Cc: Russell Coker <russell@xxxxxxxxxxxx>, devfs@xxxxxxxxxxx
In-reply-to: <1021052500.2925.12.camel@xxxxxxxxxxxxxxxxxxxxx>
References: <20020510113548.1007F3283@xxxxxxxxxxxxxxxxx> <200205101551.g4AFpxv12075@xxxxxxxxxxxxxxxxxxxxxxxx> <1021052500.2925.12.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
Borsenkow Andrej writes:
> ÷ ðÔÎ, 10.05.2002, × 19:51, Richard Gooch ÎÁÐÉÓÁÌ:

Please fix your mailer to format the above line in English.

> > 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.

No, dlopen(3) is called from get_shared_object(), which in turn is
called from process_config_line(). It's not done during event
processing. Thus, the name of the object to load is not recorded
anywhere. That saves space in the config_entry_struct,

RTFS :-)

> > - 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

Fine.

> 2. Check mtime on every call into shared object and reparse it

Fine too. Not my problem. It's actually cheap to do.

> 3. Reload shared object.

Send SIGUSR to devfsd.

> I intended to do 2 but forgot :-) 3 is better as it avoids overhead.

Yep. Send SIGUSR1 to devfsd.

> 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.

Why do you think it's messy? I have no problem with defining a cleanup
symbol that is called for shared objects that want to maintain state.
If the cleanup symbol isn't there, it doesn't get called. Easy.

> Really I do not think restarting devfsd is as bad.

Your choice.

> 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?

No, because there really isn't a good way of distinguishing between
stuff created by drivers and stuff created from user-space when
scanning. That information is only available when processing events
coming from devfs.

                                Regards,

                                        Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current:   rgooch@xxxxxxxxxxxxxxx

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