[Ocfs2-tools-devel] [PATCH 08/11] Ocfs2-tools: Add main.c to o2info.

tristan tristan.ye at oracle.com
Fri Feb 19 22:46:06 PST 2010


Joel,

I trust you a lot on the naming of options&short-options:-)


Joel Becker wrote:
> On Fri, Jan 08, 2010 at 04:50:58PM +0800, Tristan Ye wrote:
>   
>> +static struct o2info_option version_option = {
>> +	.opt_option	= {
>> +		.name		= "version",
>> +		.val		= 'v',
>> +		.has_arg 	= 0,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	= NULL,
>> +	.opt_handler	= version_handler,
>> +	.opt_op		= NULL,
>> +	.opt_private = NULL,
>> +};
>>     
>
> 	Oh, no, do not use 'v' as the short option for "--version".
> '-v' usually means "--verbose", including in other ocfs2 tools.  We use
> '-V' for "--version" elsewhere.  Of course, that means '-V' cannot be
> "--volinfo".  More below.
>
>   

So we made the deal, use -V here.

>> +static struct o2info_option coherency_option = {
>> +	.opt_option	= {
>> +		.name		= "no-coherency",
>> +		.val		= 'c',
>> +		.has_arg 	= 0,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	=
>> +		"-c|--no-coherency",
>> +	.opt_handler	= coherency_handler,
>> +	.opt_op		= NULL,
>> +	.opt_private = NULL,
>> +};
>>     
>
> 	I don't like '-c'.  It would imply "coherency", not "_no_
> coherency".  '-n' doesn't work, because it ususally means "--dry-run".
> How about '-F', which is our usual idiom for "ignore the cluster"?
>   

'-F' is ok for me.

>   
>> +static struct o2info_option volinfo_option = {
>> +	.opt_option	= {
>> +		.name		= "volinfo",
>> +		.val		= 'V',
>> +		.has_arg	= 0,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	=
>> +		"-V|--volinfo",
>> +	.opt_handler	= NULL,
>> +	.opt_op		= &volinfo_op,
>> +	.opt_private	= NULL,
>> +};
>>     
>
> 	As I said above, '-V' is '--version'.  I'd think '-I' for
> "info" or '-S' for "superblock info", but both are taken below.  We need
> to think about a good thing here.
>   

How about '-B' for superBlock or '-D' for dump superblock or '-O' for 
output of volinfo?

It really makes the naming of this one a little bit tough if we aren't 
going to use '-V', '-S' or '-I' :)

>   
>> +static struct o2info_option usage_option = {
>> +	.opt_option	= {
>> +		.name		= "usage",
>> +		.val		= 'U',
>> +		.has_arg	= 0,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	= "-U|--usage",
>> +	.opt_handler	= NULL,
>> +	.opt_op		= &usage_op,
>> +};
>>     
>
> 	"--usage" made me think "--help" at first.  How about
> "--space-usage".  '-U' is a fine short option.
>   

Good catch, '--usage' was somewhat misleading to '--help', 
'--space-usage' could be much more straightforward.


>   
>> +static struct o2info_option filestat_option = {
>> +	.opt_option	= {
>> +		.name		= "filestat",
>> +		.val		= 'S',
>> +		.has_arg	= 0,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	= "-S|--filestat",
>> +	.opt_handler	= NULL,
>> +	.opt_op		= &filestat_op,
>> +};
>>     
>
> 	"--file-stats"?  "--file-statistics"?  Long options should not
> be cryptic.
>   

Thanks for catching this.

>   
>> +static struct o2info_option freefrag_option = {
>> +	.opt_option	= {
>> +		.name		= "freefrag",
>> +		.val		= 'F',
>> +		.has_arg	= 1,
>> +		.flag		= NULL,
>> +	},
>> +	.opt_help	= "-F|--freefrag <chunksize in KB>",
>> +	.opt_handler	= NULL,
>> +	.opt_op		= &freefrag_op,
>> +};
>>     
>
> 	Argh!  I considered using '-F' above.
> 	I think we're going to have to give up on option names for this.
> They aren't options - they are _operations_.  Forget getopt for these.
> Instead, the usage should be 'o2info [options] <operation> [..
> <operation>] <device>'.  eg, "o2info -F volinfo freefrag freeinodes
> /dev/sdb1".  You only use getopt to gather actual options.  Things like
> "no coherencye".  Then at the end of the option list, you walk the
> remaining arguments for operation names.  The last argument is the
>   

Joel,

You suggestion may make the usage of o2info look more straightforward 
and easy for end-users, It however will be losing flexibility somehow, 
How about the case when each operation needs a specific argument, such 
as, 'freefrag' need us to specify a chunksize. Besides, it also keeps an 
unification in favor to tunefs.ocfs2 which also uses long-options for 
operations. Even what's more, we also could be able to do combined 
operations by following:

'o2info --volinfo --fs-features /dev/sdx1', and we will not be forcing 
users to place device or filename at the end of cmd, following usage 
also is welcome:

'o2info /file/in/ocfs2/volume --volinfo --freefrage 32' OR

'o2info --volinfo /dev/sdb1 --fs-features'


How do you think about it?


Regards,
Tristan.


> device.
>
> Joel
>
>   




More information about the Ocfs2-tools-devel mailing list