From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752149AbbJYI7N (ORCPT ); Sun, 25 Oct 2015 04:59:13 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:33337 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952AbbJYI7L (ORCPT ); Sun, 25 Oct 2015 04:59:11 -0400 Date: Sun, 25 Oct 2015 09:59:06 +0100 From: Ingo Molnar To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Jiri Olsa , LKML , David Ahern Subject: Re: [PATCH 2/4] perf report: Rename to --show-cpu-utilization Message-ID: <20151025085906.GC24337@gmail.com> References: <1445701767-12731-1-git-send-email-namhyung@kernel.org> <1445701767-12731-2-git-send-email-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1445701767-12731-2-git-send-email-namhyung@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Namhyung Kim wrote: > So that it can be more consistent with other --show-* options. The old > name (--showcpuutilization) is provided only for compatibility. 1) Btw., maybe we could enhance the option parser to strip all (non-leading) dashes from long-form option names? That way both variants would work naturally, and if someone thinks it's called '--show-cpuutilization' that would work as well. 2) Also, another enhancement would be to allow partial matches, so that --showcpu would match on the first long-form option name that matches. Right now we do: triton:~/tip> perf report -h --showcpu Usage: perf report [] triton:~/tip> Which arguably isn't very helpful! :-) 3) The only drawback of doing partial matches would be if we introduce new variants - but we'd still 'break' safely: if for example --show-cpu-usage is introduced in a couple of years, then previous usage of: perf report --showcpu would emit your ambiguous-options warning that you improved in this series. We'd output the two options that match and the user could adjust the parameter to whichever he meant. It would still very smooth behavior from a UI ergonomy POV IMHO. 4) Another possible tweak would be to print a non-fatal info line when a user didn't use the canonical form of the option. So writing: perf report --showcpu would result in (stdout) output like this: # Option parser: '--showcpu' matched on '--show-cpu-utilization' The disadvantage of this would be the extra nuisance factor, so I'm not sure we want this aspect. Thanks, Ingo