On Thu, Nov 30, 2023 at 6:13 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > On Wed, 2023-11-29 at 19:46 +0100, Roberto Sassu wrote: > > On 11/29/2023 6:22 PM, Paul Moore wrote: > > > On Wed, Nov 29, 2023 at 7:28 AM Roberto Sassu wrote: > > >> On Mon, 2023-11-20 at 16:06 -0500, Paul Moore wrote: > > >>> On Mon, Nov 20, 2023 at 3:16 AM Roberto Sassu wrote: > > >>>> On Fri, 2023-11-17 at 15:57 -0500, Paul Moore wrote: > > >>>>> On Nov 7, 2023 Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: ... > First you suggested lumping IMA and EVM together, dropping EVM > entirely. Now you're suggesting making EVM dependent on IMA. Please > stop. Welcome to design discussions and brainstorming where changing opinions and unexpected suggestions are part of the process. When we are faced with difficult problems I want everyone to think creatively and not be afraid to adjust their thinking based on their changing understanding and the ongoing discussion. Asking people to stop thinking outside the status quo is not a good way to solve challenging problems. > EVM and IMA should remain independent of each other. A few posts back that was the goal, then Roberto mentioned EVM breakage when IMA was disabled so I simply asked if it was worth "revisit the basic idea of if it even makes sense to enable EVM without IMA?". A bad answer to that question is what you provided above (and to be fair, we are all guilty of that at times), a good answer is to explain why IMA and EVM need to remain independent with bonus points awarded for realistic use cases that support the assertion of independence. > > >> Regarding the LSM order, I would take Casey's suggestion of introducing > > >> LSM_ORDER_REALLY_LAST, for EVM. > > > > > > Please understand that I really dislike that we have imposed ordering > > > constraints at the LSM layer, but I do understand the necessity (the > > > BPF LSM ordering upsets me the most). I really don't want to see us > > > make things worse by adding yet another ordering bucket, I would > > > rather that we document it well and leave it alone ... basically treat > > > it like the BPF LSM (grrrrrr). > > > > Uhm, that would not be possible right away (the BPF LSM is mutable), > > remember that we defined LSM_ORDER_LAST so that an LSM can be always > > enable and placed as last (requested by Mimi)? > > Making EVM a full fledged LSM was contingent on two things - EVM always > being enabled if configured and being the last LSM. Using capability > as a precedent for ordering requirement, Mickaël suggested defining > LSM_ORDER_LAST, which you agreed to. It sounds like you're > backtracking on an agreement. I not only agreed to LSM_ORDER_LAST, I merged the code and it is currently in Linus' tree. See my last reply to Roberto; I see no reason to change that. I never would have merged that code or sent it to Linus if I didn't feel it was necessary. I'm guessing that you misread my reply above (perhaps you missed the "another" in "... I really don't want to see us make things worse by adding yet another ordering bucket ..."), but regardless of that, I want to deal with your "backtracking" comment. Similar to my comments above about brainstorming, I don't want people to feel that they can't change their mind about something. Call it backtracking if you want (although that has a negative connotation for many), but I want people to feel free to adjust their opinions as they learn more about something or as the conversation evolves. I believe this is the primary (only?) way for us to reach consensus on challenging problems. If you are uncomfortable with new, different, and changing ideas this may not be the right place for you. I might suggest a career in politics as an alternative. -- paul-moore.com
