Use of Boost in OpenBMC

[Brad Bishop]

Just FYI Boost is now conditionally allowed by the OpenBMC
coding style guidelines:

https://gerrit.openbmc-project.xyz/#/c/8029

-brad

> On Nov 16, 2017, at 5:22 PM, Tanous, Ed <ed.tanous at intel.com> wrote:
> 
> Our platforms are all specified with 512MB of ram, so I don’t have any experience with running out of memory on the platforms we use (barring serious memory leaks).  It would be interesting if you guys had some anti-patterns that you’ve found to be problems, so we can see if we can codify those into the coding standard rules.  I know that we regularly (ab)use the fact that we have a lot of RAM to make the coding easier (reading an entire config file into memory for example) .
>  
> Some of the items in boost are designed to help with memory usage.  Using flat_map over std::map (when used properly) will save memory.  Pooled allocators can help with memory fragmentation issues for things that allocate and deallocate lots of objects in c++.
>  
> In general, I don’t find my teams usage of boost to increase memory usage significantly, but it’s something to be considered.  Memory usage tracking might be a good thing for a metric test in the future to make sure we aren’t unnecessarily increasing the memory load.
>  
> -Ed
>  
> From: Nancy Yuen [mailto:yuenn at google.com] 
> Sent: Thursday, November 16, 2017 10:51 AM
> To: vishwa <vishwa at linux.vnet.ibm.com>
> Cc: Brad Bishop <bradleyb at fuzziesquirrel.com>; Tanous, Ed <ed.tanous at intel.com>; OpenBMC <openbmc at lists.ozlabs.org>
> Subject: Re: Use of Boost in OpenBMC
>  
> 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
>