From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: turn libcommon into a shared library and package it Date: Fri, 06 Jan 2017 07:20:39 -0500 Message-ID: <1483705239.2733.2.camel@redhat.com> References: <000e3136-5222-cdf2-6479-476f120dabc5@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-qt0-f171.google.com ([209.85.216.171]:34665 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757079AbdAFMUm (ORCPT ); Fri, 6 Jan 2017 07:20:42 -0500 Received: by mail-qt0-f171.google.com with SMTP id l7so27936884qtd.1 for ; Fri, 06 Jan 2017 04:20:42 -0800 (PST) In-Reply-To: <000e3136-5222-cdf2-6479-476f120dabc5@suse.com> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Ricardo Dias , kefu chai , "ceph-devel@vger.kernel.org" On Fri, 2017-01-06 at 11:48 +0000, Ricardo Dias wrote: > > On 06-01-2017 11:38, kefu chai wrote: > > > > hi cephers, > > > > libcommon is a convenient library and is statically linked into > > librados, librbd and libcephfs. and there are some static variables > > living in libcommon, for instance, the ones defined in lockdep.cc. so, > > we will have multiple copies of these global variables if an > > application is linked against librados and (librbd | libcephfs). the > > "ceph" cli does link against librados and libcephfs via the their > > python bindings. > > > > this incurs some problems: > > > > - cross reference each other's global variables: in my testbed, i ran > > into https://github.com/ceph/ceph/pull/12249#issuecomment-264105597. > > where libcephfs was referencing the lockdeps variables in librados > > when relinquishing a lock. when libcephfs tries to acquire this lock > > again, it found that this lock is *already* locked. > > - more memory foot print and disk space: apparently, libcommon is > > included by librados, librbd and libcephfs. so it's a waste to have > > multiple copies of libcommon if librbd and/or libcephfs are loaded > > into memory or installed onto disk. > > > > after turning libcommon into a shared library, these problems are solved. > > I agree with this approach. In RBD we also had the same problems > sometime ago, and we discussed the problem here > https://github.com/ceph/ceph/pull/8537 > > > > > > > but yes, unlike librados and its friends, libcommon is not a user > > facing library, so we will not install it right under /usr/lib/. > > instead, it will be living in /usr/lib/ceph. please note, the erasure > > plugins are installed into /usr/lib/ceph/erasure-code/ and rados > > classes are installed into /usr/lib/rados-classes/. this follows the > > related section of FHS [1]. > > > > what do you think? > > +1 here. Please go forward with this :-) > > > > > > > -- > > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA > > > Sounds good to me. It might also not hurt to rename it. libcommon as a name is awfully generic and could run afoul of other libs on the machine that have nothing to do with ceph (regardless of whether you install it in this private location). Maybe libceph-common? -- Jeff Layton