5 ms·

People should read it: "... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at t

by mmooss 2y ago

People should read it: "... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ... Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling. Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ... We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them. We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ... There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."

bonzini 2y ago
I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions (https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enjellic.com/ https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
- mmooss 2y ago
  That's version 4. Here's version 2, which looks like the first patch submission: https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/ https://lore.kernel.org/linux-security-module/20230204050954...
  - bonzini 2y ago
    7000 is not a lot better.
    - vaidhy 2y ago
      Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
      - macNchz 2y ago
        I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
        raverbashing 2y ago
        There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
        bonzini 2y ago
        > Not using email patches GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes? Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
- tw1984 2y ago
  no feedback whatsoever for 2 months - just because it was 17k lines - and you are blindly defending it? if you don't know what you are posting & talking about, then maybe you shouldn't. if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones. surely that won't take more than 45 seconds. still too hard to get the point?
  - bonzini 2y ago
    > if you don't know what you are posting & talking about, then maybe you shouldn't I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about. The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it. A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
    - Lerc 2y ago
      Surely if there were insufficient established context for a reviewer to easily follow a large patch the correct response would be a swift rejection with a request that such context be established prior to submitting again. It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
      - bonzini 2y ago
        It's very easy to develop tunnel vision when working remotely with people you've not even ever met. It's happened to me multiple times and there's a very high chance that this is happening here.
- HumblyTossed 2y ago
  17KLoC? Maybe he should consider they’re probably still reviewing it through bloody eyes. But seriously I wouldn’t want to review that much code.
  - cutemonster 2y ago
    I'd get mildly angry if someone sent a giant patch without having discussed with me first. (Not working with any kernel things) But a quicker "no, don't have time, probably never will" response would have been nice I guess?
mmooss 2y ago
A maintiner's perpsecitive on the above: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
- jorvi 2y ago
  Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.

by mmooss 2y ago

bonzini 2y ago

I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions (https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enjellic.com/ https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)

mmooss 2y ago
That's version 4. Here's version 2, which looks like the first patch submission: https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/ https://lore.kernel.org/linux-security-module/20230204050954...
- bonzini 2y ago
  7000 is not a lot better.
  - vaidhy 2y ago
    Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
    - macNchz 2y ago
      I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
      - raverbashing 2y ago
        There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
        bonzini 2y ago
        > Not using email patches GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes? Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
tw1984 2y ago
no feedback whatsoever for 2 months - just because it was 17k lines - and you are blindly defending it? if you don't know what you are posting & talking about, then maybe you shouldn't. if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones. surely that won't take more than 45 seconds. still too hard to get the point?
- bonzini 2y ago
  > if you don't know what you are posting & talking about, then maybe you shouldn't I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about. The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it. A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
  - Lerc 2y ago
    Surely if there were insufficient established context for a reviewer to easily follow a large patch the correct response would be a swift rejection with a request that such context be established prior to submitting again. It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
    - bonzini 2y ago
      It's very easy to develop tunnel vision when working remotely with people you've not even ever met. It's happened to me multiple times and there's a very high chance that this is happening here.
HumblyTossed 2y ago
17KLoC? Maybe he should consider they’re probably still reviewing it through bloody eyes. But seriously I wouldn’t want to review that much code.
- cutemonster 2y ago
  I'd get mildly angry if someone sent a giant patch without having discussed with me first. (Not working with any kernel things) But a quicker "no, don't have time, probably never will" response would have been nice I guess?

mmooss 2y ago

A maintiner's perpsecitive on the above: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...

jorvi 2y ago
Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.