Adapt modules and unit tests to use C symbols instead of internal kernel C++ API #1186
Comments
wkozaczuk
added a commit
that referenced
this issue
Jul 8, 2022
In preparation to support building and running ZFS images on the kernel built with most symbols hidden, this patch adds new C function - osv_run_app() - that wraps code to run an arbitrary app. This will allow an application like mkfs.so to be changed to not have to depend on C++ symbols like osv::run() from OSv kernel. Refs #1186 Signed-off-by: Waldemar Kozaczuk <[email protected]>
wkozaczuk
added a commit
that referenced
this issue
Jul 8, 2022
This patch makes number of modifications across various files but mainly it changes mkfs.cc to switch it from using osv::run() and zfs::zfsdev_init() to new C-wrappers osv_run_app() and zfsdev_init() respectively. In adition, it also changes both mkfs.cc and cpiod.cc to expose the symbol main() which until now would be hidden if OSv was built with most symbols hidden. Finally, we modify the main makefile to build both cpiod.so and mkfs.so as proper C++ binaries in order to make them properly express dependency on libstdc++.so. This is necessary to make OSv dynamic linker load libstdc++.so from the image if kernel is built to hide most symbols including the C++ standard library ones. Refs #1186 Signed-off-by: Waldemar Kozaczuk <[email protected]>
wkozaczuk
added a commit
that referenced
this issue
Jul 8, 2022
This patch makes some incremental improvements to the process of building ZFS images. However, the main driving force here is to support building and running ZFS images with the kernel built with most symbols hidden. The key missing part to support the above is adding libstdc++.so to the image so that it can be loaded as needed by cpiod.so and mkfs.so. However, this would make the loader.elf even larger than the non-hidden version of it. So instead this patch adds new artifact - zfs_builder.elf - which is intended to be used by upload_manifest.py only to build ZFS-images. In essence this patch modifies the main makefile to build new zfs_builder.elf with bootfs populated with all artifacts necessary to build and load ZFS filesystem (cpiod.so, mkfs.so, etc). At the same time we drop support of building kernel.elf which became obsolete in favor of standard loader.elf which now is even leaner - it does not carry the bootfs footprint with ZFS building tools. On top of that we optimise the build time of ZFS image by making it run zfs_builder.elf in QEMU kernel direct mode and VGA console off that cuts boot time to around 20ms. At the end of the day we come close to satisfying #1068 - "Building a full OSv image without running it" - we use new OSv-based build tool zfs_builder.elf to build final ZFS image - usr.img. Another benefit of this approach is that we can use some "old" pre-existing version of zfs_builder.elf (possibly retrieved from github) to build ZFS image that includes new version of kernel (loader.elf). Refs #1068 Refs #1186 Signed-off-by: Waldemar Kozaczuk <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The commit af2d371 introduced the ability to build OSv kernel with most symbols but a subset of glibc hidden.
The regular Linux glibc apps should run fine on such kernel, but unfortunately many unit tests and various internal OSv apps (so-called modules) do not as they had been coded to use many internal C++ API symbols. In order to make those programs run on a kernel built with most symbols and standard C++ library hidden, we need to change them to either use suitable standard glibc symbols or expose some of the C++ API as C functions just like it was done for the
httpserver-monitoring-apimodule (see 182499c and 891bfcd).The relevant effort would be quite substantial and I doubt we will ever finish adapting all apps. So I am listing individual programs below in the order of importance:
lsroute.ccandifconfig.ccuse BSD internal API); ideally we should try to change some standard Linux facility or possibly expose a pseudo-file under/prochttpserver-apiI am on purpose not mentioning run-java and any java programs as I do think we have any appetite to touch this - please read this to understand why.
The text was updated successfully, but these errors were encountered: