ANN: new LSM guidelines

[Paul Moore]

On Tue, Sep 12, 2023 at 3:00 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Sep 12, 2023 at 2:40 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> > On 9/12/2023 11:08 AM, Paul Moore wrote:
> > >
> > > Once again, we've already discussed this many, many times: out-of-tree
> > > LSMs are not the priority and that is not going to change.  One
> > > corollary of this is that we are not going to assign LSM IDs to LSMs
> > > that remain out-of-tree as this would negatively impact the LSM layer
> > > by cluttering/depleting the LSM ID space.  LSMs that are working
> > > towards integration with the upstream Linux kernel can self-assign a
> > > temporary LSM ID which will be finalized upon merging in the LSM tree.
> > > Based on all of the arguments you have already submitted - and let us
> > > be very clear: you are the only one speaking out against this - I see
> > > no reason to change this policy.
> >
> > I won't say this is a great idea, or that I endorse it, but we could
> > allocate a range of LSM ID values ( 10000 - 10999 ? ) that we promise
> > will never be given to an upstream LSM. We wouldn't make any guarantees
> > about conflicts otherwise. These could be used by LSMs before they are
> > accepted upstream or by LSMs that don't have upstream aspirations. I
> > seriously doubt that anyone using such an LSM is going to be mixing
> > multiple such LSMs without being capable of managing ID conflicts.
>
> Not a crazy idea.  I had debated something similar, a reserved
> "private use" or "experimentation" range; there is definitely
> precedence for that in other areas, e.g. network protocols.  What held
> me back is that invariably folks will want to create long-term
> persistent registrations against this space for their out-of-tree LSMs
> which would require some sort of unofficial, adhoc registration
> authority which starts to get a bit silly in my opinion (the
> registration authority for the Linux kernel API is the upstream Linux
> kernel community).
>
> Temporary assignments while a LSM is undergoing the review-revision
> cycle on its way to being merged is something different and if we need
> a couple of reserved numbers for that (one or two MAX) we can consider
> that, but I don't expect this to be a major problem in practice.  LSMs
> that are in this transient pre-merge state shouldn't be used for
> production purposes and thus a LSM ID change on merging shouldn't be a
> problem.

Just to avoid any confusion on this, a reserved range at this point in
time is currently a NACK from my perspective.  I am open to consider
reserving one, maybe two, ID numbers in the future for in-development
LSMs if we start having problems, but I will need to see persistent
problems first.

-- 
paul-moore.com