NGINX Dynamic Modules

Jeff Kaufman jefftk at google.com
Tue Feb 9 18:45:46 UTC 2016


This is very exciting!  Among other things, this should make it
practical for distributions to package individual nginx modules
separately.

We've been looking at whether this would let us offer a precompiled
ngx_pagespeed module, though, and it looks to me like this might be
pretty tricky?  In order to load a module, it looks like it has to
have been compiled for that specific point release of nginx and with a
matching signature?  So we would need to make binaries for 1.9.11,
1.9.12, 1.9.13 etc and for each of those we would need to make ones
for each of the common signatures [1].  That's a lot of binaries to
prepare!

Have you been thinking about any way that a module could be built to
run against many versions of nginx, and many signatures, if it doesn't
touch pieces of nginx that differ?  With Apache, for example, we
prepare 32 bit and 64 bit binaries for the 2.2 series and the 2.4
series (so 4 binaries).  This works because we're calling into an ABI
that Apache is committed to keep the same, but there might be some
other way that would work better for nginx.

Jeff Kaufman
PageSpeed TL

[1] With there being 33 bits in the signature, we're not going to be
preparing 2^33 modules for each nginx release, but there are probably
common patterns of build-time feature availability.

On Tue, Feb 9, 2016 at 9:41 AM, Andrew Hutchings <ahutchings at nginx.com> wrote:
> Hi all,
>
> As you may have seen with recent code drops, we have released the initial
> version of our Dynamic Modules code to the source tree and NGINX 1.9.11.
> This initial release will allow you to compile modules with NGINX as before,
> but can create shared object files at the same time as the NGINX binary.
> These shared objects can then be loaded and unloaded at runtime.
>
> If you have any modules which you wish to use with this new feature they
> will need a little work to convert them. Specifically the way the ‘config’
> file is written has changed. Although we have maintained compatibility with
> the static compilation of modules so if you do not wish to convert a module
> then you won’t have to change anything. Details on the new format and how to
> convert the modules can be found at:
>
> https://www.nginx.com/resources/wiki/extending/
>
> In addition we are working on fully documenting the module API with
> examples.  This will come at a later date.
>
> If you have any questions or problems converting modules please let us know
> on this mailing list.
>
> Kind Regards
> --
> Andrew Hutchings (LinuxJedi)
> Technical Product Manager, NGINX Inc.
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



More information about the nginx-devel mailing list