httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: another naming question
Date Fri, 26 Dec 1997 19:09:39 GMT
On Fri, 26 Dec 1997, Alexei Kosut wrote:

> I get the impression that we're talking at each other, and not listening.

No, I just didn't understand why you thought ordinals were critical.  As
Ben mentioned ordinals can be controlled.

> Now, as I said, it is technically feasible to make DLLs load by name
> instead of number, although I don't know exactly how, and you've said
> Unixes import symbols by name. So that would be all right, I guess.
> Although it still precludes the ability to do this:
> 
> if (apache_api_version >= 19981201)
>     some_new_function();
> else
>     some_old_function();

Actually it doesn't prevent this completely.  If you look at, say, the
linux syscall table (which is essentially a bunch of ordinals) you'll find
various syscalls which are "old" or deprecated.  But they're still in the
table and contain the code necessary to munge arguments to call the new
version of the syscall.  Essentially each syscall has an implicit version
-- the version you use depends on what you linked against.

For us, if we wanted to change the parameters to an API call in a
backwards non-compatible way we could do this:

#define ap_foo ap_foo_v2
extern void ap_foo(args args args);

Then all new modules would be compiled referencing ap_foo_v2.  Old modules
would still reference ap_foo.  We'd need to provide definitions of both
ap_foo and ap_foo_v2 somewhere.  It could even be the case that ap_foo takes
an old version of a structure.

The issue then becomes how to write code that uses both old and new
functions...  The only way to do that which I can think of is to provide
a "shim" library that contains nop functions for all the new functions.
It would be a library containing ap_foo_v2 (it can be shared or static)
which did nothing.  You would have to load it as well as loading the
newer modules...

So you have all this in memory:

    apache_core_version_1997xxyy	an old executable
    apache_shim_version_19981201	a do-nothing shim
    3rd_party_module

There's more options probably, but we get into some differences between
what win32 and what unix dynamic linking provide.  For example I believe
it's possible on some unixes to have symbols in a .so which don't resolve.
In that case you don't need the shim.  It may be possible to do this on
win32 as well.

Or we could just declare that such modules have to use indirect function
calls and set up their symtable.  I don't mind if we say that this is
an option.  But I really want to be able to compile my server statically
without the need for any indirect calls.  I think we can satisfy both
of our needs with careful studying of linking on win32, linux, freebsd,
and solaris.  (That covers the major platforms for web serving.)

Dean


Mime
View raw message