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

----- Original Message -----
From: "Corey Minyard" <[email protected]>
To: "Tom Morano" <[email protected]>
Cc: "Michael Holzheu" <[email protected]>; "Micah Anderson"
<[email protected]>; "Hariprasad Nellitheertha" <[email protected]>;
"lkcd-devel" <[email protected]>;
<[email protected]>;
<[email protected]>
Sent: Monday, October 04, 2004 6:04 AM
Subject: Re: [lkcd-devel] Re: [lkcd-general] Re: lcrash and debian

.
.
.

> >Corey,
> >
> >I'm not sure the LKCD project is the best place for crash (it was only
> >pushed into the LKCD tree because it wasn't clear where it was going to
end
> >up after MCL stopped supporting it). I may be off base on this as I don't
> >use crash and am totally focused on lcrash. At the very least, I don't
think
> >it belongs inside of the lkcdutils tree. Ideally, I would like to see the
> >two projects combine their efforts somewhat. I'm not sure if that's
possible
> >however. I would be interested in hearing input from others on this list
> >regarding their preference.
> >
> >
> I really don't like lcrash because it is so tied to the kernel version.
> With crash, I can use the same tool to work on different versions with
> the same tool.  In an environment where I have to analyze crash dumps
> from lots of customers running on different kernel versions, different
> versions of LKCD (not to mention some using mcore), crash is much
> nicer.  I like the crash user interface better, too, especially the
> ability to do gdb operations with it.  The ability to nicely print
> arbitrary data structures is quite handy.

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.

>
> Plus, I have cross support for crash, which is also an absolute
> necessity for us since we support host development on different
> platforms than the target environment.

I guess I'm missing something here. The current version of lcrash appears to
have cross architecutre support (if you build it that way). I haven't used
it much that way, so perhaps there are some issues there that I don't know
about.

>
> If I was to support this, I would maintain the one that does
> cross-development support, BTW.  I think there are enough people
> interested in this to make it worthwhile.
>
> >Regarding your lkcdtools, this sounds like something that would make
sense
> >to include in the LKCD project. Right now, we are trying to get the tree
> >synced up with what is shipping on SuSE SLES9 and get LKCD working with
> >Debian. Beyond that, I'm focused on getting this working on SGI Altix
(IPF)
> >systems. The basic layout of the source and release mechanism is open for
> >discussion. I would assume the same is true for the base level utilities
> >themselves. This project is definitely in need of some more energy. Feel
> >free to jump in... :]
> >
> >
> 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.

Tom



-------------------------------------------------------
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