Re: [PATCH] Generic dead function optimisation

From: Andi Kleen (ak@suse.de)
Date: Tue Apr 25 2000 - 05:50:20 EST


Olaf Titz <olaf@bigred.inka.de> 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.)

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



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