lkml.org 
[lkml]   [2009]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH, RFC] panic-note: Annotation from user space for panics
Tim Bird <tim.bird@am.sony.com> writes:

> Eric W. Biederman wrote:
>> Matt Mackall <mpm@selenic.com> writes:
>>
>>> As much as I like kexec, it loses on memory footprint by about 100x.
>>> It's not appropriate for all use cases, especially things like
>>> consumer-grade wireless access points and phones.
>>
>> In general I agree. The cost of a second kernel and initrd can be
>> prohibitive in the smallest systems, and if you do a crash capture
>> with using a standalone app that is reinventing the wheel.
>>
>> That said. I can happily run kdump with only 16M-20M reserved.
>> So on many systems the cost is affordable.
>
> Understood. On some of my systems, the memory budget for the
> entire system is 10M. On most systems I work with, it is a
> struggle to reserve even 64K for this feature.

crash_kexec is really a glorified jump. It is possible to do a lot in
64K with a standalone application. If reliable capture of kernel
crashes is desirable to an embedded NAND device I expect a semi-general
purpose dedicated application for capturing at least dmesg from the
crashed kernel and write it to a file on a NAND filesystem could be
worth someones time.

On general purpose hardware we use a kernel and an initrd simply to
reduce the development work of supporting everything and the kitchen
sink. My impression is that embedded systems can afford a little more
setup time, and a custom compilation, and that the hardware you would like
to store things too is much more common.

Eric



\
 
 \ /
  Last update: 2009-11-18 19:19    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog