linux-next: manual merge of the block tree with the drbd tree
Mark Brown
maintainerHi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_nl.c
between commit:
ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config")
from the drbd tree and commit:
630bbba45cfd3 ("drbd: use genl pre_doit/post_doit")
from the block tree.
These changes are both quite large and the conflicts substantial, ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config") in particular has a diffstat of:
drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------ 1 file changed, 5167 insertions(+), 2093 deletions(-)
which would be enormous even for a non-mechanical change, based on the size and a glance over the changelog it seems clear to me that it should be split up into a series of patches. This would make resolving the conflicts much more tractable as it would be clearer what each change is trying to accomplish.
630bbba45cfd3 ("drbd: use genl pre_doit/post_doit") is much less of a concern as while it's fairly large it is mostly mechanical.
Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
Quoted 8 lines · Mark Brown
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_nl.cbetween commit:
Quoted 7 lines
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config")from the drbd tree and commit:
630bbba45cfd3("drbd: use genl pre_doit/post_doit")from the block tree.
Christian... See previous reply on this.
Quoted 13 lines
These changes are both quite large and the conflicts substantial,
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config") in particular has a diffstat of:drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------ 1 file changed, 5167 insertions(+), 2093 deletions(-)which would be enormous even for a non-mechanical change, based on the size and a glance over the changelog it seems clear to me that it should be split up into a series of patches. This would make resolving the conflicts much more tractable as it would be clearer what each change is trying to accomplish.
Quoted 8 lines
630bbba45cfd3("drbd: use genl pre_doit/post_doit") is much less of a concern as while it's fairly large it is mostly mechanical.Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
It _should_ feed into there, for some reason their tree got added to -next rather than go the usual route.
Signature · 1 line
Jens Axboe
Mark Brown
maintainerQuoted 10 lines · Jens Axboe
Quoted 5 lines · Mark Brown
Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
It _should_ feed into there, for some reason their tree got added to -next rather than go the usual route.
It's fine and normal to have multiple levels of tree in -next, some trees like the soc tree even require that any pull requests sent to them have had some soaking in -next. It does look like this goes in as patches rather than pull requests though? That has more likelyhood of causing issues.
Am 25.03.26 um 16:41 schrieb Mark Brown:
Quoted 29 lines
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_nl.cbetween commit:
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config")from the drbd tree and commit:
630bbba45cfd3("drbd: use genl pre_doit/post_doit")from the block tree.
These changes are both quite large and the conflicts substantial,
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config") in particular has a diffstat of:drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------ 1 file changed, 5167 insertions(+), 2093 deletions(-)which would be enormous even for a non-mechanical change, based on the size and a glance over the changelog it seems clear to me that it should be split up into a series of patches. This would make resolving the conflicts much more tractable as it would be clearer what each change is trying to accomplish.
Quoted 8 lines
630bbba45cfd3("drbd: use genl pre_doit/post_doit") is much less of a concern as while it's fairly large it is mostly mechanical.Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
Ah, sorry, that's on me, I should have called ahead.
It's a long story: the DRBD changes in drbd-next (and thus linux-next) replay about 15 years of development history. The out-of-tree DRBD module got de-synced from the in-tree version, and never truly caught up. The gap just grew over the years, and we're trying to fix that now. That's how we ended up with the enormous patch series that is now in linux-next.
We submitted the preliminary series to linux-next to "test the waters" in regards to integration with the mainline kernel, CI checks, etc. This preliminary series still breaks some old userspace tooling, though, so we can't truly submit it "officially" yet.
And that is precisely what we are working on now: we intend on starting a new genetlink family that enables compatibility with both the old and new userspace tools. This will take some more time, we are taking the first preparing steps now (such as "drbd: use genl pre_doit/post_doit"). Since this is useful for the current in-tree module as well, we have decided to submit those patches "normally" via the block tree. And obviously that caused conflicts with the next tree, since that has not been rebased (yet).
Jens, how do you want to handle this?
Should I send the (technically working, but maybe old-userspace-breaking) DRBD 9 patch series to you so you can carry it in block/for-next? So far I was under the impression that these patches would be too large and unfinished for the block/for-next branch.
Mark, thanks for your efforts and please keep the drbd-next branch marked as broken for now. I will rebase the tree in the following days, and we'll see via which path it gets resubmitted.
Thanks,
Christoph
Signature · 3 lines
Christoph Böhmwalder LINBIT | Keeping the Digital World Running DRBD HA — Disaster Recovery — Software defined Storage
Quoted 39 lines · Christoph B?hmwalder
Am 25.03.26 um 16:41 schrieb Mark Brown:
Quoted 29 lines
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_nl.cbetween commit:
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config")from the drbd tree and commit:
630bbba45cfd3("drbd: use genl pre_doit/post_doit")from the block tree.
These changes are both quite large and the conflicts substantial,
ffa847f8ff11d("drbd: rework netlink interface for DRBD 9 multi-peer config") in particular has a diffstat of:drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------ 1 file changed, 5167 insertions(+), 2093 deletions(-)which would be enormous even for a non-mechanical change, based on the size and a glance over the changelog it seems clear to me that it should be split up into a series of patches. This would make resolving the conflicts much more tractable as it would be clearer what each change is trying to accomplish.
Quoted 8 lines
630bbba45cfd3("drbd: use genl pre_doit/post_doit") is much less of a concern as while it's fairly large it is mostly mechanical.Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
Quoted 8 lines
Ah, sorry, that's on me, I should have called ahead.
It's a long story: the DRBD changes in drbd-next (and thus linux-next) replay about 15 years of development history. The out-of-tree DRBD module got de-synced from the in-tree version, and never truly caught up. The gap just grew over the years, and we're trying to fix that now. That's how we ended up with the enormous patch series that is now in linux-next.
At least that's a worthy goal, I believe I have complained about that multiple times over the last couple of years :)
Quoted 14 lines
We submitted the preliminary series to linux-next to "test the waters" in regards to integration with the mainline kernel, CI checks, etc. This preliminary series still breaks some old userspace tooling, though, so we can't truly submit it "officially" yet.
And that is precisely what we are working on now: we intend on starting a new genetlink family that enables compatibility with both the old and new userspace tools. This will take some more time, we are taking the first preparing steps now (such as "drbd: use genl pre_doit/post_doit"). Since this is useful for the current in-tree module as well, we have decided to submit those patches "normally" via the block tree. And obviously that caused conflicts with the next tree, since that has not been rebased (yet).
Quoted 5 lines
Jens, how do you want to handle this?
Should I send the (technically working, but maybe old-userspace-breaking) DRBD 9 patch series to you so you can carry it inblock/for-next? So far I was under the impression that these patches would be too large and unfinished for theblock/for-nextbranch.
How about this - rebase it against for-7.1/block, and send the series. I can stash it in for-7.1/drbd, which can go into for-next. Then the separate tree can be dropped.
I won't submit the changes in for-7.1/drbd, but just expect you to send a new series against for-7.2/block when that is a thing. The 7.2 one should be closer to going upstream, and so forth. Within a few revisions of the mainline kernel, we'll get to the point where for-7.x/drbd can be included in the merge window pull request as well, and we're done at that point and future drbd changes will just get submitted against for-7.x/block like any other block driver.
?
Signature · 1 line
Jens Axboe
Am 25.03.26 um 17:30 schrieb Jens Axboe:
Quoted 19 lines · Christoph B?hmwalder
Quoted 5 lines
Jens, how do you want to handle this?
Should I send the (technically working, but maybe old-userspace-breaking) DRBD 9 patch series to you so you can carry it inblock/for-next? So far I was under the impression that these patches would be too large and unfinished for theblock/for-nextbranch.How about this - rebase it against for-7.1/block, and send the series. I can stash it in for-7.1/drbd, which can go into for-next. Then the separate tree can be dropped.
I won't submit the changes in for-7.1/drbd, but just expect you to send a new series against for-7.2/block when that is a thing. The 7.2 one should be closer to going upstream, and so forth. Within a few revisions of the mainline kernel, we'll get to the point where for-7.x/drbd can be included in the merge window pull request as well, and we're done at that point and future drbd changes will just get submitted against for-7.x/block like any other block driver.
Quoted 2 lines
?
Sounds like a plan. I'll send the rebased series this week. We already have a few "get it closer to going upstream" patches in the pipeline targeted for the 7.1 and 7.2 merge windows, but none of them are truly ready yet. So this approach would fit very well.
Exactly, once we are done with all this we will adopt a "normal" upstream-first dev approach again. We've already discussed changes to our internal workflow to make sure we never digress this far from upstream again -- I think that's in all our interests :)
Thanks,
Christoph
Signature · 3 lines
Christoph Böhmwalder LINBIT | Keeping the Digital World Running DRBD HA — Disaster Recovery — Software defined Storage
Mark Brown
maintainerQuoted 15 lines · Christoph Böhmwalder
Am 25.03.26 um 17:30 schrieb Jens Axboe:
Quoted 7 lines
I won't submit the changes in for-7.1/drbd, but just expect you to send a new series against for-7.2/block when that is a thing. The 7.2 one should be closer to going upstream, and so forth. Within a few revisions of the mainline kernel, we'll get to the point where for-7.x/drbd can be included in the merge window pull request as well, and we're done at that point and future drbd changes will just get submitted against for-7.x/block like any other block driver.
Sounds like a plan. I'll send the rebased series this week. We already have a few "get it closer to going upstream" patches in the pipeline targeted for the 7.1 and 7.2 merge windows, but none of them are truly ready yet. So this approach would fit very well.
Quoted 4 lines
Exactly, once we are done with all this we will adopt a "normal" upstream-first dev approach again. We've already discussed changes to our internal workflow to make sure we never digress this far from upstream again -- I think that's in all our interests :)
So I should just drop the drbd tree entirely from tomorrow?
Am 25.03.26 um 17:57 schrieb Mark Brown:
Quoted 16 lines · Christoph Böhmwalder
Quoted 14 lines
Am 25.03.26 um 17:30 schrieb Jens Axboe:
Quoted 7 lines
I won't submit the changes in for-7.1/drbd, but just expect you to send a new series against for-7.2/block when that is a thing. The 7.2 one should be closer to going upstream, and so forth. Within a few revisions of the mainline kernel, we'll get to the point where for-7.x/drbd can be included in the merge window pull request as well, and we're done at that point and future drbd changes will just get submitted against for-7.x/block like any other block driver.
Sounds like a plan. I'll send the rebased series this week. We already have a few "get it closer to going upstream" patches in the pipeline targeted for the 7.1 and 7.2 merge windows, but none of them are truly ready yet. So this approach would fit very well.
Quoted 6 lines
Quoted 4 lines
Exactly, once we are done with all this we will adopt a "normal" upstream-first dev approach again. We've already discussed changes to our internal workflow to make sure we never digress this far from upstream again -- I think that's in all our interests :)
So I should just drop the drbd tree entirely from tomorrow?
I guess that would actually be the easiest path then, yes. Sorry for the churn on your side.
Signature · 3 lines
Christoph Böhmwalder LINBIT | Keeping the Digital World Running DRBD HA — Disaster Recovery — Software defined Storage
Mark Brown
maintainerQuoted 5 lines · Christoph Böhmwalder
Am 25.03.26 um 17:57 schrieb Mark Brown:
Quoted 1 line
So I should just drop the drbd tree entirely from tomorrow?
I guess that would actually be the easiest path then, yes.
OK, I'll do that.
Quoted 1 line
Sorry for the churn on your side.
No problem.
Quoted 28 lines · Christoph B?hmwalder
Am 25.03.26 um 17:30 schrieb Jens Axboe:
Quoted 19 lines · Christoph B?hmwalder
Quoted 5 lines
Jens, how do you want to handle this?
Should I send the (technically working, but maybe old-userspace-breaking) DRBD 9 patch series to you so you can carry it inblock/for-next? So far I was under the impression that these patches would be too large and unfinished for theblock/for-nextbranch.How about this - rebase it against for-7.1/block, and send the series. I can stash it in for-7.1/drbd, which can go into for-next. Then the separate tree can be dropped.
I won't submit the changes in for-7.1/drbd, but just expect you to send a new series against for-7.2/block when that is a thing. The 7.2 one should be closer to going upstream, and so forth. Within a few revisions of the mainline kernel, we'll get to the point where for-7.x/drbd can be included in the merge window pull request as well, and we're done at that point and future drbd changes will just get submitted against for-7.x/block like any other block driver.
Quoted 2 lines
?
Sounds like a plan. I'll send the rebased series this week. We already have a few "get it closer to going upstream" patches in the pipeline targeted for the 7.1 and 7.2 merge windows, but none of them are truly ready yet. So this approach would fit very well.
Quoted 4 lines
Exactly, once we are done with all this we will adopt a "normal" upstream-first dev approach again. We've already discussed changes to our internal workflow to make sure we never digress this far from upstream again -- I think that's in all our interests :)
OK, all on the same page then! Thanks.
Signature · 1 line
Jens Axboe
Mark Brown
maintainerQuoted 5 lines · Mark Brown
Since I've got no confidence in my ability to do so rather than resolving this I have marked the DRBD driver as BROKEN for today (there's a half completed merge in the tree which shows how far I got) and I will reorder the drbd tree after the block tree going forward since it seems to feed into there.
Actually I had to redo the merge so the partial resolution got lost, sorry.