Hi Chandra,
Chandra Seetharaman wrote:
On Thu, 2008-05-15 at 11:46 +0200, Hannes Reinecke wrote:
Hi Chandra,
Chandra Seetharaman wrote:
What is the purpose of this feature ?
With dh_state functionality, one could associate a handler to a new
device and then if one does "multipath", the hardware handler would be
associated with the multipath device. What are we achieving by this ?
This allows multipath to override the device tables build into
the device handler. Reason here is that multipath has a configuration
file which allows the user to override the build-in defaults.
And this includes the hardware handler, so we need to make sure that
the hardware handler is indeed attached.
Hardware handler's existence is currently been verified during parsing
(by doing a request_module() followed by scsi_dh_handler_exist() in
parse_hw_handler()).
Yes, but this only verifies that the _handler_ exist, not that it is
attached to this sdev
Hardware handler module is attached to the device itself (thru
try_module_get() in attach), so, the module will exist as long as the
device exists.
Not quite. It's only attached automatically if the device map has
an entry for this module.
However, given this patchset we can now easily manually attach any
device to the device handler. Or at least try to do so.
It's then up to the device handler to refuse binding if none of
the necessary pages/information etc. was found.
Hence, there is no need to attach it again from the multipath layer.
Yes, you do. The user might have it's own custom configuration file,
covering new/unknown/unhandled/testing devices, which out of necessity
are _not_ hardcoded in the device table of the device handler.
So multipath has to have a way of attaching device handler to those
devices, too.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
