On Mon, Apr 07, 2025 at 04:46:48PM +0200, David Hildenbrand wrote:
On 07.04.25 16:24, Liam R. Howlett wrote:
- Nikita Kalyazin kalyazin@amazon.com [250407 10:05]:
...
All of this is extremely confusing because the onus of figuring out what the final code will look like is put on the reviewer. As it is, we have issues with people not doing enough review of the code (due to limited time). One way to get reviews is to make the barrier of entry as low as possible.
I spent Friday going down a rabbit hole of patches referring to each other as dependencies and I gave up. It looks like I mistook one set of patches as required vs them requiring the same in-flight ones as your patches.
I am struggling to see how we can adequately support all of you given the way the patches are sent out in batches with dependencies - it is just too time consuming to sort out.
I'm happy to do whatever I can to make the review easier. I suppose the extreme case is to wait for the dependencies to get accepted, effectively serialising submissions, but that slows the process down significantly. For example, I received very good feedback on v1 and v2 of this series and was able to address it instead of waiting for the dependency. Would including the required patches directly in the series help? My only concern is in that case the same patch will be submitted multiple times (as a part of every depending series), but if it's better, I'll be doing that instead.
Don't resend patches that someone else is upstreaming, that'll cause other problems.
Three methods come to mind:
- As you stated, wait for the dependencies to land. This is will mean
what you are working against is well tested and won't change (and you won't have to re-spin due to an unstable base).
- Combine them into a bigger patch set. I can then pull one patch set
and look at the parts of interest to the mm side.
- Provide a git repo with the necessary changes together.
I think 2 and 3 together should be used for the guest_memfd patches. Someone needs to be managing these to send upstream. See the discussion in another patch set on guest_memfd here [1].
The issue is that most extensions are fairly independent from each other, except that they built up on Fuad's mmap support,
Sending all together as one thing might not be the best option.
Once basic mmap support is upstream, some of the extensions (e.g., directmap removal) can go in next.
So until that is upstream, I agree that tagging the stuff that builds up on that is the right thing to do, and providing git trees is another very good idea.
I'll prioritize getting Fuad's mmap stuff reviewed. (I keep saying that, I know)
Fwiw, b4 allows to specify dependencies so you can b4 shazam/am and it will pull in all prerequisite patches:
b4 prep --edit-deps Edit the series dependencies in your defined $EDITOR (or core.editor)