On Wed, Nov 9, 2022 at 7:57 PM Casey Schaufler [off-list ref] wrote:

On 11/9/2022 3:33 PM, Paul Moore wrote:

...

quoted

  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