[lkml]   [2007]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: early_printk accessing __log_buf
On Wed, 18 Jul 2007 19:39:46 -0400
Robin Getz <> 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:
> - 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-19 02:29    [W:0.052 / U:40.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site