-
-
Notifications
You must be signed in to change notification settings - Fork 604
Modularization
By design, OSv has always been a "fat" unikernel and by default has provided a large subset of glibc functionality and has included full standard C++ library (libstdc++), the ZFS implementation, drivers for many devices, and has supported many hypervisors. On one hand, it makes running arbitrary applications on any hypervisor very easy using a single universal kernel. On another hand, such universality comes with the price of the bloated kernel with many symbols and drivers and possibly ZFS unused, thus causing inefficient memory usage, longer boot time, and potential security vulnerabilities. In addition, the C++ applications linked against a version of libstdc++ different than the version the kernel was linked against, may simply not work.
To address these issues, release 0.57 introduced a new experimental build mode to hide the non-glibc symbols and libstdc++ and extracted ZFS code out of the kernel in form of a dynamically linked library. It also provided another build option to tailor the kernel to a set of specific device drivers - 'driver profiles', and finally allowed building a version of the kernel with only glibc symbols needed to support a specific application. The following paragraphs explain these changes and features in more detail.
See https://github.com/cloudius-systems/osv/commit/af2d371a61f6ab1eb5a066a0c3e93230faf6611c
This patch adds new build configuration option - conf_hide_symbols - that allows to build OSv kernel with all non-glibc symbols hidden when enabled (set to 1). By default the conf_hide_symbols is set to disabled so the kernel is still built with all symbols exported.
ZFS is one of the three filesystems that OSv implements. The original code comes from FreeBSD circa 2014 and has been since integrated and adapted to work within OSv. ZFS is one of the best file systems for persistent mutable data and what ones needs to run mysql or elasticsearch on OSv for example. Although a lot of effort has gone into integrating ZFS into OSv, its sheer code base volume makes OSv kernel bigger than it needs to be and there are a plethora of stateless use cases like redis, memcached, microservices, etc where ZFS is not needed and instead we can use ROFS now. ZFS-less kernel is expected to be at least 1MB smaller, which should make OSv images smaller, use less memory, and boot slightly faster. So it would be nice to make it optional as a shared library.
This patch introduces new build mechanism that allows creating custom kernel with specific list of device drivers intended to target given hypervisor. Such kernel benefits from smaller size and better security as all unneeded code is removed.
In essence, we introduce new build script and makefile parameter:
drivers_profile. This new parameter is intended to specify a
drivers profile which is simply a list of device drivers to be linked
into kernel with some extra functionality like PCI or ACPI these drivers
depend on. Each profile is specified in a tiny make include file (.mk)
under new conf/profiles/$(arch) directory and included by the main
makefile as requested by drivers_profile parameter. The main makefile
has number of new ifeq conditions that add given driver object file
to the linked objects list depending on the value (0 or 1) of given
conf_drivers_ variable specified in the relevant profile file.
Sometimes it is necessary to conditionally enable/disable given
code depending on the drivers selected. The good example of it is
arch-setup.cc which actually registers individual drivers and this
is where we need some kind of #if-way of registering given driver.
To that end, this patch adds new script gen-drivers-config-header and
new rule to the makefile, which automatically generates driver-config.h
header file under build/$(mode)/gen/include/osv. The driver-config.h
is comprised of the #define CONF_drivers_* macros that specify if given
driver is enabled or not (1, 0) and is included by relatively few source
file like arch-setup.cc. The extra benefit of this approach is that
every time we change value of drivers_profile, all relevant files are
recompiled and new kernel linked.
See https://github.com/cloudius-systems/osv/commit/d19ccb1cde100ab4a5c8e6db9a0d69560cabbd04
This patch introduces another new build mechanism that allows creating custom kernel exporting only symbols required by specific application. Such kernel benefits from smaller size and better security as all unneeded code is removed. This patch addresses remaining part of the modularization/librarization functionality as explained by the issue https://github.com/cloudius-systems/osv/issues/1110 and this part of the roadmap - https://github.com/cloudius-systems/osv/wiki/Roadmap#modularizationlibrarization. This idea was also mentioned in the P99 OSv presentation - see slide 12.