On 09/02/2015 04:48 AM, Hannes Reinecke wrote: > On 09/02/2015 08:39 AM, Christoph Hellwig wrote: >> On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote: >> >> 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. I have a working prototype of a D-Bus API implemented as a new thread of multipathd. The good news is it would be very easy to move to another process. >> > 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. > Where should D-Bus events be layered on top of the uevents if not inside multipathd? Would putting it inside multipathd be a reasonable first step? We could maintain the same public D-Bus API and move it to a different process. Thanks, Todd -- 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
