All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/3] bitmap: import bitmap_{set/clear} from Linux 5.5
Date: Mon, 10 Feb 2020 13:32:49 +0100	[thread overview]
Message-ID: <ea8e70a3-83d2-0491-115c-fbf18bd1d705@suse.com> (raw)
In-Reply-To: <87208524-5c30-48cf-fe7a-e5d77a26414b@xen.org>

On 10.02.2020 13:21, Julien Grall wrote:
> Hi,
> 
> On 10/02/2020 11:59, Jan Beulich wrote:
>> On 10.02.2020 12:00, Julien Grall wrote:
>>> On 10/02/2020 10:28, Jan Beulich wrote:
>>>> On 10.02.2020 10:45, Julien Grall wrote:
>>>>> Please suggest a new name for BIT_WORD() and we can repurpose it. So
>>>>> far, I have no idea how to rename it.
>>>>
>>>> _BIT_WORD() if you/we were to accept the name space violation, or
>>>> BITMAP_WORD()?
>>>
>>> BITMAP_WORD() is misleading as bitmap are using unsigned long. So my
>>> preference is _BIT_WORD().
>>>
>>> Another alternative would be ATOMIC_WORD().
>>
>> Except that there are also non-atomic bitmap operations, I don't really
>> care about the name as long as it's not BIT_WORD() (or anything else
>> that's likely to collide with other stuff.
> 
> I am afraid we are disagreing on what is colliding with what here. The 
> naming on Arm has been like that for the past few years. While this may 
> not have been the best choice, this is your suggestion colliding with 
> what is existing.

It is a plain import from Linux which has turned out impossible
because of the change that was done at some point to Arm code
which, I guess, also originally came from Linux. There's no new
naming I've been suggesting here at all.

> I am not entirely fussed about the namespace violation, although I think 
> the name is potentially misleading. Yet, I would be happy to use 
> _BIT_WORD() as this is the best of it so far.
> 
> While this is code falls under Arm maintainership, I am still happy to 
> consider other naming. But at this point, you should be the one suggesting.

BIT_UNIT() or BITOP_UNIT() or BITOP_WORD()?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-02-10 12:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 17:34 [Xen-devel] [PATCH v4 0/3] nvmx: implement support for MSR bitmaps Roger Pau Monne
2020-02-04 17:34 ` [Xen-devel] [PATCH v4 1/3] " Roger Pau Monne
2020-02-05  8:50   ` Jan Beulich
2020-02-04 17:34 ` [Xen-devel] [PATCH v4 2/3] bitmap: import bitmap_{set/clear} from Linux 5.5 Roger Pau Monne
2020-02-05  8:46   ` Jan Beulich
2020-02-05 13:21     ` Roger Pau Monné
2020-02-05 13:27       ` Jan Beulich
2020-02-08 14:37         ` Julien Grall
2020-02-10  8:43           ` Jan Beulich
2020-02-10  9:20             ` Julien Grall
2020-02-10  9:31               ` Jan Beulich
2020-02-10  9:45                 ` Julien Grall
2020-02-10 10:28                   ` Jan Beulich
2020-02-10 11:00                     ` Julien Grall
2020-02-10 11:59                       ` Jan Beulich
2020-02-10 12:21                         ` Julien Grall
2020-02-10 12:32                           ` Jan Beulich [this message]
2020-02-10 12:54                             ` Julien Grall
2020-02-14 10:40                               ` Roger Pau Monné
2020-02-14 12:04                                 ` Jan Beulich
2020-02-04 17:34 ` [Xen-devel] [PATCH v4 3/3] nvmx: always trap accesses to x2APIC MSRs Roger Pau Monne
2020-02-05  8:52   ` Jan Beulich

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=ea8e70a3-83d2-0491-115c-fbf18bd1d705@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.