----- Original Message ----- > On Sat, 12 Oct 2013 21:41:49 +0200 > Petr Tesarik <ptesarik@xxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility