Re: [Crash-utility] Re: [RFC] Provide minimal debugging to crash
Dave Anderson wrote:
Sharyathi Nagesh wrote:
> Please go through the features and let us know your thoughts
> ========================================================================
It seems safe enough to apply, and I like the idea. I'm just amazed that
the wholesale removal of all of the xxx_init() routines allows the
restricted
command list to work properly!
Hi Dave,
Good to know that you like this idea of providing minimal option
for crash.
The idea behind this work was to provide a way to extract some
minimal/quick information from a dump even if it is corrupted.
In most scenarios where a vmcore has been collected, one would
quickly like to extract dmesg and would like to have a way to
use dis/rd commands. So in cases where a vmcore is corrupted
one would be frustrated at not having the above minimal info
available. Ofcourse to do some serious debugging he will anyway
need a full vmcore.
While looking at the code we felt that just executing the first
block of xxx_init() functions would suffice for the above
requirement.
> - } else {
> + } else if(!(pc->flags & MINIMAL_MODE)){
> read_in_kernel_config(IKCFG_INIT);
> kernel_init();
> machdep_init(POST_GDB);
I haven't walked through all the restricted command list code paths to
verify that they can work properly for all architectures without, say,
kernel_init(), the 3 machdep_init() calls, vm_init() etc. having run.
Certainly trying to rd or dis vmalloc addresses would display garbage
data or just fail, but that's to be expected.
I quickly tried this on a x86 and x86_64 -- but have you tried this on
an ia64 or ppc64?
Yes we have tested this on ppc64 along with x86(Not with a
corrupted
dump but with regular dumps. Couldn't find a way to get a
corrupted dump :-)
We don't have access to an ia64 box so couldn't test this. All the
above mentioned commands work fine on the above boxes.
On system Z we have tested this with a corrupted dump which
Michael had provided. Thanks Michael for that.
The only thing I'm not excited about is all the re-tinkering with the
help screen output. Why bother? I'd prefer to keep things simple.
During initialization, display a WARNING message that lists the supported
commands just prior to the first prompt. And then just leave the help
screen alone, and let your command-restriction mechanism display the
per-command message:
error(INFO, "command: %s not available in minimal mode\n", args[0]);
...and then perhaps followed up immediately with the acceptable command
list again.
Hm yeah this could be done. Will work on this.
Another minor suggestion -- I think you can put the "eval" command in
the supported list. I use it all the time, and in this minimal
environment
it may come in very handy. (There may be others, but they're probably
not
worth having...)
OK. Will add this command.
But this is pretty cool. If I had known that you could get this basic
functionality so simply, I would have done this long ago! Nice job.
Thanks again for reviewing this.
Regards
- Sharyathi/ Sachin
Dave
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------