Re: [PATCH 1/2] drbd: fix rdma dependency

"Arnd Bergmann" <[email protected]> Wed, 18 Mar 2026 16:31:31 +0100
Newsgroups dev.linux.lists.drbd-dev,org.kernel.vger.linux-block,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Wed, Mar 18, 2026, at 16:24, Christoph Böhmwalder wrote:
> Am 18.03.26 um 11:48 schrieb Arnd Bergmann:
>
> Seems like we raced here, I already (supposedly?) fixed this on the
> drbd-next branch.

Ok, I assume that will be in linux-next

> My fix is this Kconfig:
>
> config BLK_DEV_DRBD_RDMA
> 	tristate "DRBD RDMA transport"
> 	depends on BLK_DEV_DRBD && INFINIBAND_ADDR_TRANS
> 	help
>
> 	  RDMA transport support for DRBD. This enables DRBD replication
> 	  over RDMA-capable networks for lower latency and higher throughput.
>
> 	  If unsure, say N.
>
> And then just this in the Makefile:
>
> obj-$(CONFIG_BLK_DEV_DRBD_RDMA) += drbd_transport_rdma.o
>
> That should be equivalent, right?

It's close but not the same: 

- INFINIBAND_ADDR_TRANS is a 'bool' symbol that can still be =y
  when CONFIG_INFINIBAND=m, so you'd still fail to build
  BLK_DEV_DRBD_RDMA. You still need a dependency on INFINIBAND
  (the tristate symbol) itself, though you probably also
  need the INFINIBAND_ADDR_TRANS one that I missed

- I incorrectly assumed from the earlier Makefile logic
  that the rdma transport exports symbols that are used
  by the common drbd code, but I now see that the opposite
  is the case. The difference is that for the case of
  BLK_DEV_DRBD=y, CONFIG_INFINIBAND=m, my version force-disabled
  the RDMA transport, while it should be in a loadable module.

It seems both versions are wrong then, but just adding
'depends on INFINIBAND' on top of yours should fix it.

        Arnd