On Wed, Nov 9, 2022 at 7:57 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 11/9/2022 3:33 PM, Paul Moore wrote: ... > > My reason for > > doing so is rather simple, we're going to treat the ID as a 32-bit > > value so we have *plenty* of room (just the thought of supporting +4 > > billion unique LSMs is comically insane), and I'd like to try and > > leave some space for yet-undetermined "special" things that we might > > need to convey in the LSM syscalls. For example, this would allow us > > to convey additional information to userspace when an application > > asked for labeling information using one of these reserved LSM IDs; > > applications which did not know (or care) about the special ID would > > continue to function normally but augmented/new applications would be > > able to make sense of the additional information ... and we wouldn't > > have to add a new syscall to do it. > > I don't see how > > #define LSM_ID_SPECIAL 2 > > is better than > > #define LSM_ID_SPECIAL 13 > > There's no reason to "group" LSM_ID values, nor have a range of them. > Really, I don't care one way or the other. I will bend to whatever will > is stronger. The token values are not intended to be grouped in any sort of range, it is just easier to say values 0-32 are reserved that create 33 macro defines like LSM_ID_RESERVED1..LSM_ID_RESERVED32. The actual token values shouldn't really mean anything, we could randomly assign them if that helps get my point across, I just want a few reserved numbers in the token space to leave room for future unknowns. It's not like I'm suggesting something that has never been done before :) -- paul-moore.com
