Re: [PATCH v14 1/9] xen: introduce generic non-atomic test_*bit()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.07.2024 10:47, Oleksii wrote:
> On Wed, 2024-07-03 at 09:24 +0200, Jan Beulich wrote:
>> On 02.07.2024 13:01, Oleksii Kurochko wrote:
>>> The following generic functions were introduced:
>>> * test_bit
>>> * generic__test_and_set_bit
>>> * generic__test_and_clear_bit
>>> * generic__test_and_change_bit
>>>
>>> These functions and macros can be useful for architectures
>>> that don't have corresponding arch-specific instructions.
>>>
>>> Also, the patch introduces the following generics which are
>>> used by the functions mentioned above:
>>> * BITOP_BITS_PER_WORD
>>> * BITOP_MASK
>>> * BITOP_WORD
>>> * BITOP_TYPE
>>>
>>> The following approach was chosen for generic*() and arch*() bit
>>> operation functions:
>>> If the bit operation function that is going to be generic starts
>>> with the prefix "__", then the corresponding generic/arch function
>>> will also contain the "__" prefix. For example:
>>>  * test_bit() will be defined using arch_test_bit() and
>>>    generic_test_bit().
>>>  * __test_and_set_bit() will be defined using
>>>    arch__test_and_set_bit() and generic__test_and_set_bit().
>>>
>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> Changes in V14:
>>>  - Nothing changed. Only Rebase.
>>> ---
>>> Changes in V13:
>>>  - add Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> Changes in V12:
>>>  - revert change of moving the definition of BITS_PER_BYTE from
>>> <arch>/bitops.h to xen/bitops.h.
>>>    ( a separate patch will be provided to put BITS_PER_BYTE to
>>> proper place )
>>
>> Oleksii - seeing that this wasn't actually done (as noticed by
>> Michal), my
>> intention would be to adjust the patch while committing. Please let
>> me know
>> shortly if there is anything I'm overlooking, possibly implying the
>> intended
>> adjustment shouldn't be done (and further suggesting that the
>> revision log
>> then is wrong and/or incomplete). As indicated, I'll need another
>> reply of
>> yours here (and for subsequent patches; maybe simply the entire
>> series)
>> anyway, as a release-ack is still missing.
> The changes log is correct.
> 
> If we are going to drop BITS_PER_BYTE in xen/bitops.h, then it will
> need to be added back to <arm>/bitops.h as it was done in "Changes in
> V12". (This change was lost somewhere due to an incorrect rebase by
> me.).
> 
> Regarding Release-Acked-By, I was okay to have this patch series during
> Soft Code Freeze but now we are in Hard Code Freeze state where I am
> expecting to see only bug/security fixes.
> 
> Unfortunately, it would be better based on current state of release to
> wait 4.20 staging branch.
> 
> Based on that let me know if you want me to sent a new patch series
> version with BITS_PER_BYTE adjustments or it still could be fix during
> the commit when 4.20 staging will be available?

I'm okay either way.

Jan