> > > 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/