RE: 2.6.22-rc1-mm1 - s390 vs. md

["Williams, Dan J" <dan.j.williams@intel.com>]

> From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com]
> 
> On Tue, 15 May 2007 20:19:14 -0700,
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
> rc1/2.6.22-rc1-mm1/
> 
> Doesn't build on s390 when selecting the md menu:
> 
> drivers/built-in.o(.text+0x438ae): In function `async_xor':
> : undefined reference to `dma_map_page'
> drivers/built-in.o(.text+0x43aac): In function `async_xor':
> : undefined reference to `dma_map_page'
> drivers/built-in.o(.text+0x43d2e): In function `async_xor_zero_sum':
> : undefined reference to `dma_map_page'
> drivers/built-in.o(.text+0x43f50): In function `async_memcpy':
> : undefined reference to `dma_map_page'
> drivers/built-in.o(.text+0x43f90): In function `async_memcpy':
> : undefined reference to `dma_map_page'
> drivers/built-in.o(.text+0x4423e): more undefined references to
> `dma_map_page' follow
> 
> This is caused by the following in drivers/md/Kconfig:
> 
> menuconfig MD
>         bool "Multiple devices driver support (RAID and LVM)"
>         depends on BLOCK
>         select ASYNC_TX_DMA
>         help
>           Support multiple physical spindles through a single logical
device.
>           Required for RAID and logical volume management.

The rationale for the 'select' here was to attempt to prevent user
confusion since MD_RAID456 now depends on ASYNC_TX_DMA.

> 
> ASYNC_TX_DMA is defined in drivers/dma/Kconfig, which has
> 
> menu "DMA Engine support"
>         depends on !S390
> 
> but unfortunately ASYNC_TX_DMA depends neither on the menu nor
> on !S390. (I think it was just an unknown symbol on s390 before
> Martin's Kconfig rework, so I could build older -mm kernels.)
> 
> Currently, the only md stuff depending on ASYNC_TX_DMA is MD_RAID456
> (which means it doesn't work on s390 anymore, which is bad enough).
> With the select statement, no md stuff can be build on s390 at all
(and
> I really don't see why ASYNC_TX_DMA should be forced upon all md
> users)...

I agree it should not be forced on all users, I will push the following
change:

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 4a1b77e..fd29a54 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -8,7 +8,6 @@ menu "Multi-device support (RAID and LVM)"

 config MD
        bool "Multiple devices driver support (RAID and LVM)"
-       select ASYNC_TX_DMA
        help
          Support multiple physical spindles through a single logical
device.
          Required for RAID and logical volume management.
@@ -109,7 +108,8 @@ config MD_RAID10

 config MD_RAID456
        tristate "RAID-4/RAID-5/RAID-6 mode"
-       depends on BLK_DEV_MD && ASYNC_TX_DMA
+       depends on BLK_DEV_MD
+       select ASYNC_TX_DMA
        ---help---
          A RAID-5 set of N drives with a capacity of C MB per drive
provides
          the capacity of C * (N - 1) MB, and protects against a failure

However this still will not allow s390 to build MD_RAID456.  This
dependency is in place because the xor.o object has moved from
drivers/md to drivers/dma.  The goal of the interface is to support
using offload engines when they are present, and use software routines
(like xor_block) when engines are not available.  In other words, the
intent is that DMA_ENGINE=n && ASYNC_TX_DMA=y is a valid configuration.

Can we rework the !S390 change to the DMA_ENGINE menu?  It seems to me
that S390 should follow the ARM example and only enable the driver menus
they want in arch/s390/Kconfig, no?

...

On a closer look, it seems async_tx should be its own directory like
crypto...  I'll post the incremental changes to the md-accel git tree
for review.

Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/