Skip to content

[pull] master from cloudius-systems:master#174

Merged
pull[bot] merged 5 commits intodk-dev:masterfrom
cloudius-systems:master
Jan 31, 2022
Merged

[pull] master from cloudius-systems:master#174
pull[bot] merged 5 commits intodk-dev:masterfrom
cloudius-systems:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Jan 31, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

As the issue #1166 explains, building lua module does not work on Fedora
33 and up. In short, lua module depends on a specific version 5.3 of lua
interpreter, library and header files which may not be available on
given version of Fedora and which may be the case with other Linux
distributions.

The issue #1166 describes at least three alternative solutions to the
problem, but this patch solves it by changing the makefile to
download the lua interpreter (lua executable), library and header files
from a well maintained repository - LuaBinaries at http://luabinaries.sourceforge.net/
- logically in a similar way we download luarocks. The LuaBinaries has
been in place since 2005 so there is good chance we can keep relying
on it in foreseeable future.

At the moment the makefile downloads fairly recent version 5.3.6 of lua binaries
which are compatible with the versions of lua modules (like socket, etc)
and luarocks. In future we may upgrade all elements needed to build the
module as we see fit.

As the result of this patch, lua module should in theory be build-able on any
Linux distribution and version. in reality with newer versions of gcc
one can imagine that lua modules themselves will stop compiling at which
point we will need to upgrade those and possibly lua and luarocks itself.
Also please note that lua module no longer depends on version of lua
installed on host if any.

Fixes #1166

Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
The commit af2d371 introduced ability
to build OSv kernel with most symbols but 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 have been coded to use many internal API
symbols. One such example is httpserver monitoring api module that
exposes various monitoring API REST endpoints.

At some point XLAB introduced C-wrappers API made of single C-style
osv_get_all_app_threads() functions. This patch enhances the C-wrappers API
by adding 9 more functions intended to be used by httpserver monitoring
api module.

Please note that new C-style API will open up access to relevant functionality
to new apps/modules implemented in languages different than C++.

Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
When OSv kernel is built to hide most symbols but glibc ones, the
OSv applications like httpserver monitoring API can not function
corretly as they rely on number of internal C++ API.

This patch modifies httpserver monitoring API to stop using kernel
internal C++ API. It does so by replacing some of the calls to internal C++
symbols with new module C-style API symbols: for example, sched::with_all_threads()
with new osv_get_all_threads(). In other scenarios, we fall back to
standard glibc API: for example osv::current_mounts() is replaced with
getmntent_r() and related functions.

Finally, we link httpserver monitoring app with core/options.cc and
thus remove need to have those symbols exposed by the kernel.

Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
@pull pull bot added the ⤵️ pull label Jan 31, 2022
@pull pull bot merged commit 2f1bed2 into dk-dev:master Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant