On 09/12/2014 06:32 AM, Peter Krempa wrote: > On 09/12/14 05:55, Eric Blake wrote: >> Take the previous patch one step further. In addition to >> automatically selecting byte mode with fallback if the >> user's result would be rounded, we also want to give the >> user a way to guarantee byte mode even if rounding is not >> required, with no fallback if the remote side doesn't >> support byte mode. This way, virsh can be used to more >> fully test the impact of setting the bytes flag. >> >> * tools/virsh-domain.c (blockJobBandwidth): Adjust return type and >> check for --bytes flag. >> (cmdBlockCommit, cmdBlockPull, cmdBlockJob): Add --bytes flag. >> (cmdBlockCopy): Likewise, and adjust caller. >> (blockJobImpl): Adjust caller. >> * tools/virsh.pod (blockcommit, blockcopy, blockpull, blockjob): >> Document this. >> >> Signed-off-by: Eric Blake <eblake@xxxxxxxxxx> >> --- >> tools/virsh-domain.c | 57 ++++++++++++++++++++++++++++++++++------------------ >> tools/virsh.pod | 48 +++++++++++++++++++++---------------------- >> 2 files changed, 61 insertions(+), 44 deletions(-) >> >> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c > > Whoah, this is getting a bit too complex IMHO for a simple task. > > How about not doing any automagic switching and if the user specifies > the --bytes flag then it would be passed and otherwise just the old > MiB/s value. The --bytes flag could also parse the value as a scaled > integer then. So if I understand your proposal, old call, in MiB: blockjob $dom $disk --bandwidth 1 invalid (attempt to scale, but no --bytes present) blockjob $dom $disk --bandwidth 1B new call, in bytes (awfully small value!), fails if server doesn't work blockjob $dom $disk --bandwidth 1 --bytes new call, in bytes, but using scaling to match old call blockjob $dom $disk --bandwidth 1M --bytes and no automatic fallbacks. I can live with that, but it means ditching patches 5 and 6, and posting a complete alternative. Give me a couple days (I've got another project I'm working at the moment, for image allocation high-watermark reporting), and we'll compare the two approaches. > > This would allow to drop a lot of the complexity while still allow to > use the new flags as we unfortunately have to stick with MiB/s in virsh. > That on the other hand doesn't force us to do overly complex logic that > can be left on the operator. Any other opinions on whether virsh should be user-friendly (automagic fallback) vs. more literal exposure (no scaled input without --bytes, but maps closer to API)? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list