NGINX Dynamic Modules
ahutchings at nginx.com
Tue Feb 9 20:29:07 UTC 2016
That is an interesting point about the signatures and something I can
I have an alternative idea specifically for ngx_pagespeed. I'll contact
you off-list about it in the next 24 hours.
On 09/02/16 18:45, Jeff Kaufman wrote:
> This is very exciting! Among other things, this should make it
> practical for distributions to package individual nginx modules
> 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 . That's a lot of binaries to
> 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
>  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:
>> 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
> nginx-devel mailing list
> nginx-devel at nginx.org
Andrew Hutchings (LinuxJedi)
Technical Product Manager, NGINX Inc.
More information about the nginx-devel