Re: configure options for loadable Squid modules

Alex Rousskov wrote:
> On Fri, 2007-10-12 at 16:14 +0200, Henrik Nordstrom wrote:
>> On tor, 2007-10-11 at 19:30 -0600, Alex Rousskov wrote:
>>> 2) --enable-external-modules :: This option will enable support for
>>> modules loaded runtime, from external files. There are two reasons to
>>> have it: to disable experimental code and to build "secure" Squids that
>>> cannot be altered by loading modules. Are these reasons enough to have
>>> this option?
>> I would make it a --disable-module-loading option..
>
> ... implying that module support will be enabled by default? OK.
>
>>> 3) --enable-builtin-modules :: This option will allow the modules to
>>> be preloaded at Squid executable linking time. Preloaded modules
>>> simplify handling of Squid binaries because there is no dependency on
>>> some external module file and no dangers that the external module will
>>> not load. Should this option be named --enable-internal-modules or
>>> --enable-preloaded-modules or even --with-preloaded-modules?
>> All our modules should by default be builtin, with squid.conf settings
>> for adjusting their use. Don't see the need for this option.
>
> Interesting. Why do you think that the majority of modules are going to
> be built in? A built-in (a.k.a., preloaded) module Foo requires
> relinking Squid executable with the "-dlopen Foo.la" option, right? Do
> you think most users would prefer to relink (which requires Squid
> libraries and a linker) than simply install a module and change
> squid.conf?

I think you are both looking at this in isolation. It is not an
all-or-nothing situation.

squid has these types of modules:
  1) built by default AND enabled and working by default (HTTP, ICP, etc)

- I think these should all be built-in by default and pre-linked.

  2) built by default AND disabled by default (SNMP, etc)

- I think these should be packaged as loadable modules with the main
squid binary by default.

Henriks request for --disable-module-loading implies they would be
loaded dynamically anyway, but as with now, not used unless turned on in
squid.conf.

  3) require ./configure AND enabling in squid.conf

- should be left as loadable modules, not built by default, but if user
./configure'd they be built as (2).

  4) future third-party modules

- would always be loaded dynamically.

People who want a plain vanilla squid will get all the modules, but
never have to worry about the loading-failed problems with the default
ones. A very slight chance of linking problems with advanced configs
using non-defaults, and their choice if they get to decide
built-in/loadable when using ./configure.

Any policy changes like turning one on or linking by default should be
made per-module at the same time as deciding whether anything is
experimental / stable / deprecated in the squid version.

>
> Finally, if we only have the --disable-module-loading option, would it
> be better to call it --disable-modules? That is, have one knob that
> controls whether _any_ modules (preloaded or dynamic) are supported?

A bad concept comes to mind. Whats left if squid is entirely modules and
they are turned off?

>
> If --disable-modules is a bad idea (e.g., because we may call a
> compiled-in Squid feature a "module"), how about
> --disable-loadable-modules?

Means the same thing as what Henrik suggested but with less-intuitive
wording methinks.

Side thought:
   This whole discussion lends itself to provide a good name for Adrians
earlier requested new directory 'modules'. As all the new modulised code
with good copyright tracks gets made into modules it goes in there.
   Makes it clear its the modulised code and sticks with the naming
scheme started with /helpers/ and /tools/ and /tests/

Amos
Received on Fri Oct 12 2007 - 23:33:51 MDT