2.6.0-test2 device mapper patchset

2.6.0-test2 device mapper patchset

[Joe Thornber]

A straight forward set of fixes, please merge.

- Joe

[Patch 1/6] dm: don't use MODULE_PARM

[Joe Thornber]

MODULE_PARM is deprecated in 2.6. Use the new module_param() macro.
[Kevin Corry]

--- diff/drivers/md/dm.c	2003-07-28 11:55:33.000000000 +0100
+++ source/drivers/md/dm.c	2003-07-31 11:13:11.000000000 +0100
@@ -8,6 +8,7 @@
 
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/blkpg.h>
 #include <linux/bio.h>
 #include <linux/mempool.h>
@@ -916,7 +917,7 @@
 module_init(dm_init);
 module_exit(dm_exit);
 
-MODULE_PARM(major, "i");
+module_param(major, uint, 0);
 MODULE_PARM_DESC(major, "The major number of the device mapper");
 MODULE_DESCRIPTION(DM_NAME " driver");
 MODULE_AUTHOR("Joe Thornber <thornber@sistina.com>");

[Patch 2/6] dm: remove blk.h include

[Joe Thornber]

Remove includes of <linux/blk.h>. This header is deprecated in 2.6.
[Kevin Corry]

--- diff/drivers/md/dm-ioctl-v1.c	2003-07-28 11:55:33.000000000 +0100
+++ source/drivers/md/dm-ioctl-v1.c	2003-07-31 11:13:18.000000000 +0100
@@ -12,7 +12,6 @@
 #include <linux/dm-ioctl.h>
 #include <linux/init.h>
 #include <linux/wait.h>
-#include <linux/blk.h>
 #include <linux/slab.h>
 #include <linux/devfs_fs_kernel.h>
 
--- diff/drivers/md/dm-ioctl-v4.c	2003-07-28 11:55:33.000000000 +0100
+++ source/drivers/md/dm-ioctl-v4.c	2003-07-31 11:13:18.000000000 +0100
@@ -11,7 +11,6 @@
 #include <linux/miscdevice.h>
 #include <linux/init.h>
 #include <linux/wait.h>
-#include <linux/blk.h>
 #include <linux/slab.h>
 #include <linux/devfs_fs_kernel.h>
 

[Patch 3/6] dm: decimal device num sscanf

[Joe Thornber]

The 2.4 version of Device-Mapper scans for device-numbers in decimal
instead of hex (in dm_get_device()). Update 2.6 so both versions use
the same behavior.  [Kevin Corry]

--- diff/drivers/md/dm-table.c	2003-07-28 11:55:33.000000000 +0100
+++ source/drivers/md/dm-table.c	2003-07-31 11:13:24.000000000 +0100
@@ -418,12 +418,12 @@
 	int r;
 	dev_t dev;
 	struct dm_dev *dd;
-	int major, minor;
+	unsigned int major, minor;
 
 	if (!t)
 		BUG();
 
-	if (sscanf(path, "%x:%x", &major, &minor) == 2) {
+	if (sscanf(path, "%u:%u", &major, &minor) == 2) {
 		/* Extract the major/minor numbers */
 		dev = MKDEV(major, minor);
 	} else {

[Patch 4/6] dm: 64 bit ioctl fixes

[Joe Thornber]

Update the ioctl32 handlers for the 64-bit architectures to recognize
the new Device-Mapper version 4 ioctls. The version 1 ioctls are still
there.  If/When the version 1 ioctls are removed, these same files
will need to be updated again.

I have been unable to test this patch yet, since I have not had any
luck getting 2.6.0-test2 to compile on my ppc64 box (not a dm-related
problem).  But the patch is pretty trivial, so I'm pretty confident it
will work. If anyone else can test this (on mips64, sparc64, parisc,
or x86-64), let me know if you have any problems.  [Kevin Corry]


--- diff/arch/mips64/kernel/ioctl32.c	2003-07-08 09:55:18.000000000 +0100
+++ source/arch/mips64/kernel/ioctl32.c	2003-07-31 11:13:30.000000000 +0100
@@ -1154,6 +1154,21 @@
 #endif /* CONFIG_SIBYTE_TBPROF */
 
 #if defined(CONFIG_BLK_DEV_DM) || defined(CONFIG_BLK_DEV_DM_MODULE)
+	#if defined(CONFIG_DM_IOCTL_V4)
+	IOCTL32_DEFAULT(DM_VERSION),
+	IOCTL32_DEFAULT(DM_REMOVE_ALL),
+	IOCTL32_DEFAULT(DM_LIST_DEVICES),
+	IOCTL32_DEFAULT(DM_DEV_CREATE),
+	IOCTL32_DEFAULT(DM_DEV_REMOVE),
+	IOCTL32_DEFAULT(DM_DEV_RENAME),
+	IOCTL32_DEFAULT(DM_DEV_SUSPEND),
+	IOCTL32_DEFAULT(DM_DEV_STATUS),
+	IOCTL32_DEFAULT(DM_DEV_WAIT),
+	IOCTL32_DEFAULT(DM_TABLE_LOAD),
+	IOCTL32_DEFAULT(DM_TABLE_CLEAR),
+	IOCTL32_DEFAULT(DM_TABLE_DEPS),
+	IOCTL32_DEFAULT(DM_TABLE_STATUS),
+	#else
 	IOCTL32_DEFAULT(DM_VERSION),
 	IOCTL32_DEFAULT(DM_REMOVE_ALL),
 	IOCTL32_DEFAULT(DM_DEV_CREATE),
@@ -1165,6 +1180,7 @@
 	IOCTL32_DEFAULT(DM_DEV_STATUS),
 	IOCTL32_DEFAULT(DM_TARGET_STATUS),
 	IOCTL32_DEFAULT(DM_TARGET_WAIT),
+	#endif
 #endif /* CONFIG_BLK_DEV_DM */
 
 COMPATIBLE_IOCTL(MTIOCTOP)			/* mtio.h ioctls  */
--- diff/arch/sparc64/kernel/ioctl32.c	2003-06-30 10:07:20.000000000 +0100
+++ source/arch/sparc64/kernel/ioctl32.c	2003-07-31 11:13:30.000000000 +0100
@@ -1546,6 +1546,21 @@
 COMPATIBLE_IOCTL(BNEPGETCONNLIST)
 COMPATIBLE_IOCTL(BNEPGETCONNINFO)
 /* device-mapper */
+#if defined(CONFIG_DM_IOCTL_V4)
+COMPATIBLE_IOCTL(DM_VERSION)
+COMPATIBLE_IOCTL(DM_REMOVE_ALL)
+COMPATIBLE_IOCTL(DM_LIST_DEVICES)
+COMPATIBLE_IOCTL(DM_DEV_CREATE)
+COMPATIBLE_IOCTL(DM_DEV_REMOVE)
+COMPATIBLE_IOCTL(DM_DEV_RENAME)
+COMPATIBLE_IOCTL(DM_DEV_SUSPEND)
+COMPATIBLE_IOCTL(DM_DEV_STATUS)
+COMPATIBLE_IOCTL(DM_DEV_WAIT)
+COMPATIBLE_IOCTL(DM_TABLE_LOAD)
+COMPATIBLE_IOCTL(DM_TABLE_CLEAR)
+COMPATIBLE_IOCTL(DM_TABLE_DEPS)
+COMPATIBLE_IOCTL(DM_TABLE_STATUS)
+#else
 COMPATIBLE_IOCTL(DM_VERSION)
 COMPATIBLE_IOCTL(DM_REMOVE_ALL)
 COMPATIBLE_IOCTL(DM_DEV_CREATE)
@@ -1557,6 +1572,7 @@
 COMPATIBLE_IOCTL(DM_DEV_STATUS)
 COMPATIBLE_IOCTL(DM_TARGET_STATUS)
 COMPATIBLE_IOCTL(DM_TARGET_WAIT)
+#endif
 /* And these ioctls need translation */
 HANDLE_IOCTL(HDIO_GETGEO_BIG_RAW, hdio_getgeo_big)
 /* NCPFS */
--- diff/include/linux/compat_ioctl.h	2003-07-11 09:39:50.000000000 +0100
+++ source/include/linux/compat_ioctl.h	2003-07-31 11:13:30.000000000 +0100
@@ -119,6 +119,20 @@
 COMPATIBLE_IOCTL(RESTART_ARRAY_RW)
 #ifdef CONFIG_BLK_DEV_DM
 /* DM */
+#ifdef CONFIG_DM_IOCTL_V4
+COMPATIBLE_IOCTL(DM_VERSION)
+COMPATIBLE_IOCTL(DM_LIST_DEVICES)
+COMPATIBLE_IOCTL(DM_DEV_CREATE)
+COMPATIBLE_IOCTL(DM_DEV_REMOVE)
+COMPATIBLE_IOCTL(DM_DEV_RENAME)
+COMPATIBLE_IOCTL(DM_DEV_SUSPEND)
+COMPATIBLE_IOCTL(DM_DEV_STATUS)
+COMPATIBLE_IOCTL(DM_DEV_WAIT)
+COMPATIBLE_IOCTL(DM_TABLE_LOAD)
+COMPATIBLE_IOCTL(DM_TABLE_CLEAR)
+COMPATIBLE_IOCTL(DM_TABLE_DEPS)
+COMPATIBLE_IOCTL(DM_TABLE_STATUS)
+#else
 COMPATIBLE_IOCTL(DM_VERSION)
 COMPATIBLE_IOCTL(DM_REMOVE_ALL)
 COMPATIBLE_IOCTL(DM_DEV_CREATE)
@@ -131,6 +145,7 @@
 COMPATIBLE_IOCTL(DM_TARGET_STATUS)
 COMPATIBLE_IOCTL(DM_TARGET_WAIT)
 #endif
+#endif
 /* Big K */
 COMPATIBLE_IOCTL(PIO_FONT)
 COMPATIBLE_IOCTL(GIO_FONT)

[Patch 5/6] dm: missing #include

[Joe Thornber]

Missing #include
--- diff/drivers/md/dm-ioctl-v4.c	2003-07-31 11:13:18.000000000 +0100
+++ source/drivers/md/dm-ioctl-v4.c	2003-07-31 11:14:03.000000000 +0100
@@ -13,6 +13,7 @@
 #include <linux/wait.h>
 #include <linux/slab.h>
 #include <linux/devfs_fs_kernel.h>
+#include <linux/dm-ioctl.h>
 
 #include <asm/uaccess.h>
 

[Patch 6/6] dm: use sector_div()

[Joe Thornber]

Use sector_div() rather than defining own version.  [Christophe Saout]
--- diff/drivers/md/dm-stripe.c	2003-06-30 10:07:21.000000000 +0100
+++ source/drivers/md/dm-stripe.c	2003-07-31 11:31:48.000000000 +0100
@@ -64,30 +64,6 @@
 }
 
 /*
- * FIXME: Nasty function, only present because we can't link
- * against __moddi3 and __divdi3.
- *
- * returns a == b * n
- */
-static int multiple(sector_t a, sector_t b, sector_t *n)
-{
-	sector_t acc, prev, i;
-
-	*n = 0;
-	while (a >= b) {
-		for (acc = b, prev = 0, i = 1;
-		     acc <= a;
-		     prev = acc, acc <<= 1, i <<= 1)
-			;
-
-		a -= prev;
-		*n += i >> 1;
-	}
-
-	return a == 0;
-}
-
-/*
  * Construct a striped mapping.
  * <number of stripes> <chunk size (2^^n)> [<dev_path> <offset>]+
  */
@@ -126,7 +102,8 @@
 		return -EINVAL;
 	}
 
-	if (!multiple(ti->len, stripes, &width)) {
+	width = ti->len;
+	if (sector_div(width, stripes)) {
 		ti->error = "dm-stripe: Target length not divisable by "
 		    "number of stripes";
 		return -EINVAL;

Re: [Patch 7/6 (so I can't count)] dm: resume() name clash

[Joe Thornber]

Some architectures define an extern function called resume(), which
clashes with a static function in dm-ioctl-v4.c.  Rename static one to
do_resume().
--- diff/drivers/md/dm-ioctl-v4.c	2003-07-31 11:55:02.000000000 +0100
+++ source/drivers/md/dm-ioctl-v4.c	2003-07-31 11:53:51.000000000 +0100
@@ -594,7 +594,7 @@
 	return dm_hash_rename(param->name, new_name);
 }
 
-static int suspend(struct dm_ioctl *param)
+static int do_suspend(struct dm_ioctl *param)
 {
 	int r = 0;
 	struct mapped_device *md;
@@ -613,7 +613,7 @@
 	return r;
 }
 
-static int resume(struct dm_ioctl *param)
+static int do_resume(struct dm_ioctl *param)
 {
 	int r = 0;
 	struct hash_cell *hc;
@@ -676,9 +676,9 @@
 static int dev_suspend(struct dm_ioctl *param, size_t param_size)
 {
 	if (param->flags & DM_SUSPEND_FLAG)
-		return suspend(param);
+		return do_suspend(param);
 
-	return resume(param);
+	return do_resume(param);
 }
 
 /*

Re: [Patch 3/6] dm: decimal device num sscanf

[Christoph Hellwig]

On Thu, Jul 31, 2003 at 11:49:53AM +0100, Joe Thornber wrote:
> The 2.4 version of Device-Mapper scans for device-numbers in decimal
> instead of hex (in dm_get_device()). Update 2.6 so both versions use
> the same behavior.  [Kevin Corry]

This code should just go away completly.  There's no excuse for parsing
a dev_t in new code instead of a pathname.

Re: [Patch 3/6] dm: decimal device num sscanf

[Joe Thornber]

On Thu, Jul 31, 2003 at 04:04:30PM +0100, Christoph Hellwig wrote:
> On Thu, Jul 31, 2003 at 11:49:53AM +0100, Joe Thornber wrote:
> > The 2.4 version of Device-Mapper scans for device-numbers in decimal
> > instead of hex (in dm_get_device()). Update 2.6 so both versions use
> > the same behavior.  [Kevin Corry]
> 
> This code should just go away completly.  There's no excuse for parsing
> a dev_t in new code instead of a pathname.

It's in there to match the output from 'dmsetup table'.  I'm not sure
anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
in sync.

- Joe

Re: [Patch 3/6] dm: decimal device num sscanf

[Christoph Hellwig]

On Thu, Jul 31, 2003 at 04:13:26PM +0100, Joe Thornber wrote:
> > This code should just go away completly.  There's no excuse for parsing
> > a dev_t in new code instead of a pathname.
> 
> It's in there to match the output from 'dmsetup table'.  I'm not sure
> anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
> in sync.

Please do the matching from dev_t to pathname in userspace.

Re: [Patch 3/6] dm: decimal device num sscanf

[Joe Thornber]

On Thu, Jul 31, 2003 at 04:20:00PM +0100, Christoph Hellwig wrote:
> On Thu, Jul 31, 2003 at 04:13:26PM +0100, Joe Thornber wrote:
> > > This code should just go away completly.  There's no excuse for parsing
> > > a dev_t in new code instead of a pathname.
> > 
> > It's in there to match the output from 'dmsetup table'.  I'm not sure
> > anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
> > in sync.
> 
> Please do the matching from dev_t to pathname in userspace.

we do.

Re: [Patch 3/6] dm: decimal device num sscanf

[Christophe Saout]

Am Do, 2003-07-31 um 17.13 schrieb Joe Thornber:

> On Thu, Jul 31, 2003 at 04:04:30PM +0100, Christoph Hellwig wrote:
> > On Thu, Jul 31, 2003 at 11:49:53AM +0100, Joe Thornber wrote:
> > > The 2.4 version of Device-Mapper scans for device-numbers in decimal
> > > instead of hex (in dm_get_device()). Update 2.6 so both versions use
> > > the same behavior.  [Kevin Corry]
> > 
> > This code should just go away completly.  There's no excuse for parsing
> > a dev_t in new code instead of a pathname.
> 
> It's in there to match the output from 'dmsetup table'.  I'm not sure
> anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
> in sync.

The output from dmsetup table looks different in 2.6 anyway (at least on
my system?), something like: 0 12582912 linear hda7 384

When you have a target that uses another device-mapper device it says
something like dm-5. dmsetup load doesn't like that one.

(BTW: Before 2.5.69 it looked like ide0(3, 7) or something, I don't
remember exactly. My lilo-devmapper patch tries to parse all three
formats, and also fails on things like dm-5...)

--
Christophe Saout <christophe@saout.de>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Patch 3/6] dm: decimal device num sscanf

[Christoph Hellwig]

On Thu, Jul 31, 2003 at 04:24:54PM +0100, Joe Thornber wrote:
> > > It's in there to match the output from 'dmsetup table'.  I'm not sure
> > > anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
> > > in sync.
> > 
> > Please do the matching from dev_t to pathname in userspace.

So why do you do it in kernel again?

Re: [Patch 3/6] dm: decimal device num sscanf

[Joe Thornber]

On Thu, Jul 31, 2003 at 05:14:43PM +0100, Christoph Hellwig wrote:
> On Thu, Jul 31, 2003 at 04:24:54PM +0100, Joe Thornber wrote:
> > > > It's in there to match the output from 'dmsetup table'.  I'm not sure
> > > > anyone uses it, but I'd still like to keep it so that 2.4 and 2.6 stay
> > > > in sync.
> > > 
> > > Please do the matching from dev_t to pathname in userspace.
> 
> So why do you do it in kernel again?

Let's reverse the question, why are you deprecating passing a dev_t
into the kernel ?  (I'm not being awkward, just confused).

- Joe

Re: [Patch 3/6] dm: decimal device num sscanf

[Christoph Hellwig]

On Thu, Jul 31, 2003 at 05:27:45PM +0100, Joe Thornber wrote:
> > So why do you do it in kernel again?
> 
> Let's reverse the question, why are you deprecating passing a dev_t
> into the kernel ?  (I'm not being awkward, just confused).

Because we want to keep dev_t use down as much as possible.  It should
just be a small cookie for looking up the correspoding object where
it's required by posix.  Everywhere outside that scope we better deal
with pathnames because they are much more meaningfull.  And with udev
and dynamic dev_t around the corner the actual values become more and
more meaningless.