On Sun, Jul 01, 2007 at 03:05:35PM +0100, Andrew Doran wrote:
> 
> I've been making some more general changes to the callouts which I'm going
> to check in shortly. The first is to hide the callout implementation from
> the user, so we can have a stable ABI/API for LKMs. I initially wanted to do
> that by having the callout structures dynamically allocated.

Dynamic allocation is a PITA, you either:
a) run out
b) have to be able to sleep when starting a callout
c) forgre to free them and leak memory.

> That would
> require a fairly massive set of changes to device drivers to handle the new
> semantics (e.g., callout_init() can fail, callouts must be destroyed). I'm
> also cognizant of the fact that external allocation means more cache
> pressure. So what I have done is to have the callers provide a fixed block,
> which should leave plenty of room for expansion:
> 
> typedef struct callout {
>         void    *_c_store[12];
> } callout_t;

I don't think you need that much space...
 
> We could be clever about it and allocate callouts on a strictly as-needed
> basis, but that means returning more to a simple API more like the original
> timeout/untimeout.

Acually you could force LKMs to malloc callout table entries - so the
static kernel code wouldn't suffer.

I've been trying to think of a way of stopping LKMs using some headers files.

One idea is to declare a global constant symbol with value zero in the
header file (all 'non-LKM' headers would define the same value).
The kernel itself would link (because the symbols all have the same value),
but then you run objcopy (or something) to change the value of the symbol
to a randmon(ish) number.
LKMs wouldn't have the correct value for the symbol - so wouldn't load.

This would mean sorting out the public and private/internal parts of
some header files.

	David

-- 
David Laight: david@l8s.co.uk