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

[tristan]

Joel Becker wrote:
> On Sat, Feb 20, 2010 at 02:46:06PM +0800, tristan wrote:
>   
>>> 	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
>>>       
>> 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
>>     
>
> 	Good point, I didn't realize any of the operations took
> arguments.
>
>   
>> 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
>>     
>
> 	I'm confused by this one.  'o2info volinfo fs-features
> /dev/sdx1' works just as well as the one with '--'.  So I don't see how
> we cause any problems.
>
>   

Yes, your way of 'o2info volinfo fs-features /dev/sdx1' of course works 
in that case, I meant long-options way also was capable of doing 
combined operations as well, besides, it kept a good unification of 
usage with 'tunefs.ocfs2'


>> 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'
>>     
>
> 	This is a "don't care".  There's no real usability benefit to
> allowing the device in the middle.
> 	We have to handle arguments to operations.  Our real problem was
> the conflicting short options.  Solution: no short options for
> operations.  All operations (--volinfo, --fs-features, --freefrag, etc)
> are long options only.  True options (-v for --verbose, -F for
> --no-coherency, etc) have both short and long versions.
>   

Yes, the most embarrassing thing here is the naming of short options, 
part of operations were racing for one reasonable short-option name...

I guess the solution could be, we provide part of operation with both 
short-options and long-options, and rest of them only have 
short-options. that's the way tunefs.ocfs2 was doing:

[options] can be any mix of:
-i|--interactive
-p|--progress
-v|--verbose (increases verbosity; more than one permitted)
-q|--quiet (decreases verbosity; more than one permitted)
-L|--label <label>
-N|--node-slots <number-of-node-slots>
-S|--volume-size
-U|--uuid-reset
-J|--journal-options <options>
-Q|--query <query-format>
--list-sparse
--fs-features [no]sparse,...
--update-cluster-stack
--cloned-volume[=new-label]
-y|--yes
-n|--no

Our o2info could be as follows:

Usage: o2info [options] <device or file>
o2info -h|--help
o2info -V|--version
[options] can be followings:
|--volinfo
--fs-features
--no-coherency
-U|--space-usage
-S|--file-statistics
-F|--freefrag <chunksize in KB>
-I|--freeinode



How do you think about this?


Tristan.
> Joel
>
>