Tim Bird writes:
> Eric W. Biederman wrote:
>> Matt Mackall 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 acce
David VomLehn writes:
>> > 2. Where would you suggest tying in? (Particularly since not all
>> > architectures
>> >currently support kdump)
>>
>> No changes are needed kernel side. You just need an appropriate kernel and
>> initrd for your purpose.
>
> I think I must still be missing somet
Matt Mackall 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 s
David VomLehn writes:
> On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> ...
>> Why not use the kdump hook? If you handle a kernel panic that way
>> you get enhanced reliability and full user space support. All in a hook
>> that is already present an
Artem Bityutskiy writes:
> On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
>> 2009/11/17 Artem Bityutskiy :
>> > Take a look at my mails where I describe different complications we have
>> > in our system. We really want to have an OOPS/panic + our environment
>> > stuff to go together,
David VomLehn writes:
> On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
> ...
>> This is what made us suggest the presentation driven approach. We can
>> send people who understand how the kernel development process out
>> anointed as embedded maintainers. However, looking at t
