Make kernel not to use boost program_options library

[wkozaczuk]

OSv kernel uses following parts of boost libraries:

• C++ collection and utilities templates mostly used in core/.cc; given corresponding instantiations for each type parameter combination become part of relevant object files, it is not clear how much it contributes to the size of code sections (text) of loader.elf (it seems it should be possible to measure it somehow though bloaty is not capable to show it)
  • boost/algorithm/cxx11/all_of.hpp
  • boost/algorithm/string.hpp
  • boost/algorithm/string/replace.hpp
  • boost/algorithm/string/split.hpp
  • boost/config/warning_disable.hpp
  • boost/date_time.hpp
  • boost/dynamic_bitset.hpp
  • boost/format.hpp
  • boost/intrusive/list.hpp
  • boost/intrusive/parent_from_member.hpp
  • boost/intrusive/set.hpp
  • boost/lockfree/policies.hpp
  • boost/lockfree/queue.hpp
  • boost/lockfree/stack.hpp
  • boost/range/adaptor/reversed.hpp
  • boost/range/algorithm/find.hpp
  • boost/range/algorithm/remove.hpp
  • boost/range/algorithm/transform.hpp
  • boost/spirit/include/qi.hpp
  • boost/utility.hpp
  • boost/variant.hpp
• libboost_system.a - tiny (10K code and 40K total) library providing error handling
• libboost_program_options.a - fairly large (400K code and 1.5M total) library to handle command line options and parameters

Unlike boost C++ templates that are used in many places of code and provide critical functionality that would be hard to replace with something hand-written, program options is only used by loader.cc and core/commands.cc and given its substantial size it is desirable to either replace it with something smaller or somehow make use of this library optional. Based on some experiments involving removing programs options completely from kernels it was shown that resulting loader-stripped.elf becomes smaller by 500-600K.

The solution I am proposing is hybrid:

• rewrite loader.cc::parse_options() by using getopt_long() (which is already part of musl in OSv) instead of boost::program_options
• extract commands.cc::parse_command_line(const std::string line, bool& ok) and related code as an optional library commands.so that would be used dynamically if found on filesystem; new commands.so would be linked dynamically against libboost_program_options.so; move options parsing code (osv::parse_cmdline()) from commands.cc to new options.cc
• change loader.cc:prepare_commands() to dynamically use commands.so if present to parse command line or fall back to a simple implementation that handle cmdline as single application

Please note that parse_command_line() is called by loader.cc after VFS is fully setup so nothing prevents us from loading commands.so from filesystem.

[nyh]

I think dropping boost program_options should also be done for cpiod (see issue #980), not just in the main kernel.
Note that are additional parts we use from Boost which is not listed above. One example I particularly disliked (but don't know how much overhead it really adds) is Boost Qi, used in commands.cc.
I think we should only consider moving command.cc to a separate shared object if it turns out that this Boost Qi thing is very large and we cannot improve on it.

[wkozaczuk]

I did look at this again and measured the size impact of boost spirit QI and it seems to increase the size of loader-stripped.elfby 56K only. So program options is the big winner.
Also removing program options from kernel may help us fix the "hidden" issue - #1040 - less to hide :-)

[wkozaczuk]

Please note that using getopt_long in loader.cc might be overkill as well given all options handled are in form --option=value so parsing this manually is actually not that hard.

[wkozaczuk]

All the 3 commits referencing this issue have addressed this issue so I am closing it.