"David P. Reed via Bloat" <bloat@lists.bufferbloat.net> writes:
> (One such nightmare can be seen in LKML... Search for > dpr...@deepplum.com patch emails. I tried hard, was worn down, then > gave up, since I found a way to avoid the bug, in virtualization code > on x86, and gave up on getting it fixed after a year. Life is too > short. Went looking, since I think it's important to learn from such process failures (and you're certainly not the first to opine that getting patches into the kernel is challenging). I'm assuming you're referring to this series, right? https://lore.kernel.org/all/20200704203809.76391-4-dpr...@deepplum.com/ Which, to me, looks like it was pretty close to being accepted; another revision would probably have made the cut... ...In fact it seems those patches were later resurrected by Sean as part of this series, six months later: https://lore.kernel.org/all/20201231002702.2223707-1-sea...@google.com/ One of the patches retained your authorship and made it into the kernel in this commit: https://git.kernel.org/torvalds/c/53666664a305 So wouldn't necessarily call that a complete failure :) Seems the main process issue you hit here was a subsystem that was too resource constrained on the review side, which does sadly happen. The kernel process tends to heavily favour convenience of reviewers for the same reason (which is one of the reasons it can be off-putting to outsiders, so it's a bit of a chicken and egg situation...) -Toke _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat