On Sun, Jul 22, 2007 at 07:50:47PM -0400, Mike Frysinger wrote:
> On 7/18/07, Robin Getz <[email protected]> wrote:
> >On Wed 18 Jul 2007 20:26, Andrew Morton pondered:
> >> Robin Getz wrote:
> >> > [need to access _log_buf from external for early debugging code]
> >> >
> >> > 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.
> >>
> >> 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.
> >>
> >
> >Hmm - I think that if you call with NULL dest, and have it advance the
> >pointer, you could do the same thing with something like:
> >
> > /* see how many bytes are in the buff */
> > length = early_copy_log_buff(NULL, NULL);
> > /* advance the pointer, so we only copy the last 1k */
> > if (length >= 1024 )
> > left = early_copy_log_buff(NULL, length - 1024);
> > /* copy to temp buffer, to save to flash */
> > early_copy_log_buff(buff, 1024);
> > save_buff_to_flash(buff);
> >
> >That way - you can put this in the standard places for failure, and still
> >have
> >only one function polluting printk.c (Although if you want to use it for
> >failure trapping - it's up for "normal" run time use, and doesn't go into
> >__init.
> >
> >> 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.
> >
> >Adding a few more 'embedded' folks - who might have some thoughts/opinions.
>
> i think the attached two functions account for what Robin and Andrew
> were thinking ...
I don't have any strong opinions on this one way or the other. We've been
playing more with kexec for a recovery mode, that coupled with the crash
dumps gives us most of the state we need. We would probably make use of
this printk log access functionality if it were added, though, depending
on customer environments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
