qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v3 2/4] qemu-img: make --block-size optional for compare --st


From: Eric Blake
Subject: Re: [PATCH v3 2/4] qemu-img: make --block-size optional for compare --stat
Date: Mon, 1 Nov 2021 09:19:01 -0500
User-agent: NeoMutt/20211022

On Mon, Nov 01, 2021 at 11:03:22AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2021 23:32, Eric Blake wrote:
> > On Thu, Oct 28, 2021 at 12:24:39PM +0200, Vladimir Sementsov-Ogievskiy 
> > wrote:
> > > Let's detect block-size automatically if not specified by user:
> > > 
> > >   If both files define cluster-size, use minimum to be more precise.
> > >   If both files don't specify cluster-size, use default of 64K
> > >   If only one file specify cluster-size, just use it.
> > > 
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> > > ---
> > >   docs/tools/qemu-img.rst |  7 +++-
> > >   qemu-img.c              | 71 +++++++++++++++++++++++++++++++++++++----
> > >   qemu-img-cmds.hx        |  4 +--
> > >   3 files changed, 72 insertions(+), 10 deletions(-)
> > > 
> > 
> > Reviewed-by: Eric Blake <eblake@redhat.com>
> > 
> > > +    if (cluster_size1 > 0 && cluster_size2 > 0) {
> > > +        if (cluster_size1 == cluster_size2) {
> > > +            block_size = cluster_size1;
> > > +        } else {
> > > +            block_size = MIN(cluster_size1, cluster_size2);
> > > +            qprintf(quiet, "%s and %s have different cluster sizes: %d 
> > > and %d "
> > > +                    "respectively. Using minimum as block-size for "
> > > +                    "accuracy: %d. %s\n",
> > > +                    fname1, fname2, cluster_size1,
> > > +                    cluster_size2, block_size, note);
> > 
> > Results in a long line; I don't know if it's worth trying to wrap it
> > (if we had a generic utility function that took arbitrary text, then
> > outputs it wrapped to the user's current terminal column width, I'd
> > suggest using that instead - but that's NOT something I expect you to
> > write, and I don't know if glib has such a utility).
> > 
> 
> Hmm. But long lines printed to the terminal are wrapped by terminal 
> automatically, so we don't need to wrap to terminal width by hand..

/me using a short line length in the next paragraph on purpose...

There's a difference between the ter
minal wrapping when you hit the maxi
mum length, and in intelligent
wrapping the prefers natural word
breaks.

There are programs out there that do intelligent wrapping (for
example, the mutt mailer), but I'm not sure if those wrapping routines
are available through glib.  At any rate, I do NOT want to reimplement
intelligent wrapping from scratch (Unicode specifies a rather complex
algorithm for getting sane wrapping in the presence of various Unicode
characters, and it is not trivial https://unicode.org/reports/tr14/).
So unless someone knows of an easy-to-use library that does wrapping,
you are right that leaving long lines for the terminal to output, even
when that output has awkward mid-word breaks, is tolerable.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org




reply via email to

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