[Crash-utility] Re: crash enhancements proposal

[Dave Anderson]

David Wilder wrote:

> Dave Anderson wrote:
>
> >Maneesh Soni wrote:
> >
> >
> >
> >>Hi Dave,
> >>
> >>Following is a list of a few proposed improvements to crash utility though
> >>for most of the items there are no names associated.
> >>
> >>Please let us know if these look useful or not. And if found appropriate
> >>would it be possible for you to merge these with the crash todo list.
> >>
> >>Thanks to Badari Pulavarty, Richard Moore and Vara Prasad for the inputs.
> >>
> >>
> >>
> >
> >
> >
> >>
> >>DESCRIPTION:
> >>    Code restructuring:
> >>    - move as much code for advanced commands to libraries so that
> >>      crash is at least able to open the dump image and perform minimal
> >>      set of commands like bt, dump dmesg log, disassemble etc. irrespective
> >>      of kernel version.
> >>    - code is hard to read & understand - need to re-write some of the
> >>      basic subsystems like memory mapping, pagetable management etc
> >>
> >>RESOLUTION STATUS:
> >>        Work-in-progress by Dave Wilder <dwilder at us.ibm.com> and
> >>        Maneesh Soni <maneesh at in.ibm.com>
> >>
> >>
> >>
> >
> >I don't quite understand how moving code to libraries is going to
> >achieve the goal here.  Things in some of the various *_init() functions
> >could certainly be streamlined (or skipped) in order to make it more
> >likely to make it to the first prompt.  For example, the task table initialization
> >could be made to simply fill in the context data for just the panic task.
> >(But it almost sounds like you just want to use gdb alone for the minimal
> >set of commands you've listed?)
> >
> >As far as "re-writes" are concerned, please keep in mind the
> >necessity of backwards-compatibility.  I'd much rather keep the current
> >code -- that's known to work -- in place, and if you come up with
> >something new, or re-shuffled, make it only callable when the kernel
> >is of a known kernel version or later.
> >
> >The point is, let's not just re-invent the wheel just for purpose of
> >re-inventing the wheel.
> >
> >
> >
> >
> A big advantage to this approach is the ability to have multiple
> libraries, one per per kernel  version, at minimum a crash library for
> each major kernel version 2.4, 2.6, 2.7..    This would preserve
> backward compatibility as we can leave all the 2.4 stuff  alone when
> adding code for the 2.7 kernel for example.   If a distro has special
> needs for crash they can provide a crash library specific to their kernel.
>

Of course over the life of 2.4 and 2.6 there have been major overhauls
in several areas w/respect to crash code paths that would make the
concept of a "2.4" or a "2.6" library impossible, or essentially not much
different than the way things are done now.

All I'm saying is that the last thing I want to have to do is "backwards
compatibility QA", especially within the constraints of having to satisfy
a distro, be it Red Hat or otherwise.  I can't justify changing things for the
sake of changing things.  However -- *going forward*, I think your idea has
a great deal of merit, although I'm still not sure how those "libaries" should be
best partitioned.


>
> If crash is designed so that some minimal analysis can be performed with
> out  a dependency on the crash library (look at the running  cpus back
> traces, read the log..)  then a service person can get started on a
> crash dump and determine if a library will be needed or if changes to
> the library are needed for the specific kernel.  Often you just need a
> little information from a dump to identify known problems in the kernel.
>

Makes sense.  Like I mentioned before, the number of things done
during initialization could be significantly streamlined, perhaps turned
on by a simple command line option.

Dave