The fix for bug #4916 makes it harder to enable the system to support dynamically updated module/symbol data. The scenarios involve probes on libraries or modules that are not yet loaded, and thus whose addresses cannot be sent to the module at initialization time. If there was a secure channel available to staprun (and if staprun stayed running, even if stapio was suspended), then staprun could inform the module that there was more probe target code coming online. Another scenario is probing a user program, but having the module anticipate needing a backtrace for everything - including some libraries not yet loaded. That library address data would have to be transmitted to the probe well after initialization.
I suggest that runtime should disable module_notifier until this bug is fixed, because it causes pointless warnings when loading other modules. http://sources.redhat.com/ml/systemtap/2007-q4/msg00065.html
This seems like a worsening idea now, and is discordant with the trend to upload unwind/symbol data at compile time. Maybe a need will materialize later.
I remember the discussion months ago about this and I fixed it. I did not realize there war a PR opened on it.
Fixed. 2007-10-12 Martin Hunt <hunt@redhat.com> Changes to separate the symbols from the command channel. * cap.c (init_cap): Add CAP_DAC_OVERRIDE. * staprun.h: Change init_ctl_channel prototype. * ctl.c (init_ctl_channel): Modify to open either a command or symbol channel. Use ".cmd" and ".symbols" as the new names. * mainloop.c (init_stapio): Call init_ctl_channel(0); * staprun.c (cleanup): Call stop_symbol_thread(). (main): Call start_symbol_thread(). * staprun_funcs.c (handle_symbols): Make a thread. (start_symbol_thread): New. (stop_symbol_thread): New.