Re: Driver Model 2 Proposal - Linux Kernel Performance v Usability

[Tim Hockin <thockin@hockin.org>]

On Fri, Sep 12, 2003 at 04:51:35PM -0400, Timothy Miller wrote:
> Why?  Because there are some advantages to being able to say that this 
> one module can be dropped into any box running, for instance, 2.6.12 
> through 2.6.16, while the next module is used for 2.6.17 thru 2.6.22, etc.

There are a SLEW of options that make this hard.

CONFIG_SMP - spinlocks get compiled in or not

CONFIG_SPINLOCK_DEBUGGING - changes the size of a spinlock and the behavior
of spin_lock() and friend

All the HIGHMEM and various kernel/user split option - change the kernel
virtual addresses and offsets

And these are just a few.  The thing is, there isn't any way to catalog them
all, because at any point, someone can add a CONFIG_FOO_DEBUG which changes
the size of a struct foo and foo_op().  Then any module which uses a foo has
to ALSO have FOO_DEBUG on.  Modules and kernels must match up on ALL the
options (or at least, all the ones that cross the kernel-module boundary).

This actually bit me just last week.  I turn on spinlock debugging, and a
module Oopses.  I didn't recompile modules.

It sucks.  I agree.  Maybe there is an elegant way to checksum each
functional interface and each datatype and typedef and each argument to each
funtion and make it such that IFF they are all the same, the module will
load.  It's just not pretty.

-- 
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books.  Cause and effect,
or merely an ironic juxtaposition of unrelated facts?