[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170301165801.GC20547@potion>
Date: Wed, 1 Mar 2017 17:58:02 +0100
From: Radim Krčmář <rkrcmar@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Andrew Jones <drjones@...hat.com>,
Marc Zyngier <marc.zyngier@....com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>,
James Hogan <james.hogan@...tec.com>,
Paul Mackerras <paulus@...abs.org>,
Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v2 2/5] KVM: add KVM request variants without barrier
2017-02-27 11:18+0100, David Hildenbrand:
> Am 27.02.2017 um 11:02 schrieb David Hildenbrand:
>> Am 24.02.2017 um 20:49 schrieb Radim Krčmář:
>>> The leading underscores denote that the call is just a bitop wrapper.
>>
>> Actually, the leading underscore is misleading
>>
>> If we want to match the semantics of set/test/clear_bit, using a leading
>> underscore might feel like using the non-atomic variants like
>> __clear_bit and friends.
>>
>> I'd prefer to simply drop the underscore.
>>
>
> Okay, this is not really possible for __kvm_request_set(). Hm.....
Yeah, requests are always atomic, but have some extra cruft on top of
bit operations and underscores are similar in the sense of doing less
that the non-underscored version. Also, the underscores were something
to make its use look undesirable in the code.
kvm_request_set and kvm_request_test_and_clear use a barrier and
kvm_request_test could be expected to do so as well.
I think that a barrier makes no sense in kvm_request_clear, but called
it with underscores for consistency with others and also because I think
that some callers of could use a second thought.
Powered by blists - more mailing lists