[PATCH v3 12/29] mips: Add <bits/pagesize.h>

[Florian Weimer]

* Maciej W. Rozycki:

> On Sun, 29 Sep 2024, Florian Weimer wrote:
>
>> According to arch/mips/Kconfig in the Linux sources, MIPS supports
>> 4 KiB, 8 KiB, 16 KiB, 32 KiB, 64 KiB page sizes depending on
>> CPU/configuration.
>
>  OK as far as the MIPS/Linux port is concerned only.
>
>  Of these 4 KiB, 16 KiB, 64 KiB are standard MIPS architecture page sizes 
> (three of many), and 8 KiB, 32 KiB are a Cavium Octeon vendor extension (I 
> don't know offhand if there any other non-standard sizes supported by that 
> hardware).

Thank you for this information.

>>  sysdeps/mips/bits/pagesize.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>  create mode 100644 sysdeps/mips/bits/pagesize.h
>
>  NB other page sizes are architecturally supported by TLB MMU hardware, 
> from 1 KiB up to 256 TiB, but not by the MIPS port of Linux, so shouldn't 
> this be sysdeps/unix/sysv/linux/mips/bits/pagesize.h instead, so as not to 
> apply the limitations of MIPS/Linux to the generic MIPS architecture?

In theory, any architecture could have future CPUs that support larger
page sizes, so there is no absolute strict upper limit.  For
<sys/pagesize.h> to be useful to programmers, the maximum needs to
reflect what they can reasonably expect to matter during the life time
of the file format and application.

A good indicator of future directions for page size is what binutils ld
generates by default.  On Linux, the page size cannot really be larger
than what ld bakes into the binaries.

> "[...]  To avoid the overhead and loss of test coverage by accepting
> gaps everywhere, this series teaches glibc the possible range of page
> sizes for each supported architecture."
>
> (or indeed BZ referred) which of the alternatives I quote above is right, 
> i.e. I find "supported architecture" ambiguous here -- is it an OS port or 
> a CPU architecture?

It's the combination of both.

Thanks,
Florian