[Crash-utility] [PATCH 0/3] Add a "percpu" command

[Dave Anderson]

----- Original Message -----
> On Sat, 12 Oct 2013 21:41:49 +0200
> Petr Tesarik <ptesarik at suse.cz> wrote:
> 
> >[...]
> > In general, I think it's a matter of taste, and if you dislike new
> > commands, it all boils down to finding a suitable syntax to extend the
> > existing commands. Unfortunately, "-c" (as CPU) is already taken for
> > count, and "-p" (as processor) is already taken for pointer
> > dereference. :-(
> > 
> > I can think of:
> > 
> > A. "-C" (but it requires a shift key, and two options that only
> >    differ in case may be confusing)
> > B. any other random letter ("-a" is free).
> 
> Hm, it seems this is the only blocking piece. If nobody has an idea
> until tomorrow, I'll just pick '-C', even though I hate both the shift
> key and the fact that another command ('irq') uses a different option
> ('-c') for the same concept.

I agree with you on both counts.  

I haven't had the chance to reply to your second response (I took the holiday
off yesterday), but I think a suitable compromise would be to change the 
"struct/union/* -c count" option to perhaps a "-n number" option?  

Another other option that crossed my mind would be to have a unique manner
for presenting per-cpu addresses and cpu(s) as a command argument.  They are
offset values, but they could be confused for zero-based kernel virtual address
arches (s390/s390x), so there would need to be a option to differentiate
zero-based kernel virtual addresses, and then a second option of the cpu
specifier.    

But anyway, maybe per-cpu addresses could be made to be "self-identified"
if they were presented as "<offset>:<cpu-identifer>", where the colon would
define the argument as a per-cpu item, and the <cpu-identifier> part could be
one of the following:

  offset:               nothing following the colon means the current cpu
  offset:a              all cpus
  offset:cpu-specifier  same as your patch or the irq command

That way the struct/union/* commands would seemingly only require one
of these new hybrid option formats as an "address" argument, and no 
additional -<opt> would be required, right? 

For the "p <per-cpu symbol>" command, only the additional cpu identifier
would be required, using either "-c <cpu-specifier">, or maybe it could
also allow a "<per-cpu symbol>:<cpu-specifier>" option, where if the colon
was not applied, the current behavior would be remain unchanged (because
there still should be a way to just display what it does now).  And if
the :<cpu-specifier>" were appended to the symbol name, then it would
go ahead an print the contents of the item(s). 
  
Maybe I'm overthinking it...  

But since per-cpu stuff has become so prevalent over the years, maybe it's
worth having a new specifier format.  What do you think?

Dave