linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Krause <minipli@googlemail.com>
To: Joe Perches <joe@perches.com>
Cc: David Daney <david.daney@cavium.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC PATCH 0/3] Mark literal strings in __init / __exit code
Date: Mon, 23 Jun 2014 08:29:49 +0200	[thread overview]
Message-ID: <CA+rthh8rGQX9pKUC3rGfaguQ+TVXqXqXuUiHzE6Ga0tQE1ch_A@mail.gmail.com> (raw)
In-Reply-To: <1403487015.18747.23.camel@joe-AO725>

On 23 June 2014 03:30, Joe Perches <joe@perches.com> wrote:
> 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.
>
> Another solution might be, as David Daney suggested, using
> gcc 4.5+ plug-ins to extract these format strings and
> const char * arrays into specific sections automatically.
>
> https://lkml.org/lkml/2009/7/21/483
>
> Seems feasible, but there might be a negative of string
> duplication in multiple sections that would otherwise
> be consolidated into a single object.
>

There is currently no infrastructure for gcc plugins in the kernel
tree. And using plugins might make the kernel even more depended on a
particular gcc version, as the plugin API changes with every version.
In fact, there is none, beside "use every exported function you can
get your hand on". And that API breaks with each and every new version
of gcc. This would put quite a bigger maintenance burden on such an
approach than providing appropriate wrappers, fixing the obvious
candidates and adding a checkpatch warning.

Thanks,
Mathias

      reply	other threads:[~2014-06-23  6:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-22 22:46 [RFC PATCH 0/3] Mark literal strings in __init / __exit code Mathias Krause
2014-06-22 22:46 ` [RFC PATCH 1/3] init.h: Add __init_str / __exit_str macros Mathias Krause
2014-06-24 19:43   ` Joe Perches
2014-06-24 20:13     ` Mathias Krause
2014-06-22 22:46 ` [RFC PATCH 2/3] printk: Provide pi_<level> / pe_<level> macros for __init / __exit code Mathias Krause
2014-06-22 22:46 ` [RFC PATCH 3/3] x86, acpi: Mark __init strings as such Mathias Krause
2014-06-22 22:56 ` [RFC PATCH 0/3] Mark literal strings in __init / __exit code Joe Perches
2014-06-23  6:23   ` Mathias Krause
2014-06-23  6:33     ` Joe Perches
2014-06-24 14:31       ` Rasmus Villemoes
2014-06-24 19:13         ` Mathias Krause
2014-06-24 19:37           ` Joe Perches
2014-06-24 20:10             ` Mathias Krause
2014-06-24 20:30               ` Joe Perches
2014-06-24 20:41                 ` Mathias Krause
2014-06-24 20:57                   ` Joe Perches
2014-06-24 21:06                     ` Mathias Krause
2014-06-24 21:45                       ` Joe Perches
2014-06-25  5:55                         ` Mathias Krause
2014-06-25  7:35                           ` Rasmus Villemoes
2014-06-25  7:48                             ` Joe Perches
2014-06-25  8:34                               ` Mathias Krause
2014-06-25 11:22                                 ` Joe Perches
2014-06-25  8:17                             ` Mathias Krause
2014-06-23  1:30 ` Joe Perches
2014-06-23  6:29   ` Mathias Krause [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+rthh8rGQX9pKUC3rGfaguQ+TVXqXqXuUiHzE6Ga0tQE1ch_A@mail.gmail.com \
    --to=minipli@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david.daney@cavium.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).