From: Andrew Morton <akpm@linux-foundation.org>
To: Andy Whitcroft <apw@shadowen.org>
Cc: David Brownell <david-b@pacbell.net>,
pavel@suse.cz, linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, mingo@elte.hu
Subject: Re: [PATCH] add a printk_init variant storing format strings in __initdata
Date: Wed, 4 Jun 2008 01:16:07 -0700 [thread overview]
Message-ID: <20080604011607.15dec5a7.akpm@linux-foundation.org> (raw)
In-Reply-To: <1212485252.0@pinky>
On Tue, 3 Jun 2008 10:27:32 +0100 Andy Whitcroft <apw@shadowen.org> wrote:
>
> [As gcc seems unable to help us out selecting the appropriate data segment
> for the code, how about we did something like this?]
>
> When using printk from __init functions it would be desirable to place
> the printk format strings in __initdata. Add a printk_init() variant
> which does this.
>
> This printk_init() is necessarily a #define so that we can declare the
> format string in static scope and mark it __initdata. We then call a
> newly introduced __printk_init() variant which is identicle to printk() but
> marked __init itself. By ensuring that an __init variant of printk is used
> we get proper section violation warnings when this is used incorrectly:
>
> WARNING: vmlinux.o(.text+0x3): Section mismatch in reference from the
> function something() to the variable .init.data:__printk_init_fmt.31426
> The function something() references
> the variable __initdata __printk_init_fmt.31426.
> This is often because something lacks a __initdata
> annotation or the annotation of __printk_init_fmt.31426 is wrong.
>
> Note I have followed printk's pattern for __cold annotations.
>
Ho hum. This give everyone another way in which to bury everyone else
with patches.
Wouldn't it be great if checkpatch were to detect
fail-to-use-printk_init() in an __init function?
oh, speaking of checkpatch: please use it :)
> ---
> include/linux/kernel.h | 10 ++++++++++
> kernel/printk.c | 12 ++++++++++++
> 2 files changed, 22 insertions(+), 0 deletions(-)
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 792bf0a..7754196 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -180,6 +180,13 @@ struct pid;
> extern struct pid *session_of_pgrp(struct pid *pgrp);
>
> #ifdef CONFIG_PRINTK
> +#define printk_init(fmt, args...) \
> +do { \
> + static char __printk_init_fmt[] __initdata = fmt; \
> + __printk_init(__printk_init_fmt, ##args); \
> +} while (0)
> +asmlinkage int __printk_init(const char * fmt, ...)
> + __attribute__ ((format (printf, 1, 2))) __cold;
> asmlinkage int vprintk(const char *fmt, va_list args)
> __attribute__ ((format (printf, 1, 0)));
> asmlinkage int printk(const char * fmt, ...)
> @@ -196,6 +203,9 @@ extern int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst);
> extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
> unsigned int interval_msec);
> #else
> +asmlinkage int printk_init(const char * fmt, ...)
> + __attribute__ ((format (printf, 1, 2))) __cold;
> +static inline int __cold printk_init(const char *s, ...) { return 0; }
> static inline int vprintk(const char *s, va_list args)
> __attribute__ ((format (printf, 1, 0)));
> static inline int vprintk(const char *s, va_list args) { return 0; }
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 8fb01c3..992a5c0 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -616,6 +616,18 @@ asmlinkage int printk(const char *fmt, ...)
> return r;
> }
>
> +asmlinkage __init int __printk_init(const char *fmt, ...)
> +{
> + va_list args;
> + int r;
> +
> + va_start(args, fmt);
> + r = vprintk(fmt, args);
> + va_end(args);
> +
> + return r;
> +}
We're going to want to be able to call printk_init() from modules.
Please fix and test that, if we decide to proceed.
Oh, and we're going to need printk_meminit() and printk_cpuinit() and
whatever.
Which probably means that __printk_init() can't be __init, unless all
the CONFIG_ settings which control __cpuinit, __meminit etc are blowing
in the right direction.
It would be good if we could get some idea of the savings here, because
boy this is going to be a pain.
next prev parent reply other threads:[~2008-06-04 8:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-29 20:33 [patch 2.6.26-rc4-git] PM: boot time suspend selftest David Brownell
2008-05-29 21:01 ` Rafael J. Wysocki
2008-05-29 21:26 ` David Brownell
2008-05-29 21:29 ` Rafael J. Wysocki
2008-05-29 23:06 ` Andrew Morton
2008-05-30 4:34 ` David Brownell
2008-05-29 23:22 ` Andrew Morton
2008-05-30 10:59 ` Ingo Molnar
2008-05-30 19:04 ` Andrew Morton
2008-06-03 9:27 ` [PATCH] add a printk_init variant storing format strings in __initdata Andy Whitcroft
2008-06-03 16:41 ` Johannes Weiner
2008-06-03 17:49 ` [linux-pm] " Johannes Berg
2008-06-04 8:16 ` Andrew Morton [this message]
2008-06-04 8:32 ` MinChan Kim
2008-06-04 8:59 ` David Woodhouse
2008-06-04 9:10 ` [linux-pm] " Johannes Berg
2008-06-04 9:17 ` David Woodhouse
2008-06-04 10:51 ` Johannes Berg
2008-06-04 11:43 ` Alan Cox
2008-06-04 8:56 ` David Woodhouse
2008-06-03 10:45 ` [patch 2.6.26-rc4-git] PM: boot time suspend selftest Andy Whitcroft
2008-07-07 4:12 ` David Brownell
2008-07-23 8:19 ` Andrew Morton
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=20080604011607.15dec5a7.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mingo@elte.hu \
--cc=pavel@suse.cz \
/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