[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 apache.org 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. -dean
