httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: another naming question
Date Fri, 26 Dec 1997 09:01:58 GMT
On Thu, 25 Dec 1997, Alexei Kosut wrote:

> So? All I'm saying is that I want binary-compiled modules to still link
> and load if we add a function to the API!

Huh?  Why wouldn't it?   Adding a function to the "module calling the
core" part of the API doesn't change the linking/loading behaviour at all.

Are you referring to modules.c compilation issues?  This is trivial to
solve, and I posted a solution about three times over a year ago:
one parameter in modules.c should be the number of API phases in the
structure (or the size of the entire structure).  Then the http_request
code can build a function table with a few extra comparisons.

Alternately there's the registration method, which is easier/nicer.

But I really thought we were arguing about the "module calling core"
part of the API.

> They may link, but they don't run. Apache doesn't let them, but if it did,
> you'd get seg faults and bus errors (or the Win32 equivilent) up the
> wazoo. Because the structures' arrangements have changed, the functions
> are ordinally in different places, etc...

First of all, yes if we rearrange request_req then all hell breaks
loose, same with a bunch of other structures.  We generally don't
rearrange them, and we could put the effort into not rearranging them.
(Although if we're going that way I wouldn't mind one rearrangement to
make them cache friendly.)

If you want complete abstraction of structures then you need to make
a get_foo and set_foo routine for every single element.  That's makes
code look pretty ugly.  You essentially have to get rid of structs and
use opaque type handles everywhere... you're not programming in C then.

Secondly, I don't think you understand how linking happens.  Individual
object files don't give one whit where an external "foo" is.  They contain
relocation records so that no matter what offset foo appears at they
can reference it.  The linker fills in these offsets for statically
linked object files and libraries (the loader fills them in for shared

If we don't modify any of the structures, and we remove the
MODULE_MAGIC_NUMBER test from Apache then we have the binary compatibility
that you're asking for.

> If it can be done with something as complex as a whole operating system,
> why can't it happen for our nice little web server?

You'll notice that the operating system has a well defined interface and
when new functionality is added it is done in a way that doesn't affect
existing binary compatilibity.  To do this requires a little forsight
when designing the system in the first place, Apache lacks a little
(not a lot) in this area.  We just never put the effort into maintaining
binary compatibility.  There's essentially nothing stopping us from doing
it with the current API though.

But, do we want to go there?  Let me give you examples of binary
compatibility issues:

- The Solaris 256 FILE * bug.  Solaris libc uses an unsigned char in
the FILE * structure to store the file handle.  They can't make it an
unsigned short because it would break compatibility with essentially
all existing programs.  To maintain compatibility they would have to
maintain two libc's, one for old programs, one for new.  Sun probably
doesn't want to do either of these things for various logistical reasons.

- select() and FD_SETSIZE.  When the resolver from bind is built, it
embeds the constant FD_SETSIZE.  bind is the basis for essentially every
single libc resolver out there.  This essentially limits all programs
using name lookups to file descriptors < the pre-compiled FD_SETSIZE.
This is one of those "3rd party library" issues that ap_slack is designed
to work around.

I think we could commit to a major.minor policy for the API.  Modules
compiled for X.Y work for all X.Z where Z >= Y.  It's not unreasonable
to state that a module compiled for Apache 1.2.0 will work with all
Apache 1.2.x.


View raw message