On Fri, Aug 28, 2026 at 04:48:36PM +0000, Edgecombe, Rick P wrote: > On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote:
> > Yeah, it is. I can't think why someone would ask for that either, but > > equally it's more work to explicitly have a list of combinations we > > reject for policy reasons. At least on arm64 each permission just comes > > down to a separate bit in a control register so they're fully > > independent all the way down to the hardware. > If we want to have a unified API (Bill convinced me that we did, but maybe we > should have more discussion on this point), we will need to hammer out the > small > differences between the arch's. For technically supported, but nonsensical > combos. I'd think to resolve the differences by not supporting them. But I > mean, > it's not the end of the world. In the end we are just talking about confusing > a > handful of libc developers. They can be probably handle things. I think it's similar to differences due to architecture features - only arm64 supports _PUSH because it's the only one with that feature, users will have to work out something to do about that. If someone has a burning desire to lock weird feature combinations that can't be provided everywhere they'll have similar issues but I don't see much benefit in writing code we don't need to. We should specify what happens if the architecture can't do what was asked (return -EINVAL?) but I think it's reasonable to allow the exact restrictions to vary so long as the sensible cases all work.
signature.asc
Description: PGP signature
