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(a)us.ibm.com> and
>> Maneesh Soni <maneesh(a)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