Sdbusplus-based Shared Library

Patrick Venture venture at google.com
Wed Mar 28 02:43:24 AEDT 2018


Brad,

If you create a repository - phosphor-sdbus-utils or
phosphor-sdbusplus-utils or something like that, I'll put together a
starter pack on this and submit for review.

Patrick

On Mon, Mar 26, 2018 at 11:04 PM, Ratan Gupta
<ratagupt at linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> We raised this concern around an year back with patrick but that time it was
> told we have limited set of users for such classes,
>
> Let it be replicate but now as the code size is getting increased we should
> look for some common library for such classes.
>
> Regards
>
> Ratan Gupta
>
>
>
> On Tuesday 27 March 2018 11:17 AM, Andrew Jeffery wrote:
>>
>> On Tue, 20 Mar 2018, at 06:03, Patrick Venture wrote:
>>>
>>> On Mon, Mar 19, 2018 at 11:24 AM, Tanous, Ed <ed.tanous at intel.com> wrote:
>>>>
>>>> Have you tried prototyping to see how much space you'll save?  I suspect
>>>> it won't be a lot for a few reasons.
>>>>
>>>> 1. A lot of sdbusplus is template instantiations, and unless we forward
>>>> declare a number of base template instantiations for use in the shared
>>>> library, most of the application code will end up in the binary anyway.
>>>> 2. Sdbus calls into libsystemd, which is already a shared library.
>>>> 3. The filesystem is already compressed, so I suspect that any
>>>> duplicated methods that aren't inlined will have the same binary code
>>>> pattern and get duplicated by the squashfs filesystem.
>>>>
>>>> Those are all the reasons why I haven't really looked into it for the
>>>> dbus stuff;  I can't speak to the timer stuff, but I suspect the wins in
>>>> size there are going to be small.
>>>>
>>>> Normal disclaimer, on this specific library, I haven't prototyped
>>>> anything, just done back of the napkin guesses, so I could very easily be
>>>> missing something here.
>>>>
>>> So my thinking wasn't about reducing size of the binary but rather
>>> reducing the toil of maintaining multiple implementations of the same
>>> code.
>>>
>> I'm on board with this idea. There are a bunch of utility classes defined
>> for RAII that are (were) used in phosphor-mboxd that would be much better
>> off defined in some library where they can be reused.
>>
>> Has anyone looked at this beyond what's in the thread?
>>
>> Cheers,
>>
>> Andrew
>>
>


More information about the openbmc mailing list