NGINX Dynamic Modules
mdounin at mdounin.ru
Tue Feb 9 23:39:46 UTC 2016
On Tue, Feb 09, 2016 at 01:45:46PM -0500, Jeff Kaufman wrote:
> This is very exciting! Among other things, this should make it
> practical for distributions to package individual nginx modules
That's the main task which is expected to be solved at this point,
> 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
Yes. We don't maintain a stable ABI between versions, and not
even API between mainline versions. So preparing different
binaries for different nginx versions is unavoidable for now.
As of now general idea is that it should be possible to compile
module that can be loaded into an nginx binary built on a
particular OS with particular configure arguments. That is, you
can prepare binaries targeting particular nginx distributions.
In the future we are likely to review and reduce number of various
options that change nginx internal structures and hence are
included in the signature. This should improve compatibility
between different builds.
> 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.
The idea of signatures and version checks is to make sure that
a module and nginx ideas about API structures agree. So running
against "many signatures" looks like a wrong idea, but see above
about reducing granularity of signatures.
We can also consider providing stable ABI in addition to API in
stable branches, but this probably don't make a lot of sense as
stable releases aren't happening often.
More information about the nginx-devel