From: akpm@linux-foundation.org (Andrew Morton)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] kernel, logbuf: add support for external log buffer
Date: Tue, 24 Jul 2012 16:55:02 -0700 [thread overview]
Message-ID: <20120724165502.17de8e13.akpm@linux-foundation.org> (raw)
In-Reply-To: <1339395188-10166-1-git-send-email-hs@denx.de>
On Mon, 11 Jun 2012 08:13:08 +0200
Heiko Schocher <hs@denx.de> wrote:
> This merges support for the previously DENX-only kernel
> feature of specifying an alternative, "external" buffer
> for kernel printk messages and their associated metadata.
> This patch is based on DENX-only kernel commit:
>
> commit 212f61c7fd3b952a81d1459dd32a86a32ddfd4ce
> Author: Igor Lisitsin <igor@emcraft.com>
> Date: Wed Apr 18 14:55:19 2007 +0400
>
> Add support for external log buffer.
>
> Add support for external log buffer, for example passed by U-Boot,
> which may already contain messages (from the boot loader and/or POST).
>
> Signed-off-by: Igor Lisitsin <igor@emcraft.com>
>
> see:
> http://git.denx.de/?p=linux-denx.git;a=commit;h=212f61c7fd3b952a81d1459dd32a86a32ddfd4ce
>
> When this option is enabled, an architecture- or machine-specific log
> buffer is used for all printk messages. This allows entities such as
> boot loaders (e.g. U-Boot) to place printk-compatible messages into
> this buffer and for the kernel to coalesce them with its normal
> messages. This patch support this feature for arch/arm based
> boards.
Why was it done this way, rather than adding a hook to permit
architectures to insert data into the head of the existing kernel
buffer?
The latter approach would be quite simple, wouldn't it? A single line
added to printk.c which calls an arch function which locates the boot
loader buffer and prints it, with printk. And this is more flexible -
for example, there might be more than one external message stream
which we wish to capture.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Heiko Schocher <hs@denx.de>
Cc: linux-arm-kernel@lists.infradead.org,
Igor Lisitsin <igor@emcraft.com>, Wolfgang Denk <wd@denx.de>,
Grant Erickson <gerickson@nuovations.com>,
linux-kernel@vger.kernel.org, Tim Bird <tim.bird@am.sony.com>,
CE Linux Developers List <celinux-dev@lists.celinuxforum.org>,
Kay Sievers <kay@vrfy.org>
Subject: Re: [RFC] kernel, logbuf: add support for external log buffer
Date: Tue, 24 Jul 2012 16:55:02 -0700 [thread overview]
Message-ID: <20120724165502.17de8e13.akpm@linux-foundation.org> (raw)
In-Reply-To: <1339395188-10166-1-git-send-email-hs@denx.de>
On Mon, 11 Jun 2012 08:13:08 +0200
Heiko Schocher <hs@denx.de> wrote:
> This merges support for the previously DENX-only kernel
> feature of specifying an alternative, "external" buffer
> for kernel printk messages and their associated metadata.
> This patch is based on DENX-only kernel commit:
>
> commit 212f61c7fd3b952a81d1459dd32a86a32ddfd4ce
> Author: Igor Lisitsin <igor@emcraft.com>
> Date: Wed Apr 18 14:55:19 2007 +0400
>
> Add support for external log buffer.
>
> Add support for external log buffer, for example passed by U-Boot,
> which may already contain messages (from the boot loader and/or POST).
>
> Signed-off-by: Igor Lisitsin <igor@emcraft.com>
>
> see:
> http://git.denx.de/?p=linux-denx.git;a=commit;h=212f61c7fd3b952a81d1459dd32a86a32ddfd4ce
>
> When this option is enabled, an architecture- or machine-specific log
> buffer is used for all printk messages. This allows entities such as
> boot loaders (e.g. U-Boot) to place printk-compatible messages into
> this buffer and for the kernel to coalesce them with its normal
> messages. This patch support this feature for arch/arm based
> boards.
Why was it done this way, rather than adding a hook to permit
architectures to insert data into the head of the existing kernel
buffer?
The latter approach would be quite simple, wouldn't it? A single line
added to printk.c which calls an arch function which locates the boot
loader buffer and prints it, with printk. And this is more flexible -
for example, there might be more than one external message stream
which we wish to capture.
next prev parent reply other threads:[~2012-07-24 23:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 6:13 [RFC] kernel, logbuf: add support for external log buffer Heiko Schocher
2012-06-11 6:13 ` Heiko Schocher
2012-07-11 9:08 ` Heiko Schocher
2012-07-11 9:08 ` Heiko Schocher
2012-07-24 23:55 ` Andrew Morton [this message]
2012-07-24 23:55 ` 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=20120724165502.17de8e13.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.