From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XASg4-0003ry-Lp for qemu-devel@nongnu.org; Thu, 24 Jul 2014 19:44:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XASfy-0005IK-Fp for qemu-devel@nongnu.org; Thu, 24 Jul 2014 19:44:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XASfy-0005ID-7t for qemu-devel@nongnu.org; Thu, 24 Jul 2014 19:43:54 -0400 Message-ID: <53D19A54.7030606@redhat.com> Date: Fri, 25 Jul 2014 01:44:20 +0200 From: Max Reitz MIME-Version: 1.0 References: <1405802159-2355-1-git-send-email-mreitz@redhat.com> <1405802159-2355-2-git-send-email-mreitz@redhat.com> <53CD3728.1040904@redhat.com> <53CEC441.5020801@redhat.com> <20140723081005.GA3666@noname.str.redhat.com> In-Reply-To: <20140723081005.GA3666@noname.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Lieven , qemu-devel@nongnu.org, Stefan Hajnoczi 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