Re: [RFC] Sectionized printk data

[Arnaldo Carvalho de Melo]

Em Sat, Feb 09, 2008 at 11:08:45PM +0100, Jan Engelhardt escreveu:
> 
> On Feb 4 2008 19:07, Sam Ravnborg wrote:
> >> The attached patch allows something along the lines:
> >> 
> >> int __init some_function(void)
> >> {
> >>         [...]
> >>         pr_init(KERN_WARNING "failure %s in %s\n", ...);
> >>         [...]
> >> }
> >> 
> >> Another idea I had was to make printk a macro that figures out the
> >> section of the surrounding function and then moves the data
> >> automatically when it is a literal, but I couldn't find mechanisms that
> >> allow this.  Anyone of you got an idea?
> >> 
> >> What do you think in general?
> >
> >What is the rationale behind this?
> 
> To drop strings that are only shown once anyway, such as:
> 
> static int __init ebtables_init(void)
> {
>         int ret;
> 
>         mutex_lock(&ebt_mutex);
>         list_add(&ebt_standard_target.list, &ebt_targets);
>         mutex_unlock(&ebt_mutex);
>         if ((ret = nf_register_sockopt(&ebt_sockopts)) < 0)
>                 return ret;
> 
> ->      printk(KERN_INFO "Ebtables v2.0 registered\n");
>         return 0;
> }
> 
> >If you say "saving memory" then please let us know with specific examples
> >in what area these savings will really pay off.

A long time ago I played with this, using a sparse based tool that was
inserted as the compiler and modified the code before passing to gcc,
i.e. a pre-pre-processor:

http://www.kernel.org/pub/linux/kernel/people/acme/sparse/initstr.c

I couldn't find in the archives, but IIRC some extra pages were freed
after boot, i.e. strings moved from .data to .init.data.

With a tool like this the advantage is that no source code has to be
changed, strings in __init functions are automagically moved to
.init.data, the disadvantage is that not all strings can be moved to
.init.data as there were (are?) subsystems that keep pointers to the
string passed and another tool would be involved in the build process.

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