Move dm hw handlers to lower level subsystems
Subsystems (4)
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.
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
@@ -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
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
@@ -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
@@ -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
@@ -127,6 +127,7 @@ extern void __scsi_put_command(struct Scextern 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
@@ -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 3struct 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
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
@@ -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
@@ -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
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
@@ -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
@@ -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
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
@@ -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_multipathstatic 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 multipstatic 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_priostatic 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_sif (!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_taint 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_taelse 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(voikmem_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
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
@@ -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
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 bydrivers/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
@@ -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
@@ -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
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]
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]
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 NetLinkQuoted 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
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 NetLinkQuoted 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
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]
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_BLOCKandREQ_LB_OP_TRANSITION. In later mails I will send patches which remove old code and add more functionality.Signed-off-by Mike Christie <[email protected]>
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.
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_BLOCKandREQ_LB_OP_TRANSITION. In later mails I will send patches which remove old code and add more functionality.Signed-off-by Mike Christie <[email protected]>
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_BLOCKcode.
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.