Castor Fu wrote:
On Thu, 10 Nov 2005, Dave Anderson wrote:
>> I also did not feel comfortable accepting the extension-keyword
>> stuff. While I do recognize that it would be useful to be
>> able to dynamically determine what extension modules to load,
>> I don't feel the extend command should be encumbered with the
>> job, but rather such an implementation-specific chore should
>> be handled by an instance of extension library code.
>>
>> For that reason I exported both the load_extension() and
>> unload_extension() functions so that extension library code
>> could use them to in turn load other extension libraries.
>>
>> The call to load_extension() could be made from either the
>> _init() function or from an extension command. At those
>> points in time, the "first" extension library will have all
>> the information (kernel version, crash version, dumpfile,
>> etc.) at its disposal, and then can make the decision as to
>> what additional libraries to load.
Implementing this, I realized that the for this scheme to work,
if I want to access things like the crash version, the 'pc'
structure will have to remain the same. Perhaps a small
set of these functions can be exported to reduce the dependencies
of such a loader on defs.h?
The minimal expectation would be something which would export
pc->program_version
If pc->curcmd were exported, that would also remove dependencies
on calling cmd_usage.
I do try my best to not muck with the basic data structures, and if changed,
to add the new struff onto the end of the data structure, so even if a module
were built with an older version, its dependencies would still be in place.
And with respect to the program_context structure specifically, I cannot
even remember the last time that it changed. We can always put a
moratorium on the data structure to enforce the "only-add-to-the-end"
rule. Or if you feel it's necessary, come up with a mechanism for
exporting stuff generically for extensions, come up with something
that we can put in extensions.c.
Dave