From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [PATCH] Introducing multipath C API Date: Thu, 28 Jan 2016 10:15:16 +0100 Message-ID: <56A9DC24.3050507@suse.de> References: <1453953120-7023-1-git-send-email-fge@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1453953120-7023-1-git-send-email-fge@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Gris Ge Cc: dm-devel@redhat.com List-Id: dm-devel.ids 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=3D/usr/sbin/ \ > syslibdir=3D/usr/lib64/ \ > libdir=3D/usr/lib64/multipath \ > rcdir=3D/etc/rc.d/init.d \ > unitdir=3D/usr/lib/systemd/system \ > includedir=3D/usr/include > make libdmmp_check > = > man libdmmp.h > man dmmp_mpath_array_get > man > = > 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 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@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N=FCrnberg)