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 <[email protected]> >>> Reviewed-by: Jan Beulich <[email protected]> >>> --- >>> Changes in V14: >>> - Nothing changed. Only Rebase. >>> --- >>> Changes in V13: >>> - add Reviewed-by: Jan Beulich <[email protected]> >>> --- >>> 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
