lkml.org 
[lkml]   [2014]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHv3 0/9] Mark literal strings in __init / __exit code
From
Date
On Sun, 2014-08-24 at 18:04 +0200, Mathias Krause wrote:
> On 21 August 2014 18:25, Sam Ravnborg <sam@ravnborg.org> wrote:
> > So is it really worth it?
>
> I took the hacky script mentioned in the first email (now also
> attached, init_str.awk), let it ran over the whole kernel, fixed the
> fall-out and did an allmodconfig build. Beside the script being far
> from perfect (it catches a few false positives and, more important,
> only covers a fraction of the potential strings -- only the pr_*()
> macros) it already leads to 24 modules requiring a page less during
> run-time because of the afore mentioned page crossing. It includes
> popular modules like hid.ko and ipv6.ko, so almost anybody would
> benefit from it. But as the page crossing effect depends on the
> particular kernel configuration and toolchain setup, fell free to do
> your own tests. The script doing the measurement is attached, too
> (mod_info.sh)

I think it would be worth it.

I think the added complexity converting:
printk/pr_<level>
to
pi_<level>/pe_<level>
for init/exit sections is a lightweight, one-time cost and
continuing upstream maintainer involvement is next to nil.

This mechanism supports all existing compiler toolchains.

Updating toolchains and or using a gcc compiler plugin
means that extra work would also need to be done for llvm
and any other alternate compiler.

And, as Mathias mentioned, the string deduplication logic
may be somewhat complicated for each compiler.

The worst that happens if a printk is added that is not
written as pi_<level> is some unnecessary .text is consumed.

No doubt someone will every so often run Mathias' scripts
against the kernel tree and submit the odd patch to fix it
up.




\
 
 \ /
  Last update: 2014-08-24 18:41    [W:0.059 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site