From: Andrew Morton <akpm@linux-foundation.org>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: early_printk accessing __log_buf
Date: Wed, 18 Jul 2007 17:26:03 -0700 [thread overview]
Message-ID: <20070718172603.231351ea.akpm@linux-foundation.org> (raw)
In-Reply-To: <200707181939.46910.rgetz@blackfin.uclinux.org>
On Wed, 18 Jul 2007 19:39:46 -0400
Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Wed 18 Jul 2007 18:16, Andrew Morton pondered:
> >
> > I'd suggest that any interface into here should be via function calls,
> > not via direct access to printk internals: think up some nice
> > copy_me_some_of_the_log_buffer() interface.
>
> If so - I would still like to put it in:
> - ifdef CONFIG_EARLY_PRINTK
> - and define as __init
>
> so that people don't use it when they shouldn't (when the kernel is up an
> running).
>
> Something simple like - early_copy_log_buff(void *dest, size_t n)
>
> copies n bytes from log_buf to memory area dest. Returns number of bytes that
> could not be copied. Can find out how many bytes are in the log_buff by
> calling with zero size.
>
> This is not destructive to existing interfaces (log_start and con_start are
> not updated/used). This should ensure that if booting does work - that normal
> messages come out the standard method.
>
> Any other suggestions?
>
When I was at $EARLIER_EMPLOYER, we had code in there to copy the last
kilobyte-odd of the log buffer into flash when the box oopsed.
So there's one instance proof that something more general would be needed.
Probably there are others, but they'll mainly be in the consumer/embedded
area, and those sorts of engineers don't read this mailing list much.
next prev parent reply other threads:[~2007-07-19 0:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 21:56 early_printk accessing __log_buf Robin Getz
2007-07-18 22:16 ` Andrew Morton
2007-07-18 23:39 ` Robin Getz
2007-07-18 23:53 ` Mike Frysinger
2007-07-19 3:37 ` Robin Getz
2007-07-19 3:47 ` Andrew Morton
2007-07-19 0:26 ` Andrew Morton [this message]
2007-07-19 2:26 ` Stephane Couture
2007-07-19 3:58 ` Robin Getz
2007-07-22 23:50 ` Mike Frysinger
2007-07-23 0:14 ` Paul Mundt
2007-07-23 18:19 ` Robin Getz
2007-07-23 20:15 ` Andrew Morton
2007-07-23 20:54 ` Mike Frysinger
2007-07-23 21:05 ` Andrew Morton
2007-07-23 22:10 ` Mike Frysinger
2007-07-23 22:15 ` Robin Getz
2007-07-23 22:34 ` Andrew Morton
2007-07-24 17:50 ` Robin Getz
2007-07-24 18:12 ` Andrew Morton
2007-07-24 20:12 ` Robin Getz
2007-07-24 21:30 ` Andrew Morton
2007-07-31 7:47 ` Mike Frysinger
2007-07-31 7:59 ` Bryan Wu
2007-07-31 8:11 ` Mike Frysinger
2007-07-31 18:36 ` 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=20070718172603.231351ea.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox