public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Tim Bird <tim.bird@am.sony.com>
Cc: Matt Mackall <mpm@selenic.com>,
	David VomLehn <dvomlehn@cisco.com>,
	"dedekind1\@gmail.com" <dedekind1@gmail.com>,
	Marco Stornelli <marco.stornelli@gmail.com>,
	Simon Kagstrom <simon.kagstrom@netinsight.net>,
	"linux-embedded\@vger.kernel.org"
	<linux-embedded@vger.kernel.org>,
	"akpm\@linux-foundation.org" <akpm@linux-foundation.org>,
	"dwm2\@infradead.org" <dwm2@infradead.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"paul.gortmaker\@windriver.com" <paul.gortmaker@windriver.com>
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics
Date: Wed, 18 Nov 2009 10:16:28 -0800	[thread overview]
Message-ID: <m1iqd77l6r.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B043467.8000708@am.sony.com> (Tim Bird's message of "Wed\, 18 Nov 2009 09\:52\:39 -0800")

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


  reply	other threads:[~2009-11-18 18:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12  2:13 [PATCH, RFC] panic-note: Annotation from user space for panics David VomLehn
2009-11-12 18:00 ` Marco Stornelli
2009-11-12 21:56   ` David VomLehn
2009-11-13  8:10     ` Simon Kagstrom
2009-11-13 11:45       ` Artem Bityutskiy
2009-11-13 11:59         ` Simon Kagstrom
2009-11-13 14:16           ` Artem Bityutskiy
2009-11-14  8:28         ` Marco Stornelli
2009-11-17  8:53           ` Artem Bityutskiy
2009-11-17 12:45             ` Marco Stornelli
2009-11-17 13:10               ` Artem Bityutskiy
2009-11-17 15:45                 ` Eric W. Biederman
2009-11-17 23:56                   ` David VomLehn
2009-11-18  0:28                     ` Eric W. Biederman
2009-11-18  0:53                       ` David VomLehn
2009-11-18  9:01                         ` Américo Wang
2009-11-18 17:01                         ` Eric W. Biederman
2009-11-18  0:56                       ` Matt Mackall
2009-11-18 16:07                         ` Eric W. Biederman
2009-11-18 17:52                           ` Tim Bird
2009-11-18 18:16                             ` Eric W. Biederman [this message]
2009-11-18  8:26                   ` Artem Bityutskiy
2009-11-17 17:53                 ` Marco Stornelli
2009-11-12 18:06 ` Matt Mackall
2009-11-12 21:58   ` David VomLehn
2009-11-13 11:35   ` Artem Bityutskiy
2009-11-12 19:50 ` Paul Gortmaker
2009-11-12 22:09   ` David VomLehn
2009-11-13 11:50     ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-11-13 11:26 ` Artem Bityutskiy
2009-11-17  9:03 ` Artem Bityutskiy

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=m1iqd77l6r.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=dedekind1@gmail.com \
    --cc=dvomlehn@cisco.com \
    --cc=dwm2@infradead.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.stornelli@gmail.com \
    --cc=mpm@selenic.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=simon.kagstrom@netinsight.net \
    --cc=tim.bird@am.sony.com \
    /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