[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0C7297FA1D2D244A9C7F6959C0BF1E5201DB0584@azsmsx413.amr.corp.intel.com>
Date: Wed, 16 May 2007 10:21:25 -0700
From: "Williams, Dan J" <dan.j.williams@...el.com>
To: "Cornelia Huck" <cornelia.huck@...ibm.com>,
"Andrew Morton" <akpm@...ux-foundation.org>
Cc: <linux-kernel@...r.kernel.org>, "NeilBrown" <neilb@...e.de>,
"Martin Schwidefsky" <schwidefsky@...ibm.com>,
"linux-s390" <linux-s390@...r.kernel.org>
Subject: RE: 2.6.22-rc1-mm1 - s390 vs. md
> From: Cornelia Huck [mailto:cornelia.huck@...ibm.com]
>
> On Tue, 15 May 2007 20:19:14 -0700,
> Andrew Morton <akpm@...ux-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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists