Re: [lkcd-devel] Re: Re: lcrash and debian

Corey Minyard <[email protected]> Mon, 04 Oct 2004 12:23:09 -0500
Newsgroups gmane.linux.lkcd.general
Message-ID <[email protected]>
Tom Morano wrote:

>I guess I don't quite see where lcrash is so tied to the kernel version. The
>only thing that would cause it problems is a functional change in a kernel
>data structure (remove/change a key struct member, etc.). Of course that may
>not be the case with the version currently in the CVS tree (I've noticed
>that there are some problems with the treatment of local copies of dump
>headers, for example). Being able to do gdb operations is a nice feature,
>however lcrash can nicely print arbitrary data structures too, so I'm not
>quite sure what you mean by your last statement.\
>  
>
This is exactly what I'm talking about.  If a user turns on/off things 
like preemption and SMP, major kernel data structures change.  Plus, 
lcrash will only work with one version of the LKCD header (we currently 
support two).  I don't want to have to compile a different version of 
lcrash for each possibility.  And our users will complain bitterly if 
they have to do that.

On the second part, you mean I can type something like:

  p *(ipmi_interfaces[0])

and get a nicely formatted output, just like gdb?

>>Probably the ugliest think about lkcdutils is building it.  It really
>>needs to use autoconf/automake.  (So does crash, BTW).  But I don't have
>>a lot of reason to fix that because I'm not using it any more.  I might
>>work on fixing crash, but I have a lot of other things on my plate right
>>now.
>>
>>IMHO, lkcdutils doesn't need to exist any more.  Let Dave handle the
>>crash dump support (with a little support from you) and use some simple
>>tool for crash dump extraction like the one HP developed or lkcdtools.
>>That way you can focus your energy on other things.
>>    
>>
>
>Perhaps in the future...right now that is not an option (for us). There are
>various reasons why lkcdutils (lcrash) is our crash dump toolset of choice.
>A lot of these tie directly to support of our (SGI) systems and the timing
>of product releases. We will have to see how this entire space evolves over
>time. Right now, I'm just glad to see a higher level of activity and energy
>in this project.
>  
>
Fair enough, I understand how that goes :).

-Corey



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl