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@xxxxxxxxxx> and > >> Maneesh Soni <maneesh@xxxxxxxxxx> > >> > >> > >> > > > >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
