[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/3] block/backup: avoid copying

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/3] block/backup: avoid copying less than full target clusters
Date: Wed, 24 Feb 2016 09:49:44 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/23/2016 05:52 PM, John Snow wrote:

> "Couldn't determine the cluster size of the target image, which has no
> backing file" is more correct. The problem is not why we couldn't
> determine it, but instead that we were unable to AND there is no backing
> file, so our inability to determine it is a problem.
> What's our policy on error message strings that eclipse 80 columns? I
> was told once (at gunpoint; I live in the USA) to never split up long
> strings because it makes them harder to grep for.

I don't mind error messages longer than 80 columns; and I also don't
mind string concatenation to fit the source of the message into
reasonable lengths (when I grep for a message, I just grep for the first
few words, not the whole message, precisely so that line wraps later in
the message don't cause me grief).  There's varying opinions from other
contributors on whether an error message can be split, but I don't see
anything in HACKING that says which style must prevail.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]