----- Original Message -----
On Sat, 12 Oct 2013 21:41:49 +0200
Petr Tesarik <ptesarik(a)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