Skip to contentSkip to conversation

Move dm hw handlers to lower level subsystems

PATCH In review [email protected] 4 participants 15 messages Jun 9, 2007 – Sep 11, 2007

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

The following patches remove the dm hw handlers and move them to scsi (there is only one hw handler dm-emc, but I also added one for old hp boxes which cannot be upgraded).

Why move this piece of code to the scsi layer or dasd layer or wherever they are needed?
- dm is only a BIO mapper/router. It does not know anything about scsi and it would be nice that it did not have to.
- In the future we can use the scsi hw handlers for more advanced things. For example, during scanning they can check a devices state (check it if is a passive path using whatever vendor specific checks it needs to), then we can set some bits or do some magic so that when we get commands to passive devices later (like from partition scanning or userspace app scanning) we can avoid retries and filling the logs with noisey error messages.

The drawbacks?
- I think sending REQ_TYPE_BLOCK_PC from dm hw handlers is very simple. There is no needed for the REQ_TYPE_LINUX_BLOCK/REQ_LB_OP_TRANSITION abstraction.

The patches I am sending converts what is in mainline. In the past I was converting every patch that has been sent to dm-devel, so I could make sure it all work or was going to work or was just as horrible as dm :), but I think it would be an easier transition to just get what is in mainline coverted so we can began doing more advanced things like Ed and Chandra's patches (I am working on patches for that once this is done).

The patches should work with the existing multipath tools. The dm multipath argument code, will load the scsi hw handler when it see the dm one. The only thing we do not handle in a nice backward compat way in the kernel is the dm hw handler specific arguments. Because the hw handlers move to a different subsytem, there was not nice way to do some sort of compat code in the kernel. And there was actually only one hw handler, and I guess Hannes or Ed, in a previous thread said the defaults for it should be fine most of the time initially so I did not worry.

I did testing on the code, but I do not actaully have any of this hardware, so I hacked up scsi_debug. This was nice because I can test all the code paths, but I am not really sure how realistic the testing is. So if you have a old hp/compaq hsv/msa box where the firmware cannot be upgraded or a emc clariion box try it out.

#1 lore raw

PATCH 1/7 scsi-hw-handler: add REQ_LB_OP_TRANSITION and errors

From: Mike Christie <[email protected]>

This patch adds REQ_LB_OP_TRANSITION which is a REQ_TYPE_LINUX_BLOCK type of command. It also adds the error codes which are used by REQ_LB_OP_TRANSITION to blkdev.h.

---
 block/ll_rw_blk.c      |    2 +-
 include/linux/blkdev.h |   41 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 1 deletions(-)
block/ll_rw_blk.c +1 -1
index 6b5173a..c063792 100644
@@ -3396,7 +3396,7 @@ static int __end_that_request_first(stru
 	 * for a REQ_BLOCK_PC request, we want to carry any eventual
 	 * sense key with us all the way through
 	 */
-	if (!blk_pc_request(req))
+	if (!blk_pc_request(req) && !blk_linux_request(req))
 		req->errors = 0;
 
 	if (!uptodate) {
include/linux/blkdev.h +41 -0

55 lines not on this page · raw message

Signature · 1 line
1.4.1.1
#2 lore raw

PATCH 2/7 scsi-hw-handler: scsi handling of REQ_LB_OP_TRANSITION

From: Mike Christie <[email protected]>

This patch adds a scsi handler for REQ_LB_OP_TRANSITION commands.

---
 drivers/scsi/Kconfig       |    5 ++
 drivers/scsi/scsi_error.c  |   10 ++++
 drivers/scsi/scsi_lib.c    |  113 +++++++++++++++++++++++++++++++++++++++++++-
 include/scsi/scsi_cmnd.h   |    1 
 include/scsi/scsi_device.h |   14 +++++
 5 files changed, 141 insertions(+), 2 deletions(-)
drivers/scsi/Kconfig +5 -0
index aac9cd9..e4372da 100644
@@ -285,6 +285,11 @@ source "drivers/scsi/libsas/Kconfig"
 
 endmenu
 
+menu "SCSI Device Info Drivers"
+	depends on SCSI
+
+endmenu
+
 menu "SCSI low-level drivers"
 	depends on SCSI!=n
 
drivers/scsi/scsi_error.c +10 -0
index 9adb64a..99e526d 100644
@@ -297,6 +297,7 @@ #endif
  **/
 static int scsi_check_sense(struct scsi_cmnd *scmd)
 {
+	struct scsi_device *sdev = scmd->device;
 	struct scsi_sense_hdr sshdr;
 
 	if (! scsi_command_normalize_sense(scmd, &sshdr))
@@ -305,6 +306,15 @@ static int scsi_check_sense(struct scsi_
 	if (scsi_sense_is_deferred(&sshdr))
 		return NEEDS_RETRY;
 
+	if (sdev->sdevt && sdev->sdevt->check_sense) {
+		int rc;
+
+		rc = sdev->sdevt->check_sense(&sshdr);
+		if (rc)
+			return rc;
+		/* hw module does not care. Drop down to default handling */
+	}
+
 	/*
 	 * Previous logic looked for FILEMARK, EOM or ILI which are
 	 * mainly associated with tapes and returned SUCCESS.
drivers/scsi/scsi_lib.c +111 -2

145 lines not on this page · raw message

include/scsi/scsi_cmnd.h +1 -0
index 53e1705..5344b44 100644
@@ -127,6 +127,7 @@ extern void __scsi_put_command(struct Sc
 extern void scsi_io_completion(struct scsi_cmnd *, unsigned int);
 extern void scsi_finish_command(struct scsi_cmnd *cmd);
 extern void scsi_req_abort_cmd(struct scsi_cmnd *cmd);
+extern void scsi_blk_linux_cmd_done(struct request *req, int err);
 
 extern void *scsi_kmap_atomic_sg(struct scatterlist *sg, int sg_count,
 				 size_t *offset, size_t *len);
include/scsi/scsi_device.h +14 -0
index 2f3c5b8..1db6808 100644
@@ -9,6 +9,7 @@ #include <linux/blkdev.h>
 #include <asm/atomic.h>
 
 struct request_queue;
+struct request;
 struct scsi_cmnd;
 struct scsi_lun;
 struct scsi_sense_hdr;
@@ -143,9 +144,22 @@ #define SCSI_DEFAULT_DEVICE_BLOCKED	3
 
 	struct execute_work	ew; /* used to get process context on put */
 
+	struct scsi_device_template *sdevt;
+	void			*sdevt_data;
 	enum scsi_device_state sdev_state;
 	unsigned long		sdev_data[0];
 } __attribute__((aligned(sizeof(unsigned long))));
+
+#define SCSI_MAX_SDEV_TEMPLATE_NAME 16
+
+struct scsi_device_template {
+	struct module *module;
+	const char *name;
+
+	int (* check_sense)(struct scsi_sense_hdr *);
+	void (* transition)(struct request *);
+};
+
 #define	to_scsi_device(d)	\
 	container_of(d, struct scsi_device, sdev_gendev)
 #define	class_to_sdev(d)	\
Signature · 1 line
1.4.1.1
#3 lore raw

PATCH 3/7 scsi-hw-handler: add hp sw handler

From: Mike Christie <[email protected]>

This patch adds a very basic scsi hw handler for older hp boxes which cannot be upgraded.

---
 drivers/scsi/Kconfig    |    8 ++
 drivers/scsi/Makefile   |    1 
 drivers/scsi/hw_hp_sw.c |  215 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 224 insertions(+), 0 deletions(-)
drivers/scsi/Kconfig +8 -0
index e4372da..3122346 100644
@@ -288,6 +288,14 @@ endmenu
 menu "SCSI Device Info Drivers"
 	depends on SCSI
 
+config SCSI_HP_SW
+	tristate "HP/COMPAQ MSA Driver"
+	depends on SCSI
+	help
+	 If you have a HP/COMPAQ MSA device that requires START_STOP to
+	 be sent to start it and cannot upgrade the firmware then select y.
+	 Otherwise, say N.
+
 endmenu
 
 menu "SCSI low-level drivers"
drivers/scsi/Makefile +1 -0
index cba3967..c86e3c0 100644
@@ -129,6 +129,7 @@ obj-$(CONFIG_SCSI_IBMVSCSI)	+= ibmvscsi/
 obj-$(CONFIG_SCSI_IBMVSCSIS)	+= ibmvscsi/
 obj-$(CONFIG_SCSI_HPTIOP)	+= hptiop.o
 obj-$(CONFIG_SCSI_STEX)		+= stex.o
+obj-$(CONFIG_SCSI_HP_SW)	+= hw_hp_sw.o
 
 obj-$(CONFIG_ARM)		+= arm/
 
drivers/scsi/hw_hp_sw.c new file +215 -0

215 lines not on this page · raw message

Signature · 1 line
1.4.1.1
#4 lore raw

PATCH 4/7 scsi-hw-handler: add emc clariion handler

From: Mike Christie <[email protected]>

This adds support for clarrions. It is just a port of what is in mainline. Ed's patches will be intergrated in a different patch which adds more advanced functionality.

---
 drivers/scsi/Kconfig  |    6 +
 drivers/scsi/Makefile |    1 
 drivers/scsi/hw_emc.c |  362 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 369 insertions(+), 0 deletions(-)
drivers/scsi/Kconfig +6 -0
index 3122346..f8bf5ce 100644
@@ -296,6 +296,12 @@ config SCSI_HP_SW
 	 be sent to start it and cannot upgrade the firmware then select y.
 	 Otherwise, say N.
 
+config SCSI_CLARIION
+	tristate "EMC CLARiiON Driver"
+	depends on SCSI
+	 help
+	 If you have a EMC CLARiiON select y. Otherwise, say N.
+
 endmenu
 
 menu "SCSI low-level drivers"
drivers/scsi/Makefile +1 -0
index c86e3c0..ceffe0e 100644
@@ -130,6 +130,7 @@ obj-$(CONFIG_SCSI_IBMVSCSIS)	+= ibmvscsi
 obj-$(CONFIG_SCSI_HPTIOP)	+= hptiop.o
 obj-$(CONFIG_SCSI_STEX)		+= stex.o
 obj-$(CONFIG_SCSI_HP_SW)	+= hw_hp_sw.o
+obj-$(CONFIG_SCSI_CLARIION)	+= hw_emc.o
 
 obj-$(CONFIG_ARM)		+= arm/
 
drivers/scsi/hw_emc.c new file +362 -0

362 lines not on this page · raw message

Signature · 1 line
1.4.1.1
#5 lore raw

PATCH 5/7 scsi-hw-handler: convert dm-mpath to scsi hw handlers

From: Mike Christie <[email protected]>

This patch converts dm-mpath to scsi hw handlers. It does not add any new functionality and old behaviors and userspace tools should be supported except we use the safe clariion default instead of using the userspace setting.

This is just the dm-mpath parts which are necessary to use REQ_TYPE_LINUX_BLOCK and REQ_LB_OP_TRANSITION. In later mails I will send patches which remove old code and add more functionality.

---
 drivers/md/dm-mpath.c |  199 +++++++++++++++++++++++++++----------------------
 1 files changed, 111 insertions(+), 88 deletions(-)
drivers/md/dm-mpath.c +111 -88
index de54b39..5655d16 100644
@@ -7,7 +7,6 @@
 
 #include "dm.h"
 #include "dm-path-selector.h"
-#include "dm-hw-handler.h"
 #include "dm-bio-list.h"
 #include "dm-bio-record.h"
 
@@ -60,9 +59,9 @@ struct multipath {
 
 	spinlock_t lock;
 
-	struct hw_handler hw_handler;
 	unsigned nr_priority_groups;
 	struct list_head priority_groups;
+	char *hw_handler_name;
 	unsigned pg_init_required;	/* pg_init needs calling? */
 	unsigned pg_init_in_progress;	/* Only one pg_init allowed at once */
 
@@ -106,6 +105,9 @@ static struct kmem_cache *_mpio_cache;
 struct workqueue_struct *kmultipathd;
 static void process_queued_ios(struct work_struct *work);
 static void trigger_event(struct work_struct *work);
+static void bypass_pg(struct multipath *m, struct priority_group *pg,
+		      int bypassed);
+static int fail_path(struct pgpath *pgpath);
 
 
 /*-----------------------------------------------
@@ -190,18 +192,13 @@ static struct multipath *alloc_multipath
 static void free_multipath(struct multipath *m)
 {
 	struct priority_group *pg, *tmp;
-	struct hw_handler *hwh = &m->hw_handler;
 
 	list_for_each_entry_safe(pg, tmp, &m->priority_groups, list) {
 		list_del(&pg->list);
 		free_priority_group(pg, m->ti);
 	}
 
-	if (hwh->type) {
-		hwh->type->destroy(hwh);
-		dm_put_hw_handler(hwh->type);
-	}
-
+	kfree(m->hw_handler_name);
 	mempool_destroy(m->mpio_pool);
 	kfree(m);
 }
@@ -213,12 +210,10 @@ static void free_multipath(struct multip
 
 static void __switch_pg(struct multipath *m, struct pgpath *pgpath)
 {
-	struct hw_handler *hwh = &m->hw_handler;
-
 	m->current_pg = pgpath->pg;
 
 	/* Must we initialise the PG first, and queue I/O till it's ready? */
-	if (hwh->type && hwh->type->pg_init) {
+	if (m->hw_handler_name) {
 		m->pg_init_required = 1;
 		m->queue_io = 1;
 	} else {
@@ -400,11 +395,106 @@ static void dispatch_queued_ios(struct m
 	}
 }
 
+static void __pg_init_done(struct dm_path *path, int errors)
+{
+	struct pgpath *pgpath = path_to_pgpath(path);
+	struct priority_group *pg = pgpath->pg;
+	struct multipath *m = pg->m;
+	unsigned long flags;
+
+	if (blkerr_transport_err(errors)) {
+		/*
+		 * Old dm behavior had us fail a path on any error.
+		 * In future patches, since we have finer grained errors now,
+		 * we do not have to fail the path on the first transient
+		 * error.
+		 */
+		fail_path(pgpath);
+		goto cleanup;
+	}
+
+	/* device or driver problems */
+	switch (errors) {
+	case BLKERR_OK:
+		break;
+	case BLKERR_NOSYS:
+		if (!m->hw_handler_name) {
+			errors = 0;
+			break;
+		}
+		DMERR("Cannot failover device because hw-%s may not be "
+		      "loaded.", m->hw_handler_name);
+		/*
+		 * Fail path for now, so we do not ping poing
+		 */
+		fail_path(pgpath);
+		break;
+	case BLKERR_DEV_TEMP_BUSY:
+		/*
+		 * Probably doing something like FW upgrade on the
+		 * controller so try the other pg.
+		 */
+		bypass_pg(m, pg, 1);
+		break;
+	/* TODO: For BLKERR_RETRY we should wait a couple seconds */
+	case BLKERR_RETRY:
+	case BLKERR_IMM_RETRY:
+	case BLKERR_RES_TEMP_UNAVAIL:
+		break;
+	default:
+		/*
+		 * We probably do not want to fail the path for a device
+		 * error, but this is what the old dm did. In future
+		 * patches we can do more advanced handling.
+		 */
+		fail_path(pgpath);
+	}
+
+cleanup:
+	spin_lock_irqsave(&m->lock, flags);
+	if (errors) {
+		DMERR("Could not failover device. Error %d.", errors);
+		m->current_pgpath = NULL;
+		m->current_pg = NULL;
+	} else if (!m->pg_init_required) {
+		m->queue_io = 0;
+		pg->bypassed = 0;
+	}
+
+	m->pg_init_in_progress = 0;
+	queue_work(kmultipathd, &m->process_queued_ios);
+	spin_unlock_irqrestore(&m->lock, flags);
+}
+
+static void pg_init_done(struct request *req, int err)
+{
+	__pg_init_done(req->end_io_data, req->errors);
+	__blk_put_request(req->q, req);
+}
+
+static void pg_init(struct dm_path *path)
+{
+	struct request *req;
+
+	req = blk_get_request(bdev_get_queue(path->dev->bdev), 1, GFP_NOIO);
+	if (!req) {
+		/* retry later */
+		__pg_init_done(path, BLKERR_RES_TEMP_UNAVAIL);
+		return;
+	}
+
+	req->cmd[0] = REQ_LB_OP_TRANSITION;
+	req->cmd_type = REQ_TYPE_LINUX_BLOCK;
+	req->end_io_data = path;
+	/* TODO: does this need to be configurable or is it HW specific? */
+	req->retries = 5;
+	blk_execute_rq_nowait(req->q, NULL, req, 1, pg_init_done);
+}
+
 static void process_queued_ios(struct work_struct *work)
 {
 	struct multipath *m =
 		container_of(work, struct multipath, process_queued_ios);
-	struct hw_handler *hwh = &m->hw_handler;
 	struct pgpath *pgpath = NULL;
 	unsigned init_required = 0, must_queue = 1;
 	unsigned long flags;
@@ -433,7 +523,7 @@ out:
 	spin_unlock_irqrestore(&m->lock, flags);
 
 	if (init_required)
-		hwh->type->pg_init(hwh, pgpath->pg->bypassed, &pgpath->path);
+		pg_init(&pgpath->path);
 
 	if (!must_queue)
 		dispatch_queued_ios(m);
@@ -646,10 +736,9 @@ static struct priority_group *parse_prio
 
 static int parse_hw_handler(struct arg_set *as, struct multipath *m)
 {
+	struct dm_target *ti = m->ti;
 	int r;
-	struct hw_handler_type *hwht;
 	unsigned hw_argc;
-	struct dm_target *ti = m->ti;
 
 	static struct param _params[] = {
 		{0, 1024, "invalid number of hardware handler args"},
@@ -662,25 +751,9 @@ static int parse_hw_handler(struct arg_s
 	if (!hw_argc)
 		return 0;
 
-	hwht = dm_get_hw_handler(shift(as));
-	if (!hwht) {
-		ti->error = "unknown hardware handler type";
-		return -EINVAL;
-	}
-
-	m->hw_handler.md = dm_table_get_md(ti->table);
-	dm_put(m->hw_handler.md);
-
-	r = hwht->create(&m->hw_handler, hw_argc - 1, as->argv);
-	if (r) {
-		dm_put_hw_handler(hwht);
-		ti->error = "hardware handler constructor failed";
-		return r;
-	}
-
-	m->hw_handler.type = hwht;
+	m->hw_handler_name = kstrdup(shift(as), GFP_KERNEL);
+	request_module("hw-%s", m->hw_handler_name);
 	consume(as, hw_argc - 1);
-
 	return 0;
 }
 
@@ -979,45 +1052,11 @@ static int bypass_pg_num(struct multipat
 }
 
 /*
- * pg_init must call this when it has completed its initialisation
- */
-void dm_pg_init_complete(struct dm_path *path, unsigned err_flags)
-{
-	struct pgpath *pgpath = path_to_pgpath(path);
-	struct priority_group *pg = pgpath->pg;
-	struct multipath *m = pg->m;
-	unsigned long flags;
-
-	/* We insist on failing the path if the PG is already bypassed. */
-	if (err_flags && pg->bypassed)
-		err_flags |= MP_FAIL_PATH;
-
-	if (err_flags & MP_FAIL_PATH)
-		fail_path(pgpath);
-
-	if (err_flags & MP_BYPASS_PG)
-		bypass_pg(m, pg, 1);
-
-	spin_lock_irqsave(&m->lock, flags);
-	if (err_flags) {
-		m->current_pgpath = NULL;
-		m->current_pg = NULL;
-	} else if (!m->pg_init_required)
-		m->queue_io = 0;
-
-	m->pg_init_in_progress = 0;
-	queue_work(kmultipathd, &m->process_queued_ios);
-	spin_unlock_irqrestore(&m->lock, flags);
-}
-
-/*
  * end_io handling
  */
 static int do_end_io(struct multipath *m, struct bio *bio,
 		     int error, struct mpath_io *mpio)
 {
-	struct hw_handler *hwh = &m->hw_handler;
-	unsigned err_flags = MP_FAIL_PATH;	/* Default behavior */
 	unsigned long flags;
 
 	if (!error)
@@ -1044,19 +1083,8 @@ static int do_end_io(struct multipath *m
 	}
 	spin_unlock_irqrestore(&m->lock, flags);
 
-	if (hwh->type && hwh->type->error)
-		err_flags = hwh->type->error(hwh, bio);
-
-	if (mpio->pgpath) {
-		if (err_flags & MP_FAIL_PATH)
-			fail_path(mpio->pgpath);
-
-		if (err_flags & MP_BYPASS_PG)
-			bypass_pg(m, mpio->pgpath->pg, 1);
-	}
-
-	if (err_flags & MP_ERROR_IO)
-		return -EIO;
+	if (mpio->pgpath)
+		fail_path(mpio->pgpath);
 
       requeue:
 	dm_bio_restore(&mpio->details, bio);
@@ -1141,7 +1169,6 @@ static int multipath_status(struct dm_ta
 	int sz = 0;
 	unsigned long flags;
 	struct multipath *m = (struct multipath *) ti->private;
-	struct hw_handler *hwh = &m->hw_handler;
 	struct priority_group *pg;
 	struct pgpath *p;
 	unsigned pg_num;
@@ -1157,12 +1184,10 @@ static int multipath_status(struct dm_ta
 	else
 		DMEMIT("0 ");
 
-	if (hwh->type && hwh->type->status)
-		sz += hwh->type->status(hwh, type, result + sz, maxlen - sz);
-	else if (!hwh->type || type == STATUSTYPE_INFO)
-		DMEMIT("0 ");
+	if (m->hw_handler_name)
+		DMEMIT("1 %s ", m->hw_handler_name);
 	else
-		DMEMIT("1 %s ", hwh->type->name);
+		DMEMIT("0 ");
 
 	DMEMIT("%u ", m->nr_priority_groups);
 
@@ -1387,8 +1412,6 @@ static void __exit dm_multipath_exit(voi
 	kmem_cache_destroy(_mpio_cache);
 }
 
-EXPORT_SYMBOL_GPL(dm_pg_init_complete);
-
 module_init(dm_multipath_init);
 module_exit(dm_multipath_exit);
 
Signature · 1 line
1.4.1.1
#6 lore raw

PATCH 6/7 scsi-hw-handler: rm dm-hw-handler code

From: Mike Christie <[email protected]>

dm-hw-handler is no longer used.

---
 drivers/md/Makefile        |    2 
 drivers/md/dm-hw-handler.c |  215 --------------------------------------------
 drivers/md/dm-hw-handler.h |   62 -------------
 3 files changed, 1 insertions(+), 278 deletions(-)
drivers/md/Makefile +1 -1
index 3875408..d2ccc48 100644
@@ -4,7 +4,7 @@ #
 
 dm-mod-objs	:= dm.o dm-table.o dm-target.o dm-linear.o dm-stripe.o \
 		   dm-ioctl.o dm-io.o kcopyd.o
-dm-multipath-objs := dm-hw-handler.o dm-path-selector.o dm-mpath.o
+dm-multipath-objs := dm-path-selector.o dm-mpath.o
 dm-snapshot-objs := dm-snap.o dm-exception-store.o
 dm-mirror-objs	:= dm-log.o dm-raid1.o
 md-mod-objs     := md.o bitmap.o
drivers/md/dm-hw-handler.c deleted +0 -215

215 lines not on this page · raw message

drivers/md/dm-hw-handler.h deleted +0 -62

62 lines not on this page · raw message

Signature · 1 line
1.4.1.1
#7 lore raw

PATCH 7/7 scsi-hw-handler: rm dm-emc code

From: Mike Christie <[email protected]>

dm-emc.c is no longer used and is replaced by
drivers/scsi/hw_emc.c.

---
 drivers/md/Kconfig  |    6 -
 drivers/md/Makefile |    1 
 drivers/md/dm-emc.c |  362 ---------------------------------------------------
 3 files changed, 0 insertions(+), 369 deletions(-)
drivers/md/Kconfig +0 -6
index 7df934d..35968f9 100644
@@ -256,12 +256,6 @@ config DM_MULTIPATH
 	---help---
 	  Allow volume managers to support multipath hardware.
 
-config DM_MULTIPATH_EMC
-	tristate "EMC CX/AX multipath support (EXPERIMENTAL)"
-	depends on DM_MULTIPATH && BLK_DEV_DM && EXPERIMENTAL
-	---help---
-	  Multipath support for EMC CX/AX series hardware.
-
 config DM_DELAY
 	tristate "I/O delaying target (EXPERIMENTAL)"
 	depends on BLK_DEV_DM && EXPERIMENTAL
drivers/md/Makefile +0 -1
index d2ccc48..0ca8f2f 100644
@@ -33,7 +33,6 @@ obj-$(CONFIG_BLK_DEV_DM)	+= dm-mod.o
 obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o
 obj-$(CONFIG_DM_DELAY)		+= dm-delay.o
 obj-$(CONFIG_DM_MULTIPATH)	+= dm-multipath.o dm-round-robin.o
-obj-$(CONFIG_DM_MULTIPATH_EMC)	+= dm-emc.o
 obj-$(CONFIG_DM_SNAPSHOT)	+= dm-snapshot.o
 obj-$(CONFIG_DM_MIRROR)		+= dm-mirror.o
 obj-$(CONFIG_DM_ZERO)		+= dm-zero.o
drivers/md/dm-emc.c deleted +0 -362

362 lines not on this page · raw message

Signature · 1 line
1.4.1.1
#8 lore raw

Question about NetLink

In reply to [email protected]

Hello, Alasdair recently said that device-mapper was moving to the a netlink event reporting model (and I see the patches have been posted). I found an article (2 years old) describing this at:
http://www.linuxjournal.com/article/7356. I wanted to read up on this and wondered if this article was a good starting point.

Thank you,

Brian Wood
Intel Corporation
Digital Enterprise Group
Manageability & Platform Software Division
[email protected]

#9 lore raw

Re: Question about NetLink

Quoted 6 lines · Brian J

Hello, Alasdair recently said that device-mapper was moving to the a netlink event reporting model (and I see the patches have been posted). I found an article (2 years old) describing this at:
http://www.linuxjournal.com/article/7356. I wanted to read up on this and wondered if this article was a good starting point.

I found that it was easier to use the libnl interface.
http://people.suug.ch/~tgr/libnl/

I have previously posted a test program using the libnl interface with the dm netlink patches. You should be able to find the program in the archives.

or

I updated the demo program some so ping me if you would like an updated copy.

-andmike
--
Michael Anderson
[email protected]

#10 lore raw

RE: Question about NetLink

Quoted 2 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]

On

Quoted 8 lines

Behalf Of Mike Anderson
Sent: Tuesday, June 12, 2007 12:38 PM
To: device-mapper development
Subject: Re: [dm-devel] Question about NetLink

Quoted 2 lines · Brian J

Hello, Alasdair recently said that device-mapper was moving to the a netlink event reporting model (and I see the patches have been

posted).

Quoted 9 lines
Quoted 4 lines

I found an article (2 years old) describing this at:
http://www.linuxjournal.com/article/7356. I wanted to read up on this and wondered if this article was a good starting point.

I found that it was easier to use the libnl interface.
http://people.suug.ch/~tgr/libnl/

I have previously posted a test program using the libnl interface with

the

Quoted 7 lines

dm netlink patches. You should be able to find the program in the archives.

or

I updated the demo program some so ping me if you would like an updated copy.

Hello Michael, I just found this email sorted into a folder by mistake. Could you send me an updated copy of this program (or a link to a site where it might be posted)? I would like to see netlink in action.

Quoted 10 lines

-andmike
--
Michael Anderson
[email protected]

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

#11 lore raw

RE: Question about NetLink

First link on Google when searching for "Mike Anderson libnl":

http://www.redhat.com/archives/dm-devel/2005-November/msg00128.html

Quoted 2 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]

On

Quoted 13 lines

Behalf Of Wood, Brian J
Sent: Tuesday, September 11, 2007 8:48 AM
To: device-mapper development
Subject: RE: [dm-devel] Question about NetLink

Quoted 2 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]

On

Quoted 5 lines

Behalf Of Mike Anderson
Sent: Tuesday, June 12, 2007 12:38 PM
To: device-mapper development
Subject: Re: [dm-devel] Question about NetLink

Quoted 6 lines
Quoted 3 lines
Quoted 2 lines · Brian J

Hello, Alasdair recently said that device-mapper was moving to the a netlink event reporting model (and I see the patches have been

posted).

Quoted 2 lines
Quoted 2 lines

I found an article (2 years old) describing this at:
http://www.linuxjournal.com/article/7356. I wanted to read up on

this

Quoted 14 lines
Quoted 7 lines
Quoted 2 lines

and wondered if this article was a good starting point.

I found that it was easier to use the libnl interface.
http://people.suug.ch/~tgr/libnl/

I have previously posted a test program using the libnl interface with

the

Quoted 6 lines

dm netlink patches. You should be able to find the program in the archives.

or

I updated the demo program some so ping me if you would like an

updated

Quoted 22 lines
Quoted 1 line

copy.

Hello Michael, I just found this email sorted into a folder by mistake. Could you send me an updated copy of this program (or a link to a site where it might be posted)? I would like to see netlink in action.

Quoted 10 lines

-andmike
--
Michael Anderson
[email protected]

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

#12 lore raw

Re: Question about NetLink

Quoted 4 lines · Eric R

First link on Google when searching for "Mike Anderson libnl":

http://www.redhat.com/archives/dm-devel/2005-November/msg00128.html

Thanks for providing the link.

Please note that based on discussions held on this list and lkml that I generated a patch that uses kobject uevents instead of a new netlink channel. The url to a archive of the article is given below.

http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/3949

The advantage of the kobject uevent interface is that you could trigger off a udev rule, interface through dbus/hal, or interface directly to the uevent socket like multipathd does.

I am just finishing up testing on an update to the previous posted patch that aligns the calls in my patch with the updated kobject uevent interface in the latest -mm tree. I will post soon.

-andmike
--
Michael Anderson
[email protected]

#13 lore raw

Re: [PATCH 5/7] scsi-hw-handler: convert dm-mpath to scsi hw handlers

In reply to [email protected]
Quoted 7 lines · [email protected] wrote:

From: Mike Christie <[email protected]>

This patch converts dm-mpath to scsi hw handlers. It does not add any new functionality and old behaviors and userspace tools should be supported except we use the safe clariion default instead of using the userspace setting.

Quoted 5 lines

This is just the dm-mpath parts which are necessary to use REQ_TYPE_LINUX_BLOCK and REQ_LB_OP_TRANSITION. In later mails I will send patches which remove old code and add more functionality.

Alasdair, I took out all the new functionality. This patch is just the basic conversion. I can try to break it down even more if and do a patch for every hw handler callout that gets removed (all the callouts end up getting removed), but that may not buy much since the bulk of the patch is the REQ_TYPE_LINUX_BLOCK code.

#14 lore raw

Re: [dm-devel] Re: [PATCH 5/7] scsi-hw-handler: convert dm-mpath to scsi hw handlers

Quoted 14 lines · Mike Christie
Quoted 7 lines · [email protected] wrote:

From: Mike Christie <[email protected]>

This patch converts dm-mpath to scsi hw handlers. It does not add any new functionality and old behaviors and userspace tools should be supported except we use the safe clariion default instead of using the userspace setting.

Quoted 5 lines

This is just the dm-mpath parts which are necessary to use REQ_TYPE_LINUX_BLOCK and REQ_LB_OP_TRANSITION. In later mails I will send patches which remove old code and add more functionality.

Quoted 6 lines

Alasdair, I took out all the new functionality. This patch is just the basic conversion. I can try to break it down even more if and do a patch for every hw handler callout that gets removed (all the callouts end up getting removed), but that may not buy much since the bulk of the patch is the REQ_TYPE_LINUX_BLOCK code.

Just in case, I broke the patch in this mail down here
http://www.cs.wisc.edu/~michaelc/block/dm/mpath/

It basically breaks it up into removing the creation/destruction callbacks. Then adds the new pg init code. And finally removes the old pg_init code. Each patch is not compilable by itself so it is not git-revertable, but maybe it will be easier for you to read.