httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: mod_custom_log exits too late?
Date Thu, 26 Sep 2002 23:55:47 GMT
[a little birdie said folks were quoting me ;)  hi!]

On 16 Sep 2002, Brian Pane wrote:

> Linux kernel modules are a special case due to some characteristics
> that don't apply to Apache:
> * Most Linux kernel modules are available in source form

most are available in source form simply because source is the only form
in which compatibility is remotely guaranteed.  and also because the l-k
folks (rightly) refuse to support any bug reports from folks with binary
modules linked into their kernel.

note that linux modules are not covered by GPL -- it *is* possible to
release a binary only module, and some vendors attempt it.  but the
typical reaction by linux users is to avoid the hardware which requires
binary only modules.

> * All modules are well-integrated with the kernel's build system

not even close.  try building a kernel with pcmcia, i2c, lm_sensors,
freeswan, ... it's just as painful as trying to build apache with anything
more complicated than "cp mod_foobar.c src/modules/extra".

> * Most Linux installations have the necessary tools for recompilation

from which it follows that most apache installations have the necessary
compilation tools... (do i have to go dig out the old netcraft apache/os
distribution statistics? :)

> Those things aren't generally true for Apache modules.  If you're
> running on a Solaris box with no compiler, with binary-only modules
> from third party vendors, and the next release of Apache 2.0
> increments the MMN major, then you're stuck.

yeah well if you don't have the compiler then you can't even compile
the next apache-2.0 :)  stop providing binary downloads at
and this "problem" goes away as well.  :)

even solaris boxes come with gcc as of 8/9 don't they?

> A better example is the Linux system call interface: that almost
> never breaks backward compatibility, and that's what allows users
> to upgrade their kernels to a new maintenance release without fear
> of breaking every app they depend on.

the linux system call interface is *not* an analogous interface to the
apache module API.

system calls, for example, cross a protection domain which is largely
enforced by the CPU hardware.  (but which requires special tests in every
system call to ensure hax0rs aren't attacking ring 0).

this userlevel/kernel separation is a very fundamental layering... which
apache does not have -- and which i think apache would be better off
having... but it's a fundamental paradigm shift.

if you wanted an analogous API for apache then you'd need to use IPC
or RPC to provide inter-module protection using multiple processes.
this is something i've mentioned before as well -- it eliminates linkage
issues; segfault issues; ... to design such an IPC/RPC you'd have to
put as much effort into the fundamental design of the API as goes into
system call design.

that's not to say system calls never change -- you need only look
through the linux system call table to see several new replacements
for old system calls.  glibc tends to provide a layer of indirection
so that old code continues to work as the syscalls change.  glibc even
provides parameter/structure marshalling so that changes can be made in
kernel-side structures without affecting user programs that depend on
structure layouts.

(this is the case in essentially every unix, linux is just the example
at hand.  for a solaris example look at the crappy solaris 2.5 TCP over
STREAMs implementation...  prior to 2.5 and after 2.5 TCP syscalls exist,
but in 2.5 they're library routines which make STREAMS syscalls.)

trust me:  you're doing a huge disservice to the advancement of the state
of the art by locking yourselves into a binary compatibility mentality.

i can't see any benefit to binary compatibility except in allowing
corporate vendors to hide their intellectual property -- and not share
it with the community at large (an effort which we should all be aware
is fundamentally worthless -- since reverse engineering can and does
happen every day, and is even a personal right in reasonable countries
in this world).  and as a (retired) apache contributor i find that not
only weak, but in fact a non-argument.  there is no technology worth
protecting like this.  if the vendor wants to benefit from all this free
IP they're getting from us, then they should at least give a minor amount
of effort back.

apache isn't GPL -- if vendors want binary crap, then they can make a real
C binary library, and provide an apache layer similar to the libc layer i
described above for syscalls.  6 years ago a vendor wanted WiReD to link
a proprietary binary auditing module into their httpd, and i refused.
i refused until the vendor gave me a C library and a simple wrapper i
could use to rebuild my server with.  the vendor agreed, and we all were
happy in the end.


View raw message