All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: Peter Xu <peterx@redhat.com>,
	qemu-devel@nongnu.org, quintela@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] bitmap: fix BITMAP_LAST_WORD_MASK
Date: Wed, 8 Aug 2018 09:29:38 +0100	[thread overview]
Message-ID: <20180808082937.GA2734@work-vm> (raw)
In-Reply-To: <5B6A48AF.7010906@intel.com>

* Wei Wang (wei.w.wang@intel.com) wrote:
> On 08/07/2018 05:53 PM, Dr. David Alan Gilbert wrote:
> > * Wei Wang (wei.w.wang@intel.com) wrote:
> > > On 08/07/2018 03:39 PM, Peter Xu wrote:
> > > > On Tue, Jul 31, 2018 at 06:01:18PM +0800, Wei Wang wrote:
> > > > > When "nbits = 0", which means no bits to mask, this macro is expected to
> > > > > return 0, instead of 0xffffffff. This patch changes the macro to return
> > > > > 0 when there is no bit needs to be masked.
> > > > > 
> > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > > > > CC: Juan Quintela <quintela@redhat.com>
> > > > > CC: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > > > CC: Peter Xu <peterx@redhat.com>
> > > > Reviewed-by: Peter Xu <peterx@redhat.com>
> > > > 
> > > > Is there any existing path that can trigger this nbits==0?
> > > Not sure about other bitmap APIs which call this macro. But it happens in
> > > the patches we are working on, which use bitmap_count_one.
> > > It would be good to have the macro itself handle this corner case, so that
> > > callers won't need to worry about that.
> > Given that I see you're having a similar discussion on the kernel list
> > we should see how that pans out before making qemu changes.
> 
> OK.
> The situation is a little different in Linux, because all the callers there
> have already taken the responsibilities to avoid the "nbits=0" corner case,
> that's also the reason that they want to stick with the old way. Here in
> QEMU, most callers (e.g. bitmap_count_one, bitmap_fill, bitmap_intersects)
> haven't checked that, so fixing the macro itself might be a better choice
> here.

Where we have macros or functions that have the same name as the kernel
then we should keep them consistent with the kernel unless we have a
VERY good reason to make them differ;  that's especially true if the
difference is a small subtle difference like this;  otherwise it would
be too easy for someone used to QEMU or the kernel to introduce a bad
mistake in the other one because they think they're using the same
thing.

Dave


> Best,
> Wei
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-08-08  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 10:01 [Qemu-devel] [PATCH v2] bitmap: fix BITMAP_LAST_WORD_MASK Wei Wang
2018-07-31 14:44 ` Juan Quintela
2018-08-07  7:39 ` Peter Xu
2018-08-07  8:21   ` Wei Wang
2018-08-07  9:53     ` Dr. David Alan Gilbert
2018-08-08  1:34       ` Wei Wang
2018-08-08  8:29         ` Dr. David Alan Gilbert [this message]
2018-08-07 12:17     ` Peter Xu
2018-08-08  1:30       ` Wei Wang

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=20180808082937.GA2734@work-vm \
    --to=dgilbert@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=wei.w.wang@intel.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.