Use of Boost in OpenBMC

[Nancy Yuen]

Google doesn't use Boost internally and in general have no objections to
this.

My biggest concern is how it might impact our servers with limited BMC
memory (128MB).  It's already been an issue tweaking OpenBMC to run on it
without memory issues, and it's been a constant battle.  It doesn't always
fail gracefully either.  Maybe the answer is to specify minimum
requirements for running OpenBMC, such as 512MB RAM.

----------
Nancy

On Wed, Nov 15, 2017 at 4:33 AM, vishwa <vishwa at linux.vnet.ibm.com> wrote:

> I like the proposal of using Boost when it makes more sense.
>
> As an example, In one of the recent code development, I was looking for
> string tokenizer support and could not see that in C++ and Boost had a good
> support of that. I ended up using strtok_r for that development.
>
> !! Vishwa !!
>
>
> On 11/14/2017 05:49 AM, Brad Bishop wrote:
>
>> On Nov 13, 2017, at 3:36 PM, Tanous, Ed <ed.tanous at intel.com> wrote:
>>>
>>> All,
>>>   I’d like to start a discussion around the thoughts about the inclusion
>>> of Boost headers.  I’ve heard before that it’s a controversial subject.
>>>   For record, here’s what the style guide currently says:
>>>   Boost, QT, etc.
>>>   If you give a mouse a cookie...
>>> While, in general, we appreciate reuse over rewriting, we are not using
>>> large general-purpose libraries such as Boost. Due to 'Code should be
>>> performant: code size' we do not want to utilize the entirety of Boost. If
>>> approval is given for a single part of a large general-purpose library it
>>> becomes much more difficult to disapprove of another part of the library.
>>> Before long, we may have effectively approved of the entire library.
>>>   We do look for single feature libraries that can be used in place of
>>> our own implementations.
>>>   I’d like to start a discussion around challenging a core tenant of
>>> this statement, that approval of one part of the library makes it difficult
>>> to disapprove other parts.  I would argue that the overhead of making a
>>> library available, while still rejecting improper use that effects the
>>> project, is much lower than rewriting and debugging equivalent “new”
>>> components for openbmc.
>>>   I would like to update the coding style conventions with the below
>>> verbiage in regards to boost.
>>>   Boost
>>>   Use of boost is allowed, under the following circumstances:
>>> 1.       Use is done as a header-only library.  This allows unused
>>> functions and methods to be removed by the compiler at link time, and
>>> avoids adding large amounts of overhead and flash usage.
>>> 2.       Implementers should include the lowest level header required to
>>> solve the problem at hand.  This allows uses to be found and moved forward
>>> when new standards are available, as well as reduce compile times, and
>>> decrease the possibility of accidental use.  (ie, #include
>>> <boost/container/flat_map.hpp>  not #include <boost/container.hpp>)
>>> 3.       The module used should not have an equivalent in the std
>>> namespace that meets the same requirements for implementation or clarity:
>>> For example, std::chrono should be preferred over boost::chrono.
>>> std::array over boost::array.
>>> 4.       Use does not conflict with any of the core tenants of this
>>> coding standard (clarity, modern practices, or performance)
>>>     Some examples of libraries in boost that (I believe) would be useful
>>> for openbmc:
>>> Boost containers (flat_map, flat_set, ect)
>>>                  Among other things, this module provides standards
>>> compliant containers backed by a sorted vector.  This allows a reduced
>>> memory footprint over using std::set or std::map, and in certain use cases
>>> can be more performant, or lower memory usage.
>>>   Boost asio
>>>                  This module provides C++ level networking, sockets,
>>> SSL, and asynchronous frameworks that are not available in C++ today.  It
>>> has been proposed as a Networking TS to the C++ standards committee.
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf  This
>>> use would likely align us with moving toward compliant standards in the
>>> future.
>>>   Boost string
>>>                  Implementations of common string operations not present
>>> in the standard library.  String join, split, case insensitive compare ect.
>>>     I’d like to see what other people opinions are on the matter, and
>>> see if we can reach a consensus.
>>>   Thanks,
>>>   -Ed
>>>
>>
>> This has my support.  I think (hope?) we can rely on a rigorous peer
>> review process to flush out and raise awareness of any questionable usage.
>>
>> Would it make sense to have another bullet point documented somewhere to
>> this effect?
>>
>> "If you are considering a boost component, it is suggested you outline
>> your intended usage publicly (the mailing list) to avoid wasted effort if
>> the community does not feel the specific usage is appropriate."
>>
>> -brad
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171116/20e56e79/attachment-0001.html>