On 09/02/2015 08:39 AM, Christoph Hellwig wrote: > On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote: >> That is what I'm eventually planning to do. >> My final goal is to move the multipath path monitoring stuff >> into the kernel (via the block device polling mechanism), and sending >> block events for path failure and re-establishment. > > It might be a good idea to prioritize that. Todd has been asking > for multipath monitoring APIs and suggested adding D-BUS APIs to > multipathd. I'd much prefer them directly talking to the kernel > instead of cementing multipathd, which is a bit of a wart. > Precisely my idea. I'm fine with having a device-mapper D-Bus API, so that any application can retrieve the device-mapper layout via D-Bus. (It might as well be using sysfs directly, but who am I to argue here) Path events, however, out of necessity are instantiated within the kernel, and should be send out from the kernel via uevents. D-Bus can be added on top of that, but multipathd should not generate path events for D-Bus. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
