[dm-devel] [PATCH RFC 0/3] make priority groups modular and rm ps's HW knowledge

[Mike Christie]

I do not think we will end up with one super-terrific-optimal-for-all-workloads 
path-selector. As result, people or vendors may wish to plug into dm-mpath and 
use the exsiting dm path selectors. This is currently not possible because the 
init funciotn and path status knowledge is stuck in the path-selector. Hey, that 
was my fault so I will kick myself in the shins :) If we thought we will have a 
single ps to rule them all then I guess we could add some way for vendors to 
plug in there. However, as the subject of mail hints to the following patches 
are based on the assumption stated at the beginning of the mail.

The goal of seperating out the priority_group stuff is so vendorX can implement
a pg or (internally) a collection of groups and define functions
like pg->init to send their failover commands or handle special
error cases. The latter is not really possible today becuase how to get, decode 
and/pr pass vendor specific sense is not defined. Also, by seperatng the
HW specifics from the path-selection vendors can resuse dm's path-selectors.


01-sep-pg-from-mpath.patch - move some pg code out of dm-mpath.c. dm-mpath.c 
still parses some args like how it does of selectors, but there is a new table 
format:

num_groups [group-name num_group_args [selector-name num_selector_arg num_paths 
[path_dev [path args (group args then selector args)]* ]+ ]+ ]+

The default group is just named "generic" and num_group_args=0.

02-sep-pg-from-ps.patch - moves the HW stuff out of the selector. Selector's are 
once again notified of path status updates throught the update function.

03-add-modular-pg.patch - a place to put vendor specific junk. I will resend my 
FAStT code ported to a priority-group, and seperate new group that should do the 
failover for HP-storage-works.

Hey it says RFC, so please send ideas or comments good or bad.

Thanks,

Mike