lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 9 Feb 2008 21:54:33 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Johannes Weiner <hannes@...urebad.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Sectionized printk data

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ