[PATCH v4] linux: Add openat2 (BZ 31664)

[Adhemerval Zanella Netto]

On 28/08/25 10:43, Paul Eggert wrote:
> On 2025-08-28 01:42, Aleksa Sarai wrote:
>>> I still fail to understand how a hypothetical "give me the supported flags"
>>> openat2 flag would be useful enough to justify complicating the openat2 API
>>> today.
>> My only concern is that it would break recompiles if/when we change it
>> back.
> 
> OK, but from what I can see there's no identified possibility that openat2 will modify the objects its arguments point to, just as there's no identified possibility that plain openat will do so (in a hypothetical extension to remove unnecessary slashes from its filename argument, say).
> 
> In that case it's pretty clear that glibc should mark the open_how argument as pointer-to-const, just as glibc already marks the filename argument.

I am still not sure how a potentially CHECK_FIELDS feature would play with 
openat2 in the future, especially since glibc now prefers to first include 
the kernel headers before redefining a minimal API to the syscall usage 
(meaning that programs will have access to potentially new flags depending 
on the installed kernel header).

If the kernel intends to modify the open_how in the future, setting open_how 
as const will only add extra confusion. Users might be exposed to this feature 
without explicitly including the kernel headers.

Another option might to *not* include the kernel headers and keep syncing the 
kernel definitions on kernel releases (and maybe excluding flags that might 
modify the open_how). As Florian has said, this kind of mediation by glibc was 
historically time-consuming, complex, and subject to subtle bugs (and that's 
why we abandoned this over time).