On 2026-04-16, Dorjoy Chowdhury <[email protected]> wrote: > On Thu, Apr 16, 2026 at 7:52 PM Jori Koolstra <[email protected]> wrote: > > > > On Sat, Mar 28, 2026 at 11:22:22PM +0600, Dorjoy Chowdhury wrote: > > > diff --git a/arch/alpha/include/uapi/asm/fcntl.h > > > b/arch/alpha/include/uapi/asm/fcntl.h > > > index 50bdc8e8a271..fe488bf7c18e 100644 > > > --- a/arch/alpha/include/uapi/asm/fcntl.h > > > +++ b/arch/alpha/include/uapi/asm/fcntl.h > > > @@ -34,6 +34,7 @@ > > > > > > #define O_PATH 040000000 > > > #define __O_TMPFILE 0100000000 > > > +#define OPENAT2_REGULAR 0200000000 > > > > > > > I don't quite understand why we are adding OPENAT2_REGULAR inside the > > O_* flag range. Wasn't this supposed to be only supported for openat2()? > > If so, I don't see the need to waste an O_* flag bit. But maybe I am > > missing something. > > > > Yes, OPENAT2_REGULAR is only supported for openat2. I am not sure if I > got a specific review to not add OPENAT2_REGULAR in the O_* flag 32 > bit range. But as far as I understand, for the old open system calls > we can't easily add new O_* flags as the older codepaths don't strip > off unknown bits which openat2 does. It's not easy to add new O_* > flags for the old open system calls since that could break userspace > programs. So I guess it's okay to add OPENAT2_REGULAR in the 32 bits > range anyway? (Also lots of code paths take 32bit flags param right > now and those would need changing to take uint64_t instead but this is > of course not a reason to not add the new flag outside of the 32 > bits).
Oh, I didn't notice that this wasn't mentioned here, we had a separate discussion about it in a thread with Jori and I must've assumed we discussed it in both. (My brain is also really not wired up to read large octal values easily.) While it is hard to add new O_* flags (hence OPENAT2_REGULAR), it's not /impossible/ (Jori has a patch for OPENAT2_EMPTY_PATH that is safe to add to O_* flags because of some fun historical coincidences). I would have a slight preference towards segregating the bits, ideally at the top end but even 1<<31 would've been nice. Then again, I'm not too fussed either way to be honest... -- Aleksa Sarai https://www.cyphar.com/
signature.asc
Description: PGP signature
