Re: [Fastboot] Re: [PATCH 19/29] x86_64-kexec

[ebiederm@xmission.com (Eric W. Biederman)]

Adrian Bunk <bunk@stusta.de> writes:

> On Wed, Jan 19, 2005 at 12:31:37AM -0700, Eric W. Biederman wrote:
> >...
> > ---
> linux-2.6.11-rc1-mm1-nokexec-x86_64-machine_shutdown/arch/x86_64/kernel/crash.c
> Wed Dec 31 17:00:00 1969
> 
> > +++ linux-2.6.11-rc1-mm1-nokexec-x86_64-kexec/arch/x86_64/kernel/crash.c Tue
> Jan 18 23:14:06 2005
> 
> >...
> > +note_buf_t crash_notes[NR_CPUS];
> >...
> 
> After your patches, this global variable stays completely unused
> on x86_64 (for the i386 version, you added a usage).
>
> cu
> Adrian
> 
> BTW: Is external usage for crash_notes planned, or can it become static 
>      on both architectures?

A sharp eye.  That array is a key part of an ongoing conversation.

To analyze why a kernel crashed you need some information, beyond
simply the contents of memory at the time of the crash.

If that information is not static and obtainable at the time of the crash
machine_crash_shutdown() needs to capture that information.  

For the format of the information that crashed we can either use some
random structure, that you need to know to read kernel debug information
to interpret.  Or we can use a standard format, reducing the need
for magic in the interpretation process.  The introduction of
crash_notes is the first step is switching to using a standard format,
for the data to remove unnecessary dependencies between a kernel
and the tools that analyze it after it has crashed.

crash_notes is designed to be a set of per cpu buffers that hold
information captured just after a kernel has crashed.  So the usage
is expected to be very external.  How we communicate the address of
these per cpu buffers to analysis tools still needs to be addressed.
/proc/kallsyms?

As for internal users those will come when machine_crash_shutdown
becomes more than a noop on x86_64.

Eric