generic modules review please

Hi,
    Well I've done the first easy part of the generic modules goal: made the registration framework for modules common across fs &
repl & auth.

Before I go any further I'd like to check that I am going in a direction you folk agree with, (not in general - we discussed that)
but in specifics.

The tag modules_round1 on sourceforge's CVS will let you see the patch for the work to date. It's not complete (mod_register_dump
is missing it's guts for one thing). (I have read through it though.)

I've added a squid.conf option module
mod_register internal | external modulename
that is used to register modules. The registered module gets it's mod_install_$(modulename) function called at that point, and a
matching uninstall function called when the configure entry is called. (They don't have to uninstall, but if they can, they should.)

There is no "register all internal modules now" capability, although it's trivial to put one in: for me its better to know that the
(say) heap code, while compiled in, is not even present as far as the store is concerned unless I deliberately have mod_register
internal heap.

Q: Should I put such an _option_ in (mod_register internal all) and have that as the default ?

Secondly the namespace is flat. This makes naming modules harder, and some of the current ones (all actually :] ) unclear as to
their purpose for new users. On the upside adding runtime linked modules will be much easier in this layout.

Q: is it worth, or even a good idea to move all the existing fs/repl/auth directories under "modules"

Thirdly, I want to move the bulk of the parse, free & dump code from cache_cf to libmisc. I think all the generic parse_int,
parse_string, parse_wordlist stuff shouldn't be in main squid code, as it is useful for modules to use to parse their own options.
Type specific parse/free/dump code should be where the type is defined and used, and I plan to come back to that when modular config
options happens - round 2? round 3? :]

Q: does this approach make sense?

And lastly,
the existing module specific Add code uses arrays that get realloc'd. I'd like to switch these over to linked lists so that
eventually fs modules & repl modules & auth modules can be unloaded, or at least made no-longer-available on reconfigure (and
silently unload when all references disappear).

Q: Good/bad? Are there gotchas I have to watch out for. (ie will memory use for the in memory index double or something weird like
that :] )

Rob
Received on Thu Feb 15 2001 - 16:07:20 MST