The day when the mmap() flags bit space is exhausted seems to be slowly but steadily approaching. When that happens...
Why not change the flags type from int to a new aliased data type, e.g. flagset_t1 (itself typedef'ed to int currently, and then later, when needed, re-typedefed to int64_t)?
Yes, I realize this is easier said than done, and it would require changes to both userspace and the kernel, but if the change were made now then it would get glibc and friends time to work out issues associated with the API change. If this is too radical or ugly change to make, then I'll certainly plead guilty to being naïve.
In both system calls, the huge page size is encoded in the six bits from 26 through to 31
I, for one, think Andi's method of storing numeric values in the high-order bits of flags is quite elegant2.
1 My motivation for suggesting "flagset_t" was based on seeing all the *_t types contained within a struct stat (see stat(2) ).
2 I've used a similar technique in storing both options flags and numeric values in a single 32-bit integer when using getopt(3).
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds