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

[Ingo Molnar]

* Mathias Krause <minipli@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/