On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote: > This RFC series tries to address the problem of dangling strings of > __init functions after initialization, as well as __exit strings for > code not even included in the final kernel image. The code might get > freed, but the format strings are not. > > One solution to the problem might be to declare variables in the code > and mark those variables as __initconst. That, though, makes the code > ugly, as can be seen, e.g., in drivers/hwmon/w83627ehf.c -- a pile of > 'static const char[] __initconst' lines just for the pr_info() call. > > To be able to mark strings easily patch 1 adds macros to init.h to do so > without the need to explicitly define variables in the code. Internally > it'll declare ones nonetheless, as this seem to be the only way to > attach an __attribute__() to a verbatim string. That's already enough to > solve the problem -- mark the corresponding stings by using these > macros. But patch 2 adds some syntactical sugar for the most popular use > case, by providing pr_<level> alike macros, namely pi_<level> for __init > code and pe_<level> for __exit code. This hides the use of the marker > macros behind the commonly known printing functions -- with just a > single character changed. > > Patch 3 exemplarily changes all strings and format strings in > arch/x86/kernel/acpi/boot.c to use the new macros. It also addresses a > few styling issues, though. But this already leads to ~1.7 kB of r/o > data moved to the .init.rodata section, marking it for release after > init. > > > Open issues with this approach: > > 1/ When CONFIG_DYNAMIC_DEBUG is enabled, pi_debug() and pe_debug() > fall-back to pr_debug() as there is currently no way of removing the > dynamic entries from the dynamic debug code after init. > > 2/ The variables used in the macros of patch 1 will pollute the symtab > with unneeded entries. That'll be a problem in the KALLSYMS_ALL case > only, though. But the symtab will be huge then, anyway. However, > filtering those even in this case might be desirable. > > 3/ It only seamlessly integrates for the pr_<level>() kind of use cases. > For other literal strings it gets slightly less readable, e.g. this: > > strncmp(str, "s4_nohwsig", 10) > > becomes this: > > strncmp(str, __init_str("s4_nohwsig"), 10) > > That might be okay, though, as it marks the string clearly as an init > string, so might actually increase the understanding of the life time of > the string literal. > > > So, is there interest in having such macros and markings? Patch 3 shows, > that there's actual value in it. A hacked up script, dully changing > pr_<level> to pi_<level> for __init functions under arch/x86/ already is > able to move ~8kB of r/o data into the .init section. The script, > though, is dump. It does not handle any of the printk() calls, nor does > it handle panic() calls or other strings used only in initialization > code. So there's more to squeeze out. I just want to get some feedback > first. > > Also documentation of the new macros is missing, maybe even a > checkpatch.pl change to propose using the new macros instead of pr_*() > or plain printk() in __init / __exit functions. > > What do you think?
I once proposed a similar thing. https://lkml.org/lkml/2009/7/21/421 Matt Mackall replied https://lkml.org/lkml/2009/7/21/463 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/