NGINX Dynamic Modules

[Andrew Hutchings]

Hi Jeff,

That is an interesting point about the signatures and something I can 
discuss internally.

I have an alternative idea specifically for ngx_pagespeed. I'll contact 
you off-list about it in the next 24 hours.

Kind Regards
Andrew

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
> 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
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>

-- 
Andrew Hutchings (LinuxJedi)
Technical Product Manager, NGINX Inc.