On 01/28/2016 04:52 AM, Gris Ge wrote: > Features: > > * Zero changes to existing codes. > * Utilizing existing libmultipath codes. > * Library user guide is in 'man 3 libdmmp.h'. > * Every public function has its own manpage in section 3 > generated by linux 'kernel-doc' tool. > > Usage: > > make -j5 > sudo make install \ > bindir=/usr/sbin/ \ > syslibdir=/usr/lib64/ \ > libdir=/usr/lib64/multipath \ > rcdir=/etc/rc.d/init.d \ > unitdir=/usr/lib/systemd/system \ > includedir=/usr/include > make libdmmp_check > > man libdmmp.h > man dmmp_mpath_array_get > man <dmmp function name> > > User case: > > Storaged multipath plugin: > https://github.com/storaged-project/storaged/pull/40 > > FAQ: > > 1. Why not use better approach like wrapping multipathd IPC output? > > That often means a lot changes to existing code which might be > rejected. > I would like to create a stable set of API, while its internal > implementation could be changed without breaking binary > compatibility. > > 2. Why not build on existing libmultipath internal library? > > The libmultipath has too many public symbols which seems a bad > design for public library. Yes, we still expose some internal symbols > via libdmmp currently, that's because we are depending on > libmultipath right now, to fix that we need to change libmultipath > which I intend to avoid at this initial path set. > > 3. Any developer notes? > > Following Linux kernel code style and libabc guideline. > Others are recorded in 'libdmmp/DEV_NOTES' > > 4. Can the library be licensed as LGPL? > > Nope. LGPL library cannot link to any GPL code, but our dependent > libmultipath library is GPL. You could create some D-BUS API use > libdmmp if license concerns. We might able to license libdmmp to > LGPL when some day we change our implementation. > > 5. Why not expose all properties out? > > Let's do this step by step. This commit only contains minimum API > set required to create the initial storaged multipath plugin. > > Signed-off-by: Gris Ge <fge@xxxxxxxxxx> Rather ... not. In doing so you build a _separate_ multipath topology, which has nothing to do with the current multipath topology as being used by the multipathd. With that you run into the risk of both getting out-of-sync, making debugging and error recovery really hard. I would very much advocate to use the IPC interface into multipathd; we can easily define a stable ABI for that. ATM it's just being use for the userland CLI, and hence it'll return human-readable output. But I don't have any issues to define a machine-readable output, too, so that it can be easily parsed from other programs. In fact, I had the problem already, so I would welcome such an approach. But adding yet another library which duplicates existing functionality is not the way to go. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
