httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: another naming question
Date Sun, 28 Dec 1997 14:57:53 GMT
Alexei Kosut wrote:
> If everyone else but me thinks that having modules only
> be source-compatible between different versions of Apache, I guess I can
> live with that. But it seems like the wrong thing to do.

I've been staying out of this discussion until now, but I guess the time has
come for me to weigh in.  I don't want to be considered one of the
'everyone' to whom Alexei is referring. <g>

No, I don't think source-only compatibility is the way to go.  We are using
a time-honoured mechanism to check binary compatibility: the MMN.  Months
ago, someone opined that modules should be able to check against this
value for (test_mmn <= MODULE_MAGIC_NUMBER), and someone leapt on them
with both feet saying a module was BROKEN if it wasn't checking against
specific values.  I don't think I said anything at the time, but I'm
saying it now: I consider that position (only specific values) WRONG.
Compatibility checks *should* be possible on a less-than-or-equal basis.

I've had a lot of experience with one OS' implementation of this mechanism.
I'll probably be laughed off the list, but that OS is OpenVMS - a very,
very stable and robust development and production platform.  OpenVMS
uses a similar sort of compatibility mechanism for checking against
shared-library routines.  It's broken into major/minor portions, though,
which I think might be a good idea for us to consider.  OpenVMS has
a lot of disadvantages, but one plus in this case is that this compatibility
checking is built into the system itself.  When you link an executable,
the linker records the MMN-equivalents of all the shared libraries
involved.  When you try to run the executable later, the system performs
the check and won't even run it if there's a mismatch - and it tells
you which library is either older than what you linked against, or
too new (major version++).  At library build-time, you can even tell the
linker that versions should always match, match only if exactly equal
(major and minor), or match if the run-time library's version is >= that
recorded in the executable for the link-time library.  The MMN, and
the compatibility rules for it, are attached to the library, not the
thing linking against it.  There are some rules that must be followed
when building a library for upward compatibility, of course - mostly
involving only adding new functionality at the end of the transfer

Sorry, got carried away.  To sum up:

 o I'm in favour of upward binary compatibility.
 o I think the API version should be considered a spectrum, not a set
   of discrete points, for purposes of compatibility checking.
 o I think run-time MMN checking functions should be available to modules.

How this is accomplished I don't really care.  Alexei's table-lookup solution
is semi-elegant; I can't speak to the performance issues, but if that
implementation will suck performance wind, we need to find another.  The
OpenVMS solution involves load-time function pointer rewrites, which we
can't do because we're not an operating system.  (OpenVMS executables
in memory bear only a passing resemblance to their disk appearances.)
Maybe an API call-through routine, like ap_api(func-code, vararg...)?
(Yggh.  I think this was already proposed, too.  OpenVMS does this for
some things that can't be rewritten at load-time, like syscalls.)

{Sigh}  I Babylon again.  Binary compatibility HO!

#ken	P-)}

View raw message