On Wed, Mar 19, 2025 at 09:43:06AM +0530, Anshuman Khandual wrote: > > > On 3/19/25 09:04, Anshuman Khandual wrote: > > On 3/19/25 07:16, Yury Norov wrote: > >> + Catalin Marinas, ARM maillist > >> > >> Hi Catalin and everyone, > > > > Hello Yury, > > > >> > >> Anshuman Khandual asked me to merge GENMASK_U128() saying it's > >> important for ARM to stabilize API. While it's a dead code, I > >> accepted his patch as he promised to add users shortly. > >> > >> Now it's more than half a year since that. There's no users, > >> and no feedback from Anshuman. > > > > My apologies to have missed your email earlier. Please find response > > for the earlier email below as well. > > > >> > >> Can you please tell if you still need the macro? I don't want to > >> undercut your development, but if you don't need 128-bit genmasks > >> there's no reason to have a dead code in the uapi. > > > > The code base specifically using GENMASK_U128() has not been posted > > upstream (probably in next couple of months or so) till now, except > > the following patch which has been not been merged and still under > > review and development. > > > > https://lore.kernel.org/lkml/20240801054436.612024-1-anshuman.khandual@xxxxxxx/ > > > >> > >> Thanks, > >> Yury > >> > >> On Wed, Mar 05, 2025 at 10:22:47AM -0500, Yury Norov wrote: > >>> + Anshuman Khandual <anshuman.khandual@xxxxxxx> > >>> > >>> Anshuman, > >>> > >>> I merged your GENMASK_U128() because you said it's important for your > >>> projects, and that it will get used in the kernel soon. > >>> > >>> Now it's in the kernel for more than 6 month, but no users were added. > >>> Can you clarify if you still need it, and if so why it's not used? > > > > We would need it but although the code using GENMASK_U128() has not been > > posted upstream. > > > >>> > >>> As you see, people add another fixed-types GENMASK() macros, and their > >>> implementation differ from GENMASK_U128(). > > > > I will take a look. Is GENMASK_U128() being problematic for the this new > > scheme ? > > > >>> > >>> My second concern is that __GENMASK_U128() is declared in uapi, while > >>> the general understanding for other fixed-type genmasks is that they > >>> are not exported to users. Do you need this macro to be exported to > >>> userspace? Can you show how and where it is used there? > > > > No, not atleast right now. Ok, thanks. > > These were moved into uapi subsequently via the following commit. > > > > 21a3a3d015aee ("tools headers: Synchronize {uapi/}linux/bits.h with the kernel sources") > > > > But in general GENMASK_U128() is needed for generating 128 bit page table > > entries, related flags and masks whether in kernel or in user space for > > writing kernel test cases etc. > > In the commit 947697c6f0f7 ("uapi: Define GENMASK_U128"), GENMASK_U128() gets defined > using __GENMASK_U128() which in turn calls __BIT128() - both of which are defined in > UAPI headers inside (include/uapi/linux/). > > Just wondering - are you suggesting to move these helpers from include/uapi/linux/ to > include/linux/bits.h instead ? Vincent is working on fixed-width GENMASK_Uxx() based on GENMASK_TYPE(). https://lore.kernel.org/lkml/20250308-fixed-type-genmasks-v6-0-f59315e73c29@xxxxxxxxxx/T/ The series adds a general GENMASK_TYPE() in the linux/bits.h. I'd like all fixed-widh genmasks to be based on it. The implementation doesn't allow to move GENMASK_TYPE() the to uapi easily. There was a discussion regarding that, and for now the general understanding is that userspace doesn't need GENMASK_Uxx(). Are your proposed tests based on the in-kernel tools/ ? If so, linux/bits.h will be available for you. Vincent, Can you please experiment with moving GENMASK_U128() to linux/bits.h and switching it to GENMASK_TYPE()-based implementation? If it works, we can do it after merging of GENMASK_TYPE() and ancestors. Thanks, Yury
