Re: [PATCH] Generic dead function optimisation

From: Andi Kleen (
Date: Tue Apr 25 2000 - 05:50:20 EST

Olaf Titz <> writes:

> > > static int do_something(void) {...}
> > > EXPORT_SYMBOL(do_something);
> > I would prefer that such a case be perfect illegal..
> Seconded.
> > It violates the Principle of Least Surprise
> Not only that, it violates longstanding C semantics.
> "static" => "can not be referenced outside this compilation unit"
> "EXPORT_SYMBOL" => "can be referenced outside this compilation unit"
> It's simply a contradiction.

The kernel just uses it everywhere.

Things like that are very common all over the kernel (call it poor man's
C++ classes):

struct bla_ops {
        void (*funca)(struct bla *, int arg);
        void (*funcb)(struct bla *, int arg);

struct bla {
        struct bla_ops *b_ops;

static void my_funca(struct bla *, int arg)

static void my_funcb(struct bla *, int arg)

static struct bla_ops my_bla_ops = {
        funca: my_funca,
        funcb, my_funcb

struct bla *alloc_bla(void)
        struct bla *b = kmalloc(sizeof(struct bla), GFP_KERNEL);
        b->b_ops = &my_bla_ops;
        return b;

funca and funcb can be called from outside the module. They are still
declared static. If you trust static to mean ``cannot be called from outside''
you'll quickly fall flat onto your face.
Overall you want a flat name space anyways, to make tools like cscope or
[ce]tags work, so it is a good idea to use explicit bla_* prefixes anyways.
With that static is rather useless for most cases (except special
hacks like putting local symbols via macros into ELF segments etc.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST