[Crash-utility] Re: [RFC] Provide minimal debugging to crash

[Sachin P. Sant]

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