ANN: new LSM guidelines

[Kees Cook]

On Mon, Sep 25, 2023 at 09:55:47AM +0900, Tetsuo Handa wrote:
> On 2023/09/13 4:00, Paul Moore 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.
> 
> Like Kees Cook said, we don't need to worry about depleting the LSM ID space
> because lsm_id::id is a u64. We only need to worry about cluttering/conflicting
> the values.

Right, this will go one of two ways:

1) author: "Hello, here is a new LSM I'd like to upstream, here it is. I assigned
            it the next LSM ID."
   maintainer(s): "Okay, sounds good. *review*"

2) author: "Hello, here is an LSM that has been in active use at $Place,
            and we have $Xxx many userspace applications that we cannot easily
            rebuild. We used LSM ID $Value that is far away from the sequential
            list of LSM IDs, and we'd really prefer to keep that assignment."
  maintainer(s): "Okay, sounds good. *review*"

No problems detected.

-Kees

-- 
Kees Cook