> ... > So what else ought to be changed before freezing the interfaces? > [One change I intend to make is struct path to void in dm-hw-handler.h > and dm-path-selector.h] > ... I think for dm-path-selector.h this would be a step into the wrong direction. Personally I would rather see path information moving into the path selector domain. There are even some fields and functions in dm-mpath.c (current_count) that are rather specific to a selector. Most of the functions in mpath.c do not really need more than a path link (except some that implement generic selector functionality like for example fail_path). On the other hand path-selectors currently store the path pointer wrapped into their own structs for all paths and often have to search this list to match a passed path pointer). My proposal would be something like this: Files: dm-path-selector.h Definitions of core functions. dm-path-selector.c Core functionality for path selectors. dm-path-selector-int.h Defines common internal for path selectors. dm-path-selector-rr.c The round-robin selector. In mpath.c only the current_path_group is kept. It will always call ps->ps->select_path (it still would have to get the bdev either by passing an pointer to select_path or put a bdev_from_path to dm-path-selector.c). The constructor for path-selectors would parse the paths and do the setup. The io functions would only use the path as a void pointer to call path-selector functions. Does this sound acceptable? > New table example: > 0 96000 multipath > 1 queue_if_no_path 0 1 round-robin 2 1 7:1 1 7:2 1 For path selectors: what about per selector arguments? <selector-type> <nr of selector args> [<selector args>]* <nr of paths> (<nr of path args> [<path args>]* <path>)* For example the round-robin could take the number of io operations before switching to the next path: round-robin 1 1000 2 1 7:1 1 7:2 /Stefan Bader