Re: [PATCHv3 0/9] Mark literal strings in __init / __exit code

Ingo Molnar
2014-08-22T08:25:08Z

* Mathias Krause <minipli@googlemail.com> wrote:

> > It feels like a burdensome hack that kernel developers are
> > forced to use different printing facilities, depending on
> > the life cycle of a method. We want to simplify init
> > annotations, we don't want to complicate them!
>
> Does this:
>
> pi_info("mkiss: AX.25 Multikiss, Hans Albas PE1AYX\n");
>
> really look more complicated compared to this?:
>
> static const char banner[] __initconst = KERN_INFO \
> "mkiss: AX.25 Multikiss, Hans Albas PE1AYX\n";
> printk(banner);
>
> The latter can be found in drivers/net/hamradio/mkiss.c. Aged
> code, admitted. But we have a few more of those and the
> pi_info() looks way more appealing to me by doing the very
> same thing ;)

My point is that both are complicated, compared to using the
regular printk() variants.

In general printk()s should not be aware of what function
context they are in.

> > And if tooling isn't ready for this, then wouldn't the
> > right solution be to improve tooling - instead of
> > complicating the kernel?
>
> Plugin based approaches for this have been mentioned before
> but those suffer from the same "global view" problem. So,
> IMHO it's not that easy to solve it at the toolchain level.

It might be solved via a regular tooling feature, or via
tooling extension based on plugins.

Regardless of how it's implemented on the tooling side, my
point remains: this kind of optimization is done on the tooling
side in a natural fashion, while it's an ongoing maintenance
concern on the kernel side.

So it should be done on the tooling side, especially as the
benefits appear to be marginal.

Thanks,

Ingo