All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, stefanha@gmail.com, aliguori@us.ibm.com,
	Wenchao Xia <xiawenc@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/6] libqblock APIs
Date: Mon, 03 Sep 2012 16:05:06 +0200	[thread overview]
Message-ID: <5044B912.7020405@redhat.com> (raw)
In-Reply-To: <5044B720.5080205@redhat.com>

Il 03/09/2012 15:56, Eric Blake ha scritto:
> Exactly how does the *pnum argument work?  This interface looks like it
> isn't fully thought out yet.  Either I want to know if a chunk of
> sectors is allocated (I supply start and length of sectors to check),
> regardless of how many sectors beyond that point are also allocated
> (pnum makes no sense);

pnum makes sense if the [start, start+length) range includes both
allocated and unallocated sectors.

> or I want to know how many sectors are allocated
> from a given point (I supply start, and the function returns length, so
> nb_sectors makes no sense).

This operation could be O(number of blocks in disk) worst case, so it
makes sense to provide nb_sectors as an upper bound.  nb_sectors is
typically dictated by the size of your buffer.

That said, QEMU's internal bdrv_is_allocated function does have one not
entirely appealing property: the block at start + *pnum might have the
same state as the block at start + *pnum - 1, even if *pnum < length.
We may want to work around this in libqblock, but we could also simply
document it.

Paolo

> Either way, I think you are supplying too
> many parameters for how I envision checking for allocated sectors.

  reply	other threads:[~2012-09-03 14:05 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03  9:18 [Qemu-devel] [PATCH 0/6] libqblock, qemu block layer library Wenchao Xia
2012-09-03  9:18 ` [Qemu-devel] [PATCH 1/6] libqblock APIs Wenchao Xia
2012-09-03 13:18   ` Paolo Bonzini
2012-09-04  3:15     ` Wenchao Xia
2012-09-04  6:50       ` Paolo Bonzini
2012-09-04  9:05         ` Wenchao Xia
2012-09-10  8:10         ` Wenchao Xia
2012-09-03 13:56   ` Eric Blake
2012-09-03 14:05     ` Paolo Bonzini [this message]
2012-09-04  7:05       ` Wenchao Xia
2012-09-04  7:29         ` Paolo Bonzini
2012-09-04  6:42     ` Wenchao Xia
2012-09-04 11:35       ` Eric Blake
2012-09-04 13:47         ` Paolo Bonzini
2012-09-03 19:22   ` Blue Swirl
2012-09-03  9:18 ` [Qemu-devel] [PATCH 2/6] libqblock public type defines Wenchao Xia
2012-09-03 13:13   ` Paolo Bonzini
2012-09-04  2:00     ` Wenchao Xia
2012-09-03 14:20   ` Eric Blake
2012-09-04  7:10     ` Wenchao Xia
2012-09-04  7:37       ` Paolo Bonzini
2012-09-03 19:31   ` Blue Swirl
2012-09-04  7:19     ` Wenchao Xia
2012-09-04  7:38       ` Paolo Bonzini
2012-09-04 19:22         ` Blue Swirl
2012-09-10  8:22           ` Wenchao Xia
2012-09-03  9:18 ` [Qemu-devel] [PATCH 3/6] libqblock error handling Wenchao Xia
2012-09-03 14:22   ` Eric Blake
2012-09-04  7:12     ` Wenchao Xia
2012-09-10  8:20     ` Wenchao Xia
2012-09-03  9:18 ` [Qemu-devel] [PATCH 4/6] libqblock internal used functions Wenchao Xia
2012-09-03 13:18   ` Paolo Bonzini
2012-09-04  3:19     ` Wenchao Xia
2012-09-03 14:28   ` Eric Blake
2012-09-03 15:18     ` Paolo Bonzini
2012-09-04  7:15       ` Wenchao Xia
2012-09-04  7:38         ` Paolo Bonzini
2012-09-04 11:38         ` Eric Blake
2012-09-04 13:49           ` Paolo Bonzini
2012-09-04 13:51             ` Kevin Wolf
2012-09-10  8:23               ` Wenchao Xia
2012-09-03  9:18 ` [Qemu-devel] [PATCH 5/6] libqblock test example Wenchao Xia
2012-09-03 19:27   ` Blue Swirl
2012-09-03  9:18 ` [Qemu-devel] [PATCH 6/6] libqblock building system Wenchao Xia
2012-09-03 13:10   ` [Qemu-devel] xbzrle migration cache size advise for high memory changes workload ? Alexandre DERUMIER
2012-09-04 14:05     ` Orit Wasserman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5044B912.7020405@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=xiawenc@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.