Re: linux-next: manual merge of the block tree with the drbd tree

[Jens Axboe <axboe@kernel.dk>]

On 3/25/26 10:07 AM, Christoph B?hmwalder wrote:
> Am 25.03.26 um 16:41 schrieb Mark Brown:
>> Hi 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.
> 
> 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 :)

> 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.

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.

?

-- 
Jens Axboe