On 31/10/2013 6:04 p.m., Alex Rousskov wrote:
On 10/30/2013 10:28 PM, Amos Jeffries wrote:
On 31/10/2013 1:16 p.m., Alex Rousskov wrote:
Hello,
The attached patch upgrades Squid to libecap v1.0, allowing
asynchronous (e.g., threaded) eCAP adapters and eCAP version checks.
After these changes, Squid can support eCAP adapters built with libecap
v1.0, but stops supporting adapters built with earlier libecap versions
(due to libecap API changes). The new libecap version allows Squid to
better check the version of the eCAP adapter being loaded as well as the
version of the eCAP library being used. This should help with migration
to libecap v1.0.
Does this new library version support break backward compatibility with
building Squid against libecap 0.2.x ?
Yes, patched Squid cannot work with libecap v0.x or libecap v1.1 (if
that is what you are asking). If I am not answering your question,
please rephrase.
Why is explicit module library version checking being pushed into Squid
itself? does not the library ABI versioning handle backward-compatibility?
Sorry, I do not know what it means for "the library ABI versioning" to
"handle backward-compatibility", but I know that patched Squid cannot
work with libecap v0.x or libecap v1.1, so I adjusted Squid ./configure
check accordingly. Or are you asking about something else?
As I understand library design the library version N should be offering
the same ABI symbols from library N-1 and as far back N-x as possible.
Such that software like Squid built against library N-1 can still load
adapters built against N or N+1 onwards as far as possible.
This should not require any changes in Squid itself. But only in the
library internals.
I am checking whether the library 1.0/1.1 versions are supported like
this because most of our downstream distributions will need to release
packages of newer libecap library before releasing version of Squid with
these changes. Having a forced in-sync step between the library and
proxy will cause transition problems for them. If we can make Squid
still build and/or run against the older libraries it would be helpful
avoiding problems there.
Please keep in mind that there can be are up to 2+N libecap versions
that Squid needs to deal with, where N is the number of eCAP adapters:
(1) libecap Squid was built with
+
(1) libecap Squid is running with
+
(N) libecap adapters were built with.
It is possible to configure "Squid built with libecap v1.0" to load an
"adapter built with libecap v0.2". I ran many tests like that. Old
Squids would crash and burn in similar version mismatch cases. With this
patch, Squid warns the admin about the adapter version mismatch and
either exits or runs OK, depending on squid.conf IIRC (but Squid may
still crash and burn on exit when global library destructors are called
-- nothing we can do about that AFAIK).
Okay. So Squid configured in such a way that the library calls only use
0.2 API symbols still works. Good.
What then is blocking Squid from supporting build against either 0.2 or
1.0 library version?
We have feature-detection possible in configure.ac and #if macros to
build in/out support code based on those results. It sounds to me like
the library gobal destructors need to be better protected internally
from crashing, but that is an ecap problem.
The important thing is that if we apply this today our releases of Squid
will still need to build on systems only supplying libecap 0.2.
Its not a blocker, but if you could find a way to allow build against
those old library versions as well as the new ones it would be helpful.
... now on to the audit.
Amos
