[dm-devel] [PATCH] Introducing multipath C API <libdmmp/libdmmp.h>

[Hannes Reinecke]

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 at redhat.com>

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 at suse.de			               +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)