Re: [Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specification

[Max Reitz <mreitz@redhat.com>]

On 23.07.2014 10:10, Kevin Wolf wrote:
> Am 22.07.2014 um 22:06 hat Max Reitz geschrieben:
>> On 21.07.2014 17:52, Eric Blake wrote:
>>> On 07/19/2014 02:35 PM, Max Reitz wrote:
>>>> Many qemu-img subcommands only read the source file(s) once. For these
>>>> use cases, a full write-back cache is unnecessary and mainly clutters
>>>> host cache memory. Though this is generally no concern as cache memory
>>>> is freely available and can be scaled by the host OS, it may become a
>>>> concern with thin provisioning.
>>>>
>>>> For these cases, it makes sense to allow users to freely specify the
>>>> source cache mode (e.g. use no cache at all).
>>>>
>>>> This commit adds a new switch (-T) for the qemu-img subcommands check,
>>>> compare, convert and rebase to specify the cache to be used for source
>>>> images (the backing file in case of rebase).
>>> What mnemonic did you have in mind when choosing -T? Or was it just a
>>> universally available letter for the subcommands you were touching?
>> To be honest, I just didn't know what -t stands for. Therefore I
>> just thought it might be remotely logical if the lower-cased letter
>> is used for destination and the upper-cased letter for source
>> caching.
> Things might get a bit confusing there, though, because upper-case
> often means the "other image", i.e. destination or backing file, in other
> commands (create -F, compare -F, convert -O and -B, rebase -F).

Right, but we don't really have the choice to suddenly make -t an 
upper-case option.

> Of course, most of them are deprecated, so I wouldn't make that a reason
> to block this series, but perhaps we should consider using more long
> options instead of randomly assigning the letters that are still free.

Well, it's not completely random; -t is a cache mode and -T will be, too 
(and I don't think -T should be used for anything but another cache 
mode). I guess I'd generally vote for introducing long options for 
everything after this series, but then some people might use -T and 
confuse others (hence not introducing -T at all might actually make 
sense). I'd be fine with -t and -T and introducing long options later 
on, so I leave it up to you. ;-)

Max