ehmry/genode
ehmry/genode
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Compare commits

base: ehmry:master
Branches Tags
ehmry:master
ehmry:cached_fs_rom
ehmry:libc
ehmry:issue3709
ehmry:issue3705
ehmry:unlabeled-log
ehmry:staging
ehmry:devel
ehmry:19.11
ehmry:19.08
ehmry:sculpt-19.07
ehmry:19.05-sdk
ehmry:19.05
ehmry:i3261
ehmry:sculpt_ce
ehmry:19.02
ehmry:18.11
ehmry:sculpt_vc
ehmry:18.08
ehmry:18.05
ehmry:18.02
ehmry:17.11
ehmry:17.08
ehmry:17.05
ehmry:17.02
ehmry:16.11
ehmry:16.08
ehmry:16.05
ehmry:16.02
ehmry:15.11
ehmry:15.08
ehmry:15.05
ehmry:15.02
ehmry:14.11
ehmry:14.08
ehmry:14.05
ehmry:14.02
ehmry:13.11
ehmry:13.08
ehmry:13.05
ehmry:13.02
ehmry:12.11
ehmry:12.08
ehmry:12.05
ehmry:12.02
ehmry:11.11
..
compare: ehmry:19.02
Branches Tags
ehmry:cached_fs_rom
ehmry:libc
ehmry:issue3709
ehmry:issue3705
ehmry:master
ehmry:unlabeled-log
ehmry:staging
ehmry:devel
ehmry:19.11
ehmry:19.08
ehmry:sculpt-19.07
ehmry:19.05-sdk
ehmry:19.05
ehmry:i3261
ehmry:sculpt_ce
ehmry:19.02
ehmry:18.11
ehmry:sculpt_vc
ehmry:18.08
ehmry:18.05
ehmry:18.02
ehmry:17.11
ehmry:17.08
ehmry:17.05
ehmry:17.02
ehmry:16.11
ehmry:16.08
ehmry:16.05
ehmry:16.02
ehmry:15.11
ehmry:15.08
ehmry:15.05
ehmry:15.02
ehmry:14.11
ehmry:14.08
ehmry:14.05
ehmry:14.02
ehmry:13.11
ehmry:13.08
ehmry:13.05
ehmry:13.02
ehmry:12.11
ehmry:12.08
ehmry:12.05
ehmry:12.02
ehmry:11.11

No commits in common. "master" and "19.02" have entirely different histories.
master ... 19.02

3378 changed files with 55114 additions and 86788 deletions
Show Stats Expand all files Collapse all files

13
.gitignore vendored
View File

@ -2,21 +2,10 @@
*.orig
*.swp
*.rej
result
result-*
/build
/contrib
/depot
/public
/repos/world
/.tup
/build-*
/configs
##### TUP GITIGNORE #####
##### Lines below automatically generated by Tup.
##### Do not edit.
.tup
/.gitignore
/dev
/out

72
README.md → README
View File

@ -1,29 +1,16 @@
**FORK AHEAD**
This a fork of the Genode OS reference implementation with a replacement
build system that is humane and interoperable.
=================================
Genode Operating System Framework
=================================
Changes against [Genode Labs](https://genode-labs.com/) master may be
reviewed with the following commands:
```sh
git remote add genodelabs https://github.com/genodelabs/genode.git
git fetch genodelabs
git diff genodelabs/master
```
---
# Genode Operating System Framework
This is the source tree of the reference implementation of the Genode OS
architecture. For a general overview about the architecture, please refer to
the project's official website:
### Official project website for the Genode OS Framework
https://genode.org/documentation/general-overview
:Official project website for the Genode OS Framework:
[https://genode.org/documentation/general-overview]
The current implementation can be compiled for 8 different kernels: Linux,
L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
@ -46,14 +33,15 @@ the kernel that fits best with the requirements at hand for the particular
usage scenario.
## Documentation
Documentation
#############
The primary documentation is the book "Genode Foundations", which is available
on the front page of Genode website:
### Download the book "Genode Foundations"
:Download the book "Genode Foundations":
https://genode.org
[https://genode.org]
The book describes Genode in a holistic and comprehensive way. It equips you
with a thorough understanding of the architecture, assists developers with the
@ -65,75 +53,79 @@ The project has a quarterly release cycle. Each version is accompanied with
detailed release documentation, which is available at the documentation
section of the project website:
### Release documentation
:Release documentation:
https://genode.org/documentation/release-notes/
[https://genode.org/documentation/release-notes/]
## Directory overview
Directory overview
##################
The source tree is composed of the following subdirectories:
### 'doc'
:'doc':
This directory contains general documentation. Please consider the following
document for a quick guide to get started with the framework:
[doc/getting_started.txt](doc/getting_started.txt)
! doc/getting_started.txt
If you are curious about the ready-to-use components that come with the
framework, please review the components overview:
[doc/components.txt](doc/components.txt)
! doc/components.txt
### 'repos':
:'repos':
This directory contains the so-called source-code repositories of Genode.
Please refer to the README file in the 'repos' directory to learn more
about the roles of the individual repositories.
### 'tool'
:'tool':
Source-code management tools and scripts. Please refer to the README file
contained in the directory.
### 'depot' and 'public'
:'depot' and 'public':
Local depot and public archive of Genode packages. Please refer to
[doc/depot.txt](doc/depot.txt)
! doc/depot.txt
for more details.
## Additional community-maintained components
Additional community-maintained components
##########################################
The components found within the main source tree are complemented by a growing
library of additional software, which can be seamlessly integrated into Genode
system scenarios.
### Genode-world repository
:Genode-world repository:
https://github.com/genodelabs/genode-world
[https://github.com/genodelabs/genode-world]
## Contact
Contact
#######
The best way to get in touch with Genode developers and users is the project's
mailing list. Please feel welcome to join in!
### Genode Mailing Lists
:Genode Mailing Lists:
https://genode.org/community/mailing-lists
[https://genode.org/community/mailing-lists]
## Commercial support
Commercial support
##################
The driving force behind the Genode OS Framework is the German company Genode
Labs. The company offers commercial licensing, trainings, support, and
contracted development work:
### Genode Labs website
:Genode Labs website:
https://www.genode-labs.com
[https://www.genode-labs.com]

0
Tupfile.ini
View File

46
Tuprules.gcc
View File

@ -1,46 +0,0 @@
TOOLCHAIN_CONFIGURED=$(TOOLCHAIN_CONFIGURED)X
ifeq (@(TUP_ARCH),i386)
CC_MARCH = -march=i686 -m32
LD_MARCH = -melf_i386
AS_MARCH = -march=i686 --32
endif
ifeq (@(TUP_ARCH),x86_64)
CC_MARCH = -m64 -mcmodel=large
LD_MARCH = -melf_x86_64
endif
ifeq (@(TUP_ARCH),arm_v8)
CC_MARCH = -march=armv8-a
endif
ifdef CXXFLAGS
CXXFLAGS = @(CXXFLAGS)
endif
CXXFLAGS += -Wno-error=implicit-fallthrough
CXXFLAGS += -Wno-error=unknown-pragmas
CXXFLAGS += -Wextra
CXXFLAGS += -Weffc++
CXXFLAGS += -Werror
CXXFLAGS += -Wsuggest-override
CXXFLAGS += -Wno-unknown-pragmas
LIBGCC = `$(CXX) $(CC_MARCH) -print-libgcc-file-name`
!ir = | $(DEV_DIR)/<pkg-config> |> clang $(OLEVEL) $(CXXFLAGS) $(CXXFLAGS_%e) $(CXXFLAGS_%f) `$(PKG_CONFIG) --cflags $(LIBS)` $(CPPFLAGS) -S -emit-llvm %f |> %B.ll
!asm = |> ^ CC %b^ @(CC_WRAPPER) $(CC) $(OLEVEL) $(CFLAGS) $(CFLAGS_%e) $(CFLAGS_%f) -D__ASSEMBLY__ $(CPPFLAGS) -c %f -o %o |> %B.o
!cc = | $(DEV_DIR)/<pkg-config> |> ^o CC %f^ @(CC_WRAPPER) $(CC) $(OLEVEL) $(CFLAGS) $(CFLAGS_%e) $(CFLAGS_%f) $(CPPFLAGS) `$(PKG_CONFIG) --cflags $(LIBS) $(LIBS_CFLAGS)` -c -fPIC %f -o %o |> %B.o
!cxx = | $(DEV_DIR)/<pkg-config> |> ^o CXX %b^ @(CC_WRAPPER) $(CXX) $(OLEVEL) $(CXXFLAGS) $(CXXFLAGS_%e) $(CXXFLAGS_%f) $(CPPFLAGS) `$(PKG_CONFIG) --cflags $(LIBS)` -c -fPIC %f -o %o |> %B.o
!ld = | $(DEV_DIR)/<lib> $(DEV_DIR)/<pkg-config> |> ^o LD %o^ $(LD) -o %o $(LDFLAGS) `$(PKG_CONFIG) --libs $(LIBS)` %f |>
!incbin = |> ^ incbin %f^ \
export SYM=_binary_`echo %b | sed 's/\./_/g'`; \
echo ".global ${SYM}_start, ${SYM}_end; .data; .align 4; ${SYM}_start:; .incbin \"%f\"; ${SYM}_end:" \
| x86_64-unknown-genode-as $(AS_MARCH) -o %o - \
|> binary_%b.o

40
Tuprules.llvm
View File

@ -1,40 +0,0 @@
TOOLCHAIN_CONFIGURED=$(TOOLCHAIN_CONFIGURED)X
ifeq (@(TUP_ARCH),i386)
CC_MARCH = -march=i686 -m32
LD_MARCH = -melf_i386
AS_MARCH = -march=i686 --32
endif
ifeq (@(TUP_ARCH),x86_64)
CC_MARCH = -m64 -mcmodel=large
LD_MARCH = -melf_x86_64
endif
ifeq (@(TUP_ARCH),arm_v8)
CC_MARCH = -march=armv8-a
endif
ifdef CXXFLAGS
CXXFLAGS = @(CXXFLAGS)
endif
CXXFLAGS += -Wno-undefined-bool-conversion -Wno-unknown-attributes -Wsystem-headers -Werror -Wno-uninitialized -Wno-mismatched-tags
LIBGCC = `$(CC) $(CC_MARCH) -print-libgcc-file-name`
!ir = | $(DEV_DIR)/<pkg-config> |> clang $(OLEVEL) $(CXXFLAGS) $(CXXFLAGS_%e) $(CXXFLAGS_%f) `$(PKG_CONFIG) --cflags $(LIBS)` $(CPPFLAGS) -S -emit-llvm %f |> %B.ll
!asm = |> ^ CC %b^ @(CC_WRAPPER) $(CC) $(OLEVEL) $(CFLAGS) $(CFLAGS_%e) $(CFLAGS_%f) -D__ASSEMBLY__ $(CPPFLAGS) -c %f -o %o |> %B.o
!cc = | $(DEV_DIR)/<pkg-config> |> ^o CC %f^ @(CC_WRAPPER) $(CC) $(OLEVEL) $(CFLAGS) $(CFLAGS_%e) $(CFLAGS_%f) $(CPPFLAGS) `$(PKG_CONFIG) --cflags $(LIBS) $(LIBS_CFLAGS)` -c -fPIC %f -o %o |> %B.o
!cxx = | $(DEV_DIR)/<pkg-config> |> ^o CXX %b^ @(CC_WRAPPER) $(CXX) $(OLEVEL) $(CXXFLAGS) $(CXXFLAGS_%e) $(CXXFLAGS_%f) $(CPPFLAGS) `$(PKG_CONFIG) --cflags $(LIBS)` -c -fPIC %f -o %o |> %B.o
!ld = | $(DEV_DIR)/<lib> $(DEV_DIR)/<pkg-config> |> ^o LD %o^ $(LD) $(LDFLAGS) `$(PKG_CONFIG) --libs $(LIBS)` --whole-archive --start-group %f --no-whole-archive --end-group -o %o |>
!incbin = |> ^ incbin %f^ \
export SYM=_binary_`echo %b | sed 's/\./_/g'`; \
echo ".global ${SYM}_start, ${SYM}_end; .data; .align 4; ${SYM}_start:; .incbin \"%f\"; ${SYM}_end:" \
| llvm-mc -filetype=obj - > %o \
|> binary_%b.o

103
Tuprules.tup
View File

@ -1,103 +0,0 @@
.gitignore
AR = @(AR)
AS = @(AS)
CC = @(CC)
CXX = @(CXX)
LD= @(LD)
OBJCOPY = @(OBJCOPY)
STRIP = @(STRIP)
OUT_DIR=$(TUP_CWD)/out
DEV_DIR = $(TUP_CWD)/dev
DEV_LIB_DIR = $(DEV_DIR)/lib
ifdef IS_GCC
include Tuprules.gcc
endif
ifdef IS_LLVM
include Tuprules.llvm
endif
ifeq ($(TOOLCHAIN_CONFIGURED),)
error no toolchain configuration is active
endif
ifneq ($(TOOLCHAIN_CONFIGURED),X)
error "multiple toolchain configurations are active "
endif
ifeq (@(TUP_ARCH),i386)
X86 = y
endif
ifeq (@(TUP_ARCH),x86_64)
X86 = y
endif
GENODE_DIR = $(TUP_CWD)
!prg = | $(DEV_DIR)/<lib> $(DEV_DIR)/<pkg-config> \
|> ^o LD %o^ $(LD) -o %o $(LD_MARCH) $(LDFLAGS) -L$(DEV_LIB_DIR) %f `$(PKG_CONFIG) --libs $(LIBS) genode-prg` $(LIBGCC) |> %d
!lib = | $(DEV_DIR)/<lib> $(DEV_DIR)/<pkg-config> |> ^o LD %o^ $(LD) $(LD_MARCH) %f $(LDFLAGS) `$(PKG_CONFIG) --libs genode-lib $(LIBS)` -L$(DEV_LIB_DIR) -o %o |> %d.lib.so
!collect_bin = |> ^ COLLECT %b^ \
$(STRIP) -o %o %f \
|> $(OUT_DIR)/bin/%b $(OUT_DIR)/<bin>
!collect_shared = |> ^ COLLECT %b^ \
cp %f %o \
|> $(OUT_DIR)/lib/%b $(OUT_DIR)/<lib>
!collect_static = |> ^ COLLECT %b^ \
cp %f %o \
|> $(DEV_LIB_DIR)/%b \
$(DEV_DIR)/<lib> \
PKG_CONFIG_DIR = $(DEV_DIR)/lib/pkgconfig
ifdef NIX_OUTPUTS_DEV
export PKG_CONFIG_PATH
PKG_CONFIG = PKG_CONFIG_PATH=$(PKG_CONFIG_DIR):$PKG_CONFIG_PATH @(PKGCONFIG)
else
PKG_CONFIG = PKG_CONFIG_PATH=$(PKG_CONFIG_DIR) @(PKGCONFIG)
endif
CFLAGS += -g
CXXFLAGS += -g
ifdef OLEVEL
OLEVEL = @(OLEVEL)
else
OLEVEL = -O2
endif
!strip = |> $(STRIP) -o %o %f |>
!ln = |> ln -s %f %o |>
!ar = |> $(AR) -rcs %o %f |> %d.a
GIT_VERSION = `git describe || echo @(VERSION)`
SED_PKGCONFIG_FLAGS += -e "s|@VERSION@|$(GIT_VERSION)|"
!sed_pkgconfig_file = |> ^o SED %B^ \
sed $(SED_PKGCONFIG_FLAGS) $(SED_FLAGS) < %f > %o; \
$(PKG_CONFIG) --validate %o; \
|> $(PKG_CONFIG_DIR)/%B $(DEV_DIR)/<pkg-config>
!sed_pkgconfig_flags = |> ^o SED %d.pc^ \
sed $(SED_PKGCONFIG_FLAGS) $(SED_FLAGS) > %o; \
$(PKG_CONFIG) --validate %o; \
|> $(PKG_CONFIG_DIR)/%d.pc $(DEV_DIR)/<pkg-config>
!emit_lib_pkg_config = |> ^ emit %d.a pkg-config^ \
echo Name: %d >> %o; \
echo Description: Genode %d library >> %o; \
echo Version: $(GIT_VERSION) >> %o; \
echo Libs: -l:%d.a >> %o; \
$(PKG_CONFIG) --validate %o; \
|> $(PKG_CONFIG_DIR)/%d.pc $(DEV_DIR)/<pkg-config>

2
VERSION
View File

@ -1 +1 @@
19.11
19.02

0
configs/.gitignore vendored
View File

2
depot/ehmry/download
View File

@ -1 +1 @@
https://depot.1337.cx
https://depot.fuzzlabs.org

1
depot/mstein/download
View File

@ -1 +0,0 @@
https://depot.genode.org

51
depot/mstein/pubkey
View File

@ -1,51 +0,0 @@
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFuhfGYBEADOj0EW/U2O3koeGIuNGDuBDSzkYjncoBrrPN1z69hgK349xiP7
ZwrPBA0kJ3ctLcRQcOEDF5XJzjByuNk3JV6MuKFqwy2i9dDTHkv5pv7Na/R3L2CM
k79weVahjPllt9nnbSMMtYH0eL187EhLW9owd0CY9wDj1lhLISHpyKvb9vwiUAwQ
i+xypGgU+Qvf8BmfTDdjfP0n+Iw31z+R3xiHhWmhrs9gID2XVtGZIy9NQQrijJYS
1Hp8hjgH9Fzmj0GkxUI+2mEqLeEp6wBmmo+7PRzc+iRYJNocyRxDbmdE0eyh3P93
QABzZiWTU+Feq0MYa1FK55uFCFHe6MSFLq33CGYMzQ9oFQHjuEX1KqJT/OoumPgN
iEb8Bt3XmqiI8GejafLKIW8gO8tYLABdrEpFelnyXy12IIOpOwb8GrxFUEu8+bDb
Fc0YkV7cZ4NH2Kq/6/Or30gCA2XUpqhDNSxA6jer35a3ZzvgXvcRkNR/oOt+qt/3
u9ew+e6Xjque0PRWzdavVlKdYWzSV8umVw5DGgQj/rSn+8spog/5w1lElyUa/5Yx
Z+1bvOIyXPg+tTLimWtGRZQorak1sMsLMDqQck9SwOQWpSmVGsJ14uWXSMaZjdj9
4rHSSymYlcQWP8t9lfPf6/ZSH8574PbbJSe71UXcWWznSGprSt2QQAQ7NwARAQAB
tCtNYXJ0aW4gU3RlaW4gPG1hcnRpbi5zdGVpbkBnZW5vZGUtbGFicy5jb20+iQI+
BBMBAgAoBQJboXxmAhsDBQkDwmcABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAK
CRDJZVRAR8NPkiTSD/9xiUVNgKTkmH9WRdCcaHuyhKoQI6CsWnMOW5OZ+gVXPc9U
LapQ5Wymb+yGE8Uyn4EJnwdEa8TdWztMs3TNtK5vh1Pk1lKmtKcblBiDrUPEURhR
mUBoUkMe2VDXyN27e0lkbxcFJ0HrYnhvb72Yfnw6B3XMa/NIhbOU3ttB/tVR6Kjl
YVDtTokfILQc07Ai+TqkqNARtPGntHAn9qFvPLNKI31c+Xw/QGZbVPNFW1QAYBiO
5dqsSwKaouapHAb0GBmU0fAfJZNcvwt9Ph7WDXU9Ce3LZmIshGW7Gzm7EGdf4VS6
k4OtEWZhZHRnl9/sBJ2UlQU0tFs3ow53aDZQIa4FKd4JKabBeRgDUKCGEyfoNKCq
NKkLZaR/kFA9EqTPZSIXPLYIzIlSFoL3LVDOc5O7hDT9vXaubdZeAfE9VcHDdm3u
usW034F0zbsuu4G83qZ6QhDOp0UhujfSU+BDkH0I+OfFyVkQAmy69J3byi7Iluno
OcZM13rbe30jzyyyWAnjHicAt8tNwCLMmnIRvYT9ELqywID0Zzxkct61eJQ6L6aq
/DnUD9Kq0OwdxC1wMGtimX5eUnN7S7y5+TMRepJnWcTtgrLBVqwRrvSLnsKVd4Gb
Bu3dSs+BxMV1UcyU0KWwDPY2D7k8SGgeH7IEPo/JiGO8RrWYJRac9qel9egMYbkC
DQRboXxmARAAoaRH/xgKvp0QrNFJZBW12SdXT4h1nXglbpZd+bUl738LqM2JSIC5
Qq7t2DUtOiL9UxqvRgAIjkVLR+hHJBZyuPOP5Ebaf3Mr7eAdmCx2TMsHZPKBLnTy
EqeUcnPwThNKcUaGsQYlkxIQAJtPzy3YBuDCYnzzSi6KzP3VC8szHsXcPo2DeKWI
m9BbMMSQkB3m0fz8W3ar/64RDoubRWRJ07b7q4WUb4jPvql+Tz+Gv5x3qm8g6m1j
uD+U5OhGCe3m5/MsI2JYdWXEwif8YD59gylsj3LJIu3i4SkR8aS+x6n3LIvdSCOt
P3To87wfoSqBWWObVe/vOHRXqpzEF6T/ih/rkhUFzrHNMziTPsujBazm82AUZ6xi
2TddbdSAK+ZpSPQjyyRflNyNgv0iu6P3BnBgv0Xcuf2RsDMBDjdvHtX0lXkPMB+r
6jgxl0faV6UktH5R2d4Zt9i0/vWlZZd0MDylPNQDiKs+qSIX3ntfUUaPdEJqYAwM
gloXr3cZtsVh+Yoqt8pa4x0x6kqez+oyBUFf6y1FCKYq2H/QfPRkF/DrfZS+7jXW
iAX8PcrDceCN6Dr10/g5LPWXQOHUWxCu7FEYoYJsVXst4N0FnCOCe/OGYIhMteSV
IJJvNS4qwXZKKZ+cmuT9skEQ6zsLV9+VDYMwVqXB4wTp4EwT2pCp6LEAEQEAAYkC
JQQYAQIADwUCW6F8ZgIbDAUJA8JnAAAKCRDJZVRAR8NPktRiD/9qjH6uuT1y5uNA
4E8u6/vxZGsyBG57dtnQ0KQbcsZSrUxMiDTtMMrklsl2vtut/XDroajm+d2eaQ4K
j0h285VRkT5xJ79JaIQ8oyzRWBtpENy0iLUm7CmqCMuH8VFifZyEBYZgR/K+9ago
WwF3sk0QP0WJTFqIZajKK0Lo5Juk8DCXjvtkvGNytHkZ2vEkiZ9m7Eq0AjQnts5T
PdHkob7Z8fu0KfUMoCUtb+TzNyMYOVGE6uTfo8wKvbhwzUWSymZkrecx73XUUmew
MdZ2WzwGdUMXwcBZ4LvgrZVg+LKxR1lyJ+qbIUpDKXCZGGH2VZVaQspgnx2Yt0EI
Zl2ELMrTq5IcOkxtblEZpQkwaXszqUDNO43ezp/PmbTRWChoM/k3RAbp9rvoYx93
UChyRXpJRaqDxK502k3BSnOfmolpQvxTMKtLZO50URa0F0F4qD2csns4QrqOWsGr
qPqVKcLn8Q/yMW9fm5+xX+ZHICKk64GAB0YyHcw9lOWekLhGzZV1KnD5ID6+5E0B
nsWZB6PDqLM+/ykXh0rcN8DWwZvhimI5/dOEIWIkADKT8WGwh+2JnRyimhxYdaiH
ul1BvZAYqF1FVXAHd0u48MssLywGGbW4fH8D9SM+LFpP4+8oYFLNgH1OreMENuag
i47EaxpnQUgIt8PZ/gL3LeiGs8SNpw==
=flyM
-----END PGP PUBLIC KEY BLOCK-----

241
doc/challenges.txt
View File

@ -16,6 +16,17 @@ research projects on Genode.
Applications and library infrastructure
#######################################
:GNU Privacy Guard:
The [https://gnupg.org/ - GNU Privacy Guard] (GNUPG) is the most widely
used Free-Software implementation of the OpenGPG standard. It comprises a
rich set of tools for encryption and key management. For many forthcoming
application scenarios of Genode such as package management and email
communication, GNUPG is crucial. Hence, it should be ported to Genode. Such
a port may leverage Genode's fine-grained component architecture to strongly
separate network-exposed functionality, the storage of key material, and the
cryptographic functions.
:VNC server implementing Genode's framebuffer session interface:
With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
@ -39,6 +50,24 @@ Applications and library infrastructure
integrated in the operating system, i.e., in the form of Genode components
or a set of Genode VFS plugins.
:Tiled window manager:
At Genode Labs, we pursue the goal to shape Genode into an general-purpose
operating system suitable for productive work. The feature set needed to
achieve this goal largely depends on the tools and applications daily used by
the Genode engineers. As one particularly important tool for being highly
productive, we identified a tiled user interface. Currently, all developers
at Genode Labs embrace either the Ion3 window manager or the tiled Terminator
terminal emulator. Hence, we desire to have a similar mode of user
interaction on Genode as well. The goal of this challenge is to identify the
most important usage patters and the implementation of a tiled GUI that
multiplexes the framebuffer into a set of tiled and tabbed virtual
framebuffers.
Related to this work, the low-level 'Framebuffer' and 'Input' interfaces
should be subject to a revision, for example for enabling the flexible change
of framebuffer sizes as needed by a tiled user interface.
:Interactive sound switchbox based on Genode's Audio_out session interface:
Since version 10.05, Genode features a highly flexible configuration concept
@ -87,11 +116,6 @@ Applications and library infrastructure
of communicating threads as captured on the running system. The tool should
work on a selected kernel that provides a facility for tracing IPC messages.
The underlying light-weight tracing infrastructure is
[https://genode.org/documentation/release-notes/19.08#Tracinghttps://genode.org/documentation/release-notes/19.08#Tracing - already in place].
The Qt-based tracing tools would complement this infrastructure with
an interactive front end.
:Ports of popular software:
Genode features a ports mechanism to cleanly integrate 3rd-party software.
@ -103,18 +127,6 @@ Applications and library infrastructure
have available on Genode is available at
[http://usr.sysret.de/jws/genode/porting_wishlist.html].
:Native Open-Street-Maps (OSM) client:
When using Sculpt OS, we regularly need to spawn a fully fledged web
browser in a virtual machine for using OSM or Google maps. The goal
of this project would be a native component that makes maps functionality
directly available on Genode, alleviating the urge to reach for a SaaS
product. The work would include a review of existing OSM clients regarding
their feature sets and the feasibility of porting them to Genode.
Depending on the outcome of this review, an existing application could
be ported or a new component could be developed, e.g., leveraging Genode's
Qt support.
Application frameworks and runtime environments
###############################################
@ -123,18 +135,18 @@ Application frameworks and runtime environments
[http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
Java programming language and hosts an enormous ecosystem of application
software.
Since
[https://genode.org/documentation/release-notes/19.02#Showcase_of_a_Java-based_network_appliance - version 19.02],
Genode features a port of OpenJDK that allows the use of Java for networking
applications.
The next step would be the creation of Genode-specific native classes that
bridge the gap between the Java world and Genode, in particular the glue
code to run graphical applications as clients of Genode's GUI server. Since
OpenJDK has been ported to numerous platforms (such as Haiku), there exists
a comforting number of implementations that can be taken as reference.
software. The goal of this line of work is the ability to run this
software directly on Genode. The centerpiece of OpenJDK is Hotspot - the
Java virtual machine implementation, which must be ported to Genode.
The initial port should suffice to execute simple example programs that
operate on textual input. Since Genode has the FreeBSD libc readily
available, OpenJDK's existing POSIX backends can be reused. The next step
is the creation of Genode-specific native classes that bridge the gap
between the Java world and Genode, in particular the glue code to
run graphical applications as clients of Genode's GUI server. Since
OpenJDK has been ported to numerous platforms (such as Haiku), there
exists a comforting number of implementations that can be taken as
reference.
:Android's ART VM natively on Genode:
@ -143,6 +155,22 @@ Application frameworks and runtime environments
removed from the trusted computing base of Android, facilitating the use of
this mobile OS in high-assurance settings.
:Rust bindings for the Genode API:
Rust is a low-level systems programming language that ensures memory
safety without employing a garbage collector. It thereby challenges C++
as the go-to programming language for high-performance and low-level code.
Since
[http://genode.org/documentation/release-notes/16.05#New_support_for_the_Rust_programming_language - version 16.05],
Genode supports the use of the Rust programming language within
components. However, to unleash the potential of this combination,
Genode's API must become available to native Rust code. The intermediate goal
of this project is the implementation of an example server, e.g., a
component that provides a terminal-session interface. Thereby, we
will encounter the problems of bootstrapping and configuration of the
component, the provisioning of signal handlers and session objects, and
memory management.
:Go language runtime:
Go is a popular language in particular for web applications. In the past,
@ -194,33 +222,6 @@ Application frameworks and runtime environments
development is [http://halvm.org - HalVM] - a light-weight OS runtime for
Xen that is based on Haskell.
:Xlib compatibility:
Developments like Wayland notwithstanding, most application software on
GNU/Linux systems is built on top of the Xlib programming interface.
However, only a few parts of this wide interface are actually used today.
I.e., modern applications generally deal with pixel buffers instead of
relying on graphical drawing primitives of the X protocol. Hence, it seems
feasible to reimplement the most important parts of the Xlib interface to
target Genode's native GUI interfaces (nitpicker) directly. This would
allow us to port popular application software to Sculpt OS without
changing the application code.
:Bump-in-the-wire components for visualizing session interfaces:
Genode's session interfaces bear the potential for monitoring and
visualizing their use by plugging a graphical application
in-between any two components. For example, by intercepting block
requests issued by a block-session client to a block-device driver,
such a bump-in-the-wire component could visualize
the access patterns of a block device. Similar ideas could be pursued for
other session interfaces, like the audio-out (sound visualization) or NIC
session (live visualization of network communication).
The visualization of system behavior would offer valuable insights,
e.g., new opportunities for optimization. But more importantly, they
would be extremely fun to play with.
Virtualization
##############
@ -236,6 +237,21 @@ Virtualization
is normally not possible. Also, complex Genode scenarios (like Turmvilla)
could be prototyped on GNU/Linux.
:VirtualBox on top of seL4:
The [https://sel4.systems - seL4 microkernel] is a modern microkernel that
undergoes formal verification to prove the absence of bugs. Since version
4.0, the kernel supports virtualization support on x86-based hardware.
Genode has experimental support for seL4 that allows almost all Genode
components to be used on top of this kernel. VirtualBox is an exception
because it closely interacts with the underlying kernel (like NOVA) to
attain good performance. We have shown that VirtualBox can be executed
within a protection domain of the NOVA microhypervisor. The goal of this
project is the application of this approach to the virtualization
interface of seL4. The result will be a VM hosting environment that
ensures the separation of virtual machines via the formally verified
seL4 kernel.
:Xen as kernel for Genode:
Using Xen as kernel for Genode would clear the way to remove the
@ -278,25 +294,22 @@ Virtualization
the project bears the opportunity to explore the provisioning of the
KVM interface based on Genode's VFS plugin concept.
:Hardware-accelerated graphics for virtual machines:
In
[https://genode.org/documentation/release-notes/17.08#Hardware-accelerated_graphics_for_Intel_Gen-8_GPUs - Genode 17.08],
we introduced a GPU multiplexer for Intel Broadwell along with support
for Mesa-based 3D-accelerated applications.
While designing Genode's GPU-session interface, we also aimed at supporting
the hardware-accelerated graphics for Genode's virtual machine monitors like
VirtualBox or Seoul, but until now, we did not took the practical steps of
implementing a virtual GPU device model.
The goal of this project is the offering of a virtual GPU to a Linux guest
OS running on top of Genode's existing virtualization and driver
infrastructure.
Device drivers
##############
:Isochronous USB devices:
Genode's USB driver supports bulk and interrupt endpoints. Thereby, most
USB devices like USB storage, user input, printers, and networking devices
can be used. However, multi-media devices such as cameras or audio
equipment use isochronous endpoints, which are not supported. The goal
of this line of work is the support of these devices in Genode. The topic
touches the USB driver, the USB session interface, an example implementation
of a USB client driver (using the session interface) for a device of choice,
and - potentially - the enhancement of Genode's USB-pass-through mechanism
for VirtualBox.
:Sound on the Raspberry Pi:
The goal of this project is a component that uses the Raspberry Pi's
@ -305,6 +318,18 @@ Device drivers
backend, the new driver will make the sound of all SDL-based games
available on the Raspberry Pi.
:Framebuffer for UEFI and Coreboot:
By moving away from the legacy BIOS boot mechanism, it is time to
reconsider closely related traditional approaches such as the use of
the VESA BIOS extensions for accessing the frame buffer. On UEFI or
Coreboot systems, there exist alternative ways to initialize and
access the framebuffer in a hardware-independent way. On the course of
this project, we will explore the available options and create dedicated
Genode driver components that use the modern mechanisms.
For reference, the current state of Genode's UEFI support is documented
in [https://github.com/genodelabs/genode/issues/2242 - Issue 2242].
:Data Plane Development Kit (DPDK):
Genode utilizes the network device drivers of the iPXE project, which
@ -332,22 +357,8 @@ Platforms
Genode functionality such as its native GUI, lwIP, and Noux, many protocol
stacks can effectively be removed from the Linux kernel.
In 2018, Johannes Kliemann pursued this topic to a state where Genode
could be used as init process atop a customized Linux kernel.
[https://lists.genode.org/pipermail/users/2018-May/006066.html - His work]
included the execution of Genode's regular device drivers for VESA and
PS/2 as regular Genode components so that Genode's interactive demo
scenario ran happily on a laptop. At this time, however, only parts of
his results were merged into Genode's mainline.
The goal of this project is to follow up on Johannes' work, bring the
[https://github.com/genodelabs/genode/pull/2829 - remaining parts] into
shape for the inclusion into Genode, and address outstanding topics, in
particular the handling of DMA by user-level device drivers. Further down
the road, it would be tempting to explore the use of
[https://en.wikipedia.org/wiki/Seccomp - seccomp] as sandboxing mechanism
for Genode on Linux and the improvement of the Linux-specific implementation
of Genode's object-capability model.
The goal of this project is to evaluate how small the Linux kernel can get
when used as a microkernel.
:Support for the HelenOS/SPARTAN kernel:
@ -370,46 +381,34 @@ Platforms
kernel is used for Mac OS X, it could represent an industry-strength
base platform for Genode supporting all CPU features as used by Mac OS X.
:Genode on the Librem5 phone hardware:
:Linux process containers for supporting Genode`s resource trading:
Even though there exists a great variety of ARM-based SoCs, Genode
primarily focuses on the NXP i.MX family because it is - in contrast
to most SoCs in the consumer space - very liberal in terms of
good-quality public documentation and reference code, and it scales
from industrial to end-user-facing use cases (multi-media).
The [https://puri.sm/products/librem-5/ - Librem5] project - with its
mission to build a trustworthy mobile phone - has chosen the i.MX family as
the basis for their product for likely the same reasons that attract us.
To goal of this work is bringing Genode to the Librem5 hardware.
For the Librem5 project, Genode could pave the ground towards new use cases
like high-security markets where a regular Linux-based OS would not be
accepted. For the Genode community, the Librem5 hardware could become an
attractive mobile platform for everyday use, similar to how we developers
use our Genode-based [https://genode.org/download/sculpt - Sculpt OS] on our
laptops.
System management
#################
:Remote management of Sculpt OS via Puppet:
[https://en.wikipedia.org/wiki/Puppet_(company)#Puppet - Puppet] is a
software-configuration management tool for administering a large amount
of machines from one central place. Genode's
[https://genode.org/download/sculpt - Sculpt OS] lends itself to such
an approach of remote configuration management by the means of the
"config" file system (for configuring components and deployments) and
the "report" file system (for obtaining the runtime state of components).
The project would explore the application of the Puppet approach and tools
to Sculpt OS.
Even though the Linux version of Genode is primarily meant as a development
platform, there exist interesting opportunities to explore when combining
Genode with Linux, in particular Linux' process containers.
Linux process containers provide a mechanism to partition physical resources,
foremost CPU time, between Linux processes. This raises the interesting
question of whether this mechanism could be used for a proper implementation
of Genode's resource trading on Linux.
[http://lwn.net/Articles/236038/ - Process containers introduction...]
Optimizations
#############
:Low-latency audio streaming:
Genode comes with an audio streaming interface called 'Audio_out' session.
It is based on a shared-memory packet stream accompanied with asynchronous
data-flow signals. For real-time audio processing involving chains of Genode
components, streams of audio data must be carried at low latency, imposing
constraints to buffer sizes and the modes of operation of the audio mixer and
audio drivers. The goal of this project is to create a holistic design of the
whole chain of audio processing, taking thread-scheduling into account. A
particular challenge is the mixed output of real-time (small buffer, low
latency) and non-real-time (larger buffer to compensate jitter, higher
latency) audio sources.
:De-privileging the VESA graphics driver:
The VESA graphics driver executes the graphics initialization code provided

12
doc/components.txt
View File

@ -482,7 +482,13 @@ Libraries:
:'libports/lib/mk/libc':
C runtime ported from FreeBSD.
:'libports/lib/mk/libc_fatfs':
:'libports/lib/mk/libc_lwip_nic_dhcp':
Translates the BSD socket API to a NIC session using the lwIP stack.
:'dde_linux/lib/mk/libc_lxip':
Translates the BSD socket API to a NIC session using the Linux TCP/IP stack.
:'libports/lib/mk/libc_ffat':
Accesses files on a block device that contains a FAT32 file system.
:'libports/lib/mk/libc_fuse_exfat':
@ -491,6 +497,10 @@ Libraries:
:'libports/lib/mk/libc_fuse_ext2':
Accesses files on a block device that contains an ext2 file system.
:'libports/lib/mk/libc_terminal':
Connects the standard input and output from/to Genode's terminal session
interface.
:'libports/lib/mk/stdcxx':
Standard C++ library

11
doc/getting_started.txt
View File

@ -53,15 +53,14 @@ architecture independent from the underlying base platform, in this case Linux.
To give Genode a try, build and execute a simple demo scenario via:
! cd build/x86_64
! make KERNEL=linux BOARD=linux run/demo
! make KERNEL=linux run/demo
By invoking 'make' with the 'run/demo' argument, all components needed by the
demo scenario are built and the demo is executed. This includes all components
which are implicitly needed by the base platform. The base platform that the
components will be executed upon on is selected via the 'KERNEL' and 'BOARD'
variables. If you are interested in looking behind the scenes of the demo
scenario, please refer to 'doc/build_system.txt' and the run script at
'os/run/demo.run'.
components will be executed upon on is selected via the 'KERNEL' variable. If
you are interested in looking behind the scenes of the demo scenario, please
refer to 'doc/build_system.txt' and the run script at 'os/run/demo.run'.
Using platforms other than Linux
@ -113,7 +112,7 @@ steps are required:
# Uncomment the following line in 'x86_32/etc/build.conf'
! REPOSITORIES += $(GENODE_DIR)/repos/libports
# Build and execute the demo using Qemu
! make -C build/x86_32 KERNEL=okl4 BOARD=pc run/demo
! make -C build/x86_32 KERNEL=okl4 run/demo
The procedure works analogously for the other base platforms. You can, however,
reuse the already created build directory and skip its creation step if the

187
doc/news.txt
View File

@ -3,193 +3,6 @@
Genode News
===========
Genode OS Framework release 19.11 | 2019-11-28
##############################################
| Following this year's theme of "bridging worlds", Genode 19.11 adds the
| ability to use popular build tools like CMake for application development,
| introduces a new virtual-machine monitor for 64-bit ARM, and enhances
| POSIX compatibility. As another highlight, it features the first version
| of our custom block-device encrypter.
Block-device encryption is a feature often requested by users of our Sculpt OS.
Until now, we deliberately left this topic unaddressed because we felt that a
profound answer was beyond our expertise. However, during the past year, we
dived deep into it. The result is the prototype for a new block encrypter that
encrypts data but also protects integrity and freshness. For us, the
implementation of the encrypter is especially intriguing because - with about
7000 lines of code - it is Genode's first non-trivial component written in the
[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
programming language.
The second major addition is a new virtual machine monitor (VMM) for 64-bit
ARM platforms such as the NXP i.MX8. It leverages the
[https://genode.org/documentation/articles/arm_virtualization - proof of concept]
we developed in 2015 for ARMv7, which we pursued as a technology exploration.
In contrast, our aspiration with the new VMM is a product-quality solution.
In our [https://genode.org/about/road-map - road map] for 2019, we stated
the "bridging of worlds" as our overall theme for this year. On that account,
the current release moves the project forward on two levels. First, by
successively increasing the scope of POSIX compatibility, we reduce the
friction when porting existing application software to Genode. We managed
to bridge several gaps in our POSIX support that we considered as impossible
to cover some years ago. In particular, we identified ways to emulate certain
POSIX signals, ioctl calls, and fork/execve semantics. This way, popular
software such as bash, coreutils, or Vim can now be executed as regular
Genode components with no additional runtime environment (like Noux or a VMM)
required.
At a higher level, the current release introduces new tooling especially
geared at the development and porting of application software. Compared to
Genode's regular development tools, which were designed for whole-system
development, the new tool called Goa relieves the developer from the
complexity of Genode's custom build system and instead promotes the use of
popular commodity solutions like CMake.
These and more topics are described in the
[https:/documentation/release-notes/19.11 - release documentation of version 19.11...]
Genode OS Framework release 19.08 | 2019-08-28
##############################################
| Genode 19.08 puts emphasis on practical concerns ranging from
| keyboard layouts, over system-time management, to remote system
| administration. It also continues our commitment to the 64-bit ARM
| i.MX8 SoC, comes with Qt5 version 5.13, and improves POSIX compatibility.
The summer release of Genode addresses a variety of topics when using Genode
and Sculpt OS in practice. The confrontation with the real world prompted us
to develop new concepts for managing system time, keyboards layouts, and
copy-and-paste. For using Sculpt OS on the road, a new application VM for
accessing captive portals smoothes the experience of connecting to public WiFi
networks.
Besides the practical focus, the new release continues our commitment to the
64-bit ARM i.MX8 platform through new kernel support, device drivers, and test
coverage. Further topics include SMBIOS support for commodity PC hardware, a
new tracing tool, enhanced POSIX compatibility, and a major update of Qt5 to
version 5.13.
The complete picture is presented in the
[https:/documentation/release-notes/19.08 - release documentation of version 19.08...]
Sculpt OS release 19.07 | 2019-07-09
####################################
| Version 19.07 of the Sculpt operating system improves overall performance
| and introduces copy and paste between terminals, virtual machines, and
| graphical applications.
The most prominent user-visible feature of Sculpt OS 19.07 is the ability
of copy and paste text between terminals, graphical applications, and
virtual machines. Our unique take on this feature is described in
a [https://genodians.org/nfeske/2019-07-03-copy-paste - dedicated article].
Under the hood, Sculpt 19.07 benefits from the massive infrastructure
improvements that came with
[https://genode.org/documentation/release-notes/19.05 - Genode 19.05],
yielding a smoother user experience compared to earlier versions.
The new release can be obtained from the
[https://genode.org/download/sculpt - Sculpt download page] and is
accompanied by updated
[https://genode.org/documentation/articles/sculpt-19-07 - documentation].
Genode OS Framework release 19.05 | 2019-05-29
##############################################
| The highlights of version 19.05 are a new kernel-agnostic virtualization
| interface, initial support for the 64-bit ARM architecture, the use of
| C++17 by default, a new tool chain based on GCC 8.3, updated C and SPARK
| runtimes, and the consolidation of build directories across boards.
We dedicated the release cycle of Genode 19.05 to platform topics at various
levels. The flagship feature is certainly the introduction of our
kernel-agnostic virtualization interface. It has been in the works for more
than a half year and gives us the prospect of running virtual machine monitors
like Seoul and VirtualBox seamlessly across Genode's supported kernels.
The second major theme is the extension of Genode's CPU-architecture support
to 64-bit ARM (AARCH64). This step motivated the update of many parts of the
framework's fundamental infrastructure, ranging from the tool chain (updated
to GCC 8.3), over the C runtime (updated to FreeBSD 12 libc), to the dynamic
linker. The new tool chain, in turn, paved the ground for enabling C++17 by
default.
With the diversity of kernels, CPU architectures, and boards growing, we are
constantly striving to remove friction and redundancies between Genode's
underlying platforms. The current release eventually consolidates the build
directories not only across kernels but also across all boards of a given
CPU architecture. This vastly increases the velocity of Genode-based system
scenarios when targeting multiple boards or emulators at the same time.
Further details about these and many more improvements are given in the
[https:/documentation/release-notes/19.05 - release documentation of version 19.05...]
Sculpt as a Community Experience | 2019-03-19
#############################################
| The fourth stage of Sculpt OS introduces a new federated software
| provisioning model while giving the user full control over the
| component deployment via a novel graphical user interface.
With Sculpt CE, we enter the final stage of the evolution of Sculpt OS as
envisioned roughly one year ago. Initially geared towards die-hard enthusiasts
only, each revision became more and more user friendly. The previous version
Sculpt VC already offered a glimpse of Sculpt's unique user interface in the
form of an interactive component graph.
The just released Sculpt OS "as a community experience" (CE) combines this
tangible notion of component compositions with a completely federated software
provisioning model that cuts out middlemen like an app store or a
distribution. With Sculpt CE, components can be offered by a federation of
independent software providers selectable by the user. The software
installation is sandboxed and protected via digital signatures. The
integration of components with the rest of the system is completely under
control by the user. With the principle of least privilege at the heart
of Sculpt's architecture, you - the user - can fearlessly install and run
software without the need to ultimately trust the software providers.
Sculpt CE is intended to work in tandem with the new community blog
[https://genodians.org - Genodians.org] where developers and users exchange
experiences and announce new software. The best way to watch how the
Sculpt story continues is the RSS feed of Genodians.org.
To dive into the new world of Sculpt CE,
[https://genode.org/download/sculpt - download Sculpt OS...]
Genodians.org | 2019-03-08
##########################
| Genodians.org is the new place to be for getting the latest news and stories
| around Genode. It is a federated blog by and for developers and users
| alike.
With [https://genodians.org - Genodians.org], the Genode community has gained
a new place for exchanging ideas, announcing current developments, giving
tutorials, and sharing experience stories. In contrast to the formal character
of Genode's regular release notes, the articles at Genodians.org are raw and
personal, authored by individuals with no editorial process. For feedback
about the articles, readers are invited to the new
[https://reddit.com/r/genode - /r/genode] subreddit.
As written in the
[http://genodians.org/nfeske/2019-01-07-welcome - initial posting],
Genode users and developers are warmly invited to join the authors at
Genodians.org!
As a side note, the blogging platform is based on the Genode OS framework and
is of course open source
([https://github.com/genodelabs/genodians.org - GitHub repository]).
[https://genodians.org - Visit Genodians.org...]
Genode OS Framework release 19.02 | 2019-02-28
##############################################

10
doc/release_notes-19-02.txt
View File

@ -130,7 +130,7 @@ Using this interactive work flow, the discovery of software and its
integration becomes a rather playful process.
To make a once composed system permanent, one can use the inspect window to
copy the _/config/managed/deploy_ file to the _config/19.02/_ directory of your
copy the _/config/managed/deploy_ file to the _config/19.02/ directory of your
Genode partition. This way, the deployment configuration will take effect
immediately at boot time.
@ -149,8 +149,8 @@ Announcing software packages
The community experience of Sculpt CE will ultimately depend on the
participation of software providers. To become listed in the selection dialog
mentioned above, you may consider including your public key and download
location at the Genode repository at
[https://github.com/genodelabs/genode/tree/master/depot - /depot/].
location at the Genode repository
[https://github.com/genodelabs/genode/tree/master/depot - at /depot/].
For the announcement of packages, a software provider can publish so-called
"index" files for a particular Sculpt version in the software provider's
@ -177,7 +177,7 @@ Index files can be published like any other depot content using the
_depot/publish_ tool, which takes care about compressing and digitally signing
the published information:
! ./tool/depot/publish nfeske/index/19.02
| ./tool/depot/publish nfeske/index/19.02
To ease the updating of the index with current package versions, the
_sculpt.run_ script creates the _depot/index/<version>_ file from the input
@ -698,7 +698,7 @@ framework but rather supplemental. In particular, it contains ports of
3rd-party software to Genode. The pool of ported software is steadily growing,
which moves the world repository more and more into the spotlight of Genode
users. For example, among a variety of games and experimental components, our
port of OpenJDK ([Java]) is also hosted there. To acknowledge the growing
port of [Java - OpenJDK] is also hosted there. To acknowledge the growing
importance of the world repository, we added the building of all world depot
archives to our nightly build tests.

886
doc/release_notes-19-05.txt
View File

@ -1,886 +0,0 @@
===============================================
Release notes for the Genode OS Framework 19.05
===============================================
Genode Labs
The Genode release 19.05 is primarily focused on platform support.
It adds compatibility with the 64-bit ARM architecture (AARCH64),
comes with improvements of the various kernels targeted by the framework,
and extends the list of supported hardware. The increased diversity of base
platforms calls for unifications to keep the hardware and kernel landscape
manageable.
On that account, Genode uses one reference tool chain across all kernels
and CPU architectures. The current release upgrades this tool chain to
*GCC 8.3* with C++17 enabled by default
(Section [Tool chain based on GCC 8.3.0 and binutils 2.32]).
To increase the velocity of Genode system scenarios across different boards
of a given CPU architecture, the release introduces the notion
of *board and kernel-agnostic build directories* presented in Section
[Unified build directories for ARM]. Once built for one particular
CPU architecture, the same binaries can be deployed at any supported board or
kernel without recompilation. This vastly accelerates the workflow when
targeting multiple boards and emulators at once.
As another major unification effort, the current release introduces a new
*kernel-agnostic virtualization* interface. Up until now, virtualization
used to be inherently tied to a specific kernel. Thanks to the new interface,
however, one virtual machine monitor implementation can be combined with
kernels as different as NOVA, seL4, or Fiasco.OC. No recompilation needed.
As outlined in Section [Kernel-agnostic virtual-machine monitors], Genode
has now become able to run the Seoul VMM on all those kernels, while
VirtualBox is planned to follow.
On our [https://genode.org/about/road-map - road map], we originally
planned several user-facing features related to Sculpt OS. However, in the
light of the major platform efforts, we decided to defer those topics instead
of rushing them.
That said, the release is not without new features. For example, our port
of *OpenJDK* has become able to host the Spring framework and the Tomcat web
server, there are welcome improvements of the *package-management tooling*,
and we added new options for user-level networking.
Finally, version 19.05 is accompanied with the annual revision of the *Genode*
*Foundations book* (Section [New revision of the Genode Foundations book]),
which is now available as an online version in addition to the regular PDF
document.
Kernel-agnostic virtual-machine monitors
########################################
Since the introduction of Genode's
[https://genode.org/documentation/release-notes/17.02#Genode_Application_Binary_Interface - Application Binary Interface]
in the 17.02 release,
Genode components can be assembled once for a given hardware platform and
executed without further adjustments on all the supported kernels. However, at
that time, the supported virtual machine monitors - a port of VirtualBox 4 & 5,
Seoul, and our
[https://genode.org/documentation/articles/arm_virtualization - custom VMM] -
remained kernel specific.
Of course, last remaining bastions tempt to be taken! So last year, we started
the venture to unify our virtualization interface across different kernels.
Starting point was the already existing Genode VM interface of our custom VMM
on ARM. We took it and extended the interface with caution to the x86 world.
Having an eye on the requirements of our already supported VMMs on NOVA(x86),
namely VirtualBox and Seoul, the VM interface got extended with missing
features like multiple vCPU support and specific VM handlers per vCPU.
In parallel, we started to investigate the other x86 microkernels with regard
to hardware-assisted virtualization features, namely seL4 and Fiasco.OC.
Over several weeks, we iteratively extended the interface. On the one hand
we familiarized ourself with the kernel interfaces of seL4 & Fiasco.OC while
on the other hand considered known requirements of the NOVA microhypervisor.
Additionally, we kept our custom VMM for ARM still compatible with the new VM
interface.
During this time, it became apparent that the control flow on a VM resume/pause
and a VM event(exit) are different between seL4/Fiasco.OC and NOVA/base-hw.
For seL4 and Fiasco.OC, a VM is resumed by making a blocking syscall on the
kernel. On a VM event, the blocking syscall would return. Logically, on both
kernels the VMM 'calls' into the VM.
On base-hw and NOVA, it is the other way around. Whenever a VM causes a VM
event, the kernels set up either an asynchronous notification (base-hw) or a
synchronous IPC call (NOVA) to the VMM. In both cases the VMM executes a prior
registered VM event handler as response.
Upon return of the VM event handler, the kernel resumes the VM. Logically, on
NOVA and base-hw the VM 'calls' into the VMM. The following two figures
contrast the different flows of control between a user-level virtual machine
monitor and the respective kernels.
[image vm_seq_foc_sel4]
Control flow of handling virtualization events on Fiasco.OC and seL4
[image vm_seq_nova_hw]
Control flow of handling virtualization events on NOVA and the base-hw kernel
Hiding this differences behind a common VM interface was the challenge we were
faced, accepted, and won. Finally, at one point in December we had all 3
x86 kernels running with a test VMM - without re-compilation. The toy VMM
(vmm_x86.run) runs multiple vCPUs on multiple physical CPUs and tests several
VM events/exits.
After this major breakthrough, we spent the days left before Christmas to
adjust the Seoul VMM to the new VM interface, freeing it from the ties to the
NOVA kernel. The choice to start with Seoul stems from the fact that it is -
compared to VirtualBox - much smaller and therefore easier to debug if things
go wrong in the beginning. After one week, the Seoul VMM became in principle
kernel independent and worked again on NOVA. After some more days, it started
to hobble on seL4 and Fiasco.OC as well.
With the New Year, VirtualBox was the next target where all NOVA kernel
specific calls were replaced with the new Genode VM interface. Mid of January,
the work showed first results by having a prototype running simple VMs on NOVA
again. At this point, it became apparent that this venture is not anymore an
adventure. All the findings and technical details so far got condensed to a
[https://fosdem.org/2019/schedule/event/microkernel_virtualization - presentation]
given and recorded at the [https://fosdem.org/2019 - FOSDEM 2019] in Brussels
in February in the
[https://fosdem.org/2019/schedule/track/microkernels_and_component_based_os - Microkernel and Component based OS]
developer room.
At this point, we started transforming our prototype for the 4 kernels into a
clean solution to be featured in Genode 19.05. Eventually, the kernel-agnostic
Seoul VMM runnable on seL4, Fiasco.OC, and NOVA entered Genode master. In the
Genodians article
[https://genodians.org/alex-ab/2019-05-09-seoul-vmm - Seoul VMM and the new VM interface],
we conserved the current state and a few performance measurements.
Shortly before this release, the kernel-agnostic VirtualBox VMM version on
Genode/NOVA got ready. The kernel-agnostic version is in principle capable to
run Linux VMs and Windows 7/10 VMs on Genode/NOVA. Currently, this version
must still be considered as experimental and does not run on seL4 or
Fiasco.OC.
Because of the experimental nature of the kernel-agnostic VirtualBox VMM
version, we decided to keep the kernel-specific version for NOVA for the
moment. This gives us time to test and improve the kernel-agnostic version. It
also allows us to compare both versions to each other.
If time and interest permits, we will consider bringing the virtualization
support on Genode/seL4 and Genode/Fiasco.OC on par with Genode/NOVA.
When building VirtualBox with Genode 19.05,
you will find both the 'virtualbox5-nova' and the new 'virtualbox5' binaries
in the build directory. The former relies on NOVA's kernel interface whereas
the latter uses Genode's kernel-agnostic VM interface. Nightly tested run
scenarios with the new VM interface are named 'vbox5_vm*.run' and can be found
in the 'repos/ports/run' directory.
Broadened CPU architecture support and updated tool chain
#########################################################
With the major update of Genode's tool chain and library infrastructure in
tandem, the framework gains a consistent architecture support across x86-32,
x86-64, ARM-32, RISC-V, and the newly added AARCH64. This includes the tool
chain (Section [Tool chain based on GCC 8.3.0 and binutils 2.32]), the base
framework, the dynamic linker, and the C runtime
(Section [Updated dynamic linker and C runtime]).
Together with this update, we took the chance to wrap up our long-time move
away from board-specific build directories to one generic build directory
shared by multiple kernels and boards for a given CPU architecture
(Section [Unified build directories for ARM]).
Tool chain based on GCC 8.3.0 and binutils 2.32
===============================================
Genode uses a tailored tool chain based on GCC and binutils that is used
across all supported kernels and architectures. Since the previous tool-chain
update in version
[https://genode.org/documentation/release-notes/17.05#Tool_chain - 17.05],
we relied on GCC 6.3. After two years, it was time for an update, motivated by
three major reasons. First, the C++17 standard is common-place now. We Genode
developers anticipate the improvements that come with it. Second, RISC-V and
AARCH64 are now supported by mainline GCC. Up till now, we had to maintain a
custom patch set for Genode's RISC-V support. AARCH64 was not supported yet.
Third, our increasing engagement with SPARK depends on recent improvements of
the Ada compiler that is part of GCC.
With Genode 19.05, the tool chain is now based on binutils version 2.32, GCC
version 8.3.0, GDB version 8.2.1, gcov version 8.3.0, standard C++ library
version 8.3.0.
The tool chain supports x86 (32 and 64 bit), ARM, AARCH64, and RISC-V.
For C++ code, the C++17 standard is enabled by default.
The update of the tool chain provided a perfect opportunity to replace the
former use of gnatmake with a much more natural integration of Ada in Genode's
build system, using a custom ali2dep dependency-extraction tool developed
by [https://github.com/Componolit/ali2dep - Componolit].
In contrast to the previous versions, we switched to a versioned installation
directory for the new tool chain. By default, it is now installed to
_/usr/local/genode/tool/19.05/_. This eases the use of different tool-chain
versions for different development branches.
:Tool-chain installation:
[https://genode.org/download/tool-chain]
Caveats
-------
The tool-chain update required a number of adaptations throughout the source
tree, and may affect Genode users too:
* The silent fall-though within switch statements must now be replaced
by an explicit annotation of the form
! [[fallthrough]]
* The 'register' keyword is no longer valid with C++17. Hence, it must
be removed from the code.
* Types marked as 'Noncopyable' can no longer have an implicit default
constructor. A default constructor must be provided manually.
Updated dynamic linker and C runtime
====================================
The tool-chain update is accompanied with a major update of the dynamic linker
and the C runtime to cover both the AARCH64 and RISC-V architectures in
addition to the traditional x86 and ARM architectures.
FreeBSD 12 supports AARCH64 and RISC-V. Hence, by updating our C runtime to
this version, Genode's libc support extends to those architectures now.
Until now, Genode's dynamic linker supported only the eager binding of symbols
at loading time on the *RISC-V* architecture. With the current version, we
lifted this limitation in favor of lazy binding as used on all other CPU
architectures.
Unified build directories for ARM
=================================
In version
[https://genode.org/documentation/release-notes/17.02#Genode_Application_Binary_Interface - 17.02],
we introduced unified build directories for x86, which allow us to build and
run Genode scenarios on various kernels while using only one build directory.
This concept leverages Genode's cross-kernel binary compatibility to make
the switch from one kernel to another - like developing on base-linux and
deploying on base-nova - a seamless experience.
On ARM, this concept was held back by a third dimension. The
system-integration step does not only depend on the CPU architecture and
the kernel but also on the used board. Our traditional approach was the
use of one build directory per board. Granted, within such a build directory,
one could easily switch between different kernels like Fiasco.OC and seL4.
But on ARM, we find an extreme proliferation of different board
configurations, which share the same CPU architecture but demand different
integration steps. This ensues large redundancies among different build
directories. Switching from one board to another - even when most binaries
happen to be exactly the same - requires an additional rebuilding effort.
With version 19.05, we took the chance to generalize the unified build
directory concept to support multiple different boards per build directory,
greatly reducing the friction when switching kernels and boards for a given
CPU architecture (like ARMv7a). This change has the following implications:
* Drivers no longer depend on the SPEC values as configured for a build
directory.
* All *binaries* are now *named unambiguously*. For example, the USB drivers
for the Panda (OMAP) and Arndale (Exynos) boards were formerly called
'usb_drv' but were different programs. They just never happened to
appear in the same build directory. In the new version, they are named
'panda_usb_drv' and 'arndale_usb_drv' respectively and can thereby
peacefully co-exist within the same 'armv7a' build directory.
Note that this binary renaming will likely affect existing run scripts.
* Include paths no longer hide the board details, which makes the included
code much more easy to follow.
* Run scripts need to pick the right binary, depending on the used board.
Since the board is no longer tied to a build directory, the selection
of the used board has become a build-time variable 'BOARD' following
the successful pattern of how we specify the targeted 'KERNEL'.
To avoid the pollution of run scripts with difficult conditions, we wrap
the drivers needed for a particular board and use case into so-called
_drivers_ packages. Such a package can be instantiated within a generic
scenario using a nested init instance. The details about the drivers and
how they access the hardware remain nicely hidden inside this building block.
Currently, there exist _drivers_ packages for two distinct use cases:
:drivers_interactive pkgs: contain all drivers needed for simple
interactive scenarios, including graphical output and user input.
:drivers_nic pkgs: contain the drivers needed for communication over the
network.
Whenever a run script fits one of these use cases, it can rely on the
corresponding ready-to-use drivers packages via:
! import_from_depot [depot_user]/src/[base_src] \
! [depot_user]/pkg/[drivers_nic_pkg] \
! ...
With the drivers package incorporated, the drivers subsystem can be
instantiated as follows (note the absence of any board or kernel-specific
details):
! <start name="drivers" caps="1000">
! <resource name="RAM" quantum="32M" constrain_phys="yes"/>
! <binary name="init"/>
! <route>
! <service name="ROM" label="config">
! <parent label="drivers.config"/> </service>
! <service name="Timer"> <child name="timer"/> </service>
! <any-service> <parent/> </any-service>
! </route>
! <provides> <service name="Nic"/> </provides>
! </start>
Using the 'BOARD' build variable
--------------------------------
The new 'BOARD' variable selects the board to use. It can be specified either
as a 'make' command-line argument (or environment variable), or defined in the
build-directory configuration (_etc/build.conf_). The following boards are
available:
:arm_v6: rpi
:arm_v7a: arndale, imx53_qsb, imx53_qsb_tz, imx6q_sabrelite, imx7d_sabre,
nit6_solox, odroid_x2, odroid_xu, panda, pbxa9, usb_armory,
wand_quad, zynq_qemu
:arm_v8a: rpi3
:x86_64: pc, linux, muen
:x86_32: pc, linux
:riscv: spike
Please note, when running Genode on Linux or the Muen separation kernel -
although it is run on common x86 PC hardware - we treat both runtime
environments as separate "boards" because their device driver environments
are fundamentally different.
New revision of the Genode Foundations book
###########################################
The "Genode Foundations" book received its annual update, which is actually
rather a refinement than a revision. The noteworthy additions and changes are:
: <div class="visualClear"><!-- --></div>
: <p>
: <div style="clear: both; float: left; margin-right:20px;">
: <a class="internal-link" href="https://genode.org">
: <img class="image-inline" src="https://genode.org/documentation/genode-foundations-title.png">
: </a>
: </div>
: </p>
* Component health monitoring
* Static code analysis
* Documentation of --depot-user and --depot-auto-update
* Minor adjustments in the under-the-hood chapter
* Changes of the build system
* Updated tool requirements
* Updated API reference
: <div class="visualClear"><!-- --></div>
To examine the changes in detail, please refer to the book's
[https://github.com/nfeske/genode-manual/commits/master - revision history].
New online version of the book
------------------------------
We are happy to announce that the Genode Foundations book is now available
as an online version in addition to the regular PDF version.
:Browse the Genode Foundations book online:
[https://genode.org/documentation/genode-foundations/19.05/index.html]
Thanks a lot to Edgard Schmidt for creating the tooling for the HTML version
of the book!
Base framework and OS-level infrastructure
##########################################
Modernized block-storage interfaces
===================================
With the current release, we revisited Genode's interfaces for accessing
block devices to ease the implementation of asynchronous I/O, to accommodate
zero-copy block drivers, and to support trim and sync operations.
Revised RPC interface
---------------------
The 'Block::Session' RPC interface remained untouched for a long time.
We have now rectified long-standing deficiencies.
First, *sync requests* used to be handled as synchronous RPCs. This is bad
for components like part_block that multiplex one block device for multiple
clients. One long-taking sync request of one client could stall the I/O for
all other clients. The new version handles sync requests as asynchronous
block-request packets instead.
Second, the new version allows a server to dictate the *alignment* of
block-request payload. This way, a driver becomes able to use the payload
buffer shared between client and server directly for DMA transfers while
respecting the device's buffer-alignment constraints.
Third, we added support for *trim* as an asynchronous block operation.
However, as of now, this operation is ignored by all servers.
Fourth, each block operation can now be accompanied with a client-defined
request tag independent from the other parameters of the operation. The tag
allows a block-session client to uniquely correlate acknowledgments with
outstanding requests. Until now, this was possible for read and write
operations by taking the value of the request's packet-stream offset. However,
sync and trim requests do not carry any packet-stream payload and thereby lack
meaningful and unique offset values. By introducing the notion of a tag, we
can support multiple outstanding requests of any type and don't need to
overload the meaning of the offset value.
New client-side API
-------------------
We have now equipped the 'Block::Connection' with a framework API for the
implementation of robust block-session clients that perform block I/O in an
asynchronous fashion.
An application-defined 'JOB' type, inherited from 'Connection::Job',
encapsulates the application's context information associated with a block
operation.
The life cycle of the jobs is implemented by the 'Connection' and driven by
the application's invocation of 'Connection::update_jobs'. The 'update_jobs'
mechanism takes three hook functions as arguments, which implement the
applications-defined policy for producing and consuming data, and for the
completion of jobs.
We plan to gradually move the existing block clients to the new API to benefit
from the latency-hiding effects of asynchronous I/O. The first updated client
is the _block_tester_ component located at _os/src/app/block_tester/_, which
received a number of new features like the choice of the batch size. Please
refer to the accompanied README for a detailed description of the
block-tester.
Unified types for time values
=============================
[https://genode.org/documentation/release-notes/17.05#New_API_for_user-level_timing - Two years ago],
we introduced the so-called timeout framework to provide a general solution
for requirements unmet by the bare timer-session interface - most notably
timer-session multiplexing amongst multiple timeouts, and microseconds
accuracy. Up to this day, the timeout framework has proved itself many times
in both real-life appliances and artificial tests and has become the standard
front end for timing in Genode applications.
With this release, we solved one of the few remaining limitations with the
framework by enabling timeouts of up to 2^64 microseconds (> 500000 years)
across all supported architectures. In order to achieve this, we replaced the
former machine-word-wide types used for plain time values by unsigned 64-bit
integers. We did this not only inside the timeout framework but also to almost
all code in the basic Genode repositories that uses the framework.
By doing so, we also paved the way for a second step, in which we are planning
to replace plain time values as far as possible with the abstract 'Duration'
type. With this type in place, the user wouldn't have to worry anymore about
any plain-integer implications when calculating with time values.
Support for chained EBR partitions
==================================
Having an active community around Sculpt leads to bugfixes in unexpected
places. By now we prefer to use a GPT rather than an MBR based partition table
and although we test 'part_block', the component that parses the tables, on
regular basis, the handling of chained EBR's was flawed. Community member
[https://genodians.org/valerius/index - Valery Sedletski] who relies on such a
setup encountered this flaw and provided a bug report, which enabled us to
quickly reproduce and fix the problem.
IP forwarding with port redirection
===================================
The NIC router can now be used to redirect to individual destination ports on
port-forwarding. To express the redirection, the new 'to_port' attribute can
be added to '<tcp-forward>' and '<udp-forward>' rules in the NIC router
configuration. If the new attribute isn't added, the rules behave as usual and
forward with an unaltered destination port.
Libraries, languages, and applications
######################################
Ada/SPARK runtime and SPARK-based cryptography
==============================================
The SPARK runtime has been updated to GCC 8.3. SPARK components do not require
'Genode::Env' or a terminal session anymore. Debug messages can still be
printed using 'GNAT.IO', which uses 'Genode::log' and 'Genode::error'
internally now.
Threading support, which was never fully implemented, has been removed to
further simplify the runtime. This simplification allowed us to prove absence
of runtime errors for the secondary stack allocator and other parts of the
runtime.
[https://github.com/Componolit/libsparkcrypto.git - Libsparkcrypto] is a
library of common cryptographic algorithms implemented in SPARK. It is
free-standing and has a very small footprint. The port of libsparkcrypto for
Genode has been added to the libports repository. Thanks to Alexander Senier
and Johannes Kliemann of [https://componolit.com - Componolit] for maintaining
the Ada/SPARK runtime and libsparkcrypto.
To accommodate the use case of block encryption, we added the small wrapper
library 'aes_cbc_4k' around libsparkcrypto that provides a simple C++
interface for the en/decryption of 4 KiB data blocks. It uses AES-CBC while
incorporating the block number and the private key as salt values.
Improved resilience of the sequence tool
========================================
We have a simple component that starts other components sequentially. It
will exit whenever one of those components has exited with an error.
However, this component is used by our [https://genodians.org - Genodians]
appliance where it controls the content-update mechanism. Since updating
involves fetching content via HTTP/S depending on external events, e.g.,
the remote site is not reachable, the sequence tool might exit. In a long
running appliance, this is obviously not a useful action where no one is
in place to restart the sequence tool. Rather than increasing the overall
complexity of the appliance by introducing such a management component, we
added a _keep-going_ feature to the sequence tool that will instruct it
to carry on even if one of the started components has failed.
Please look at _repos/os/src/app/sequence/README_ for instructions on
how to use the feature.
NIC-bus server for private LANs
===============================
The 'nic_bus' server was added to the world repository as an alternative
to the 'nic_router' and 'nic_bridge' components. The name may be a slight
misnomer, but this component acts neither as a hub, switch, or router.
The 'nic_bus' implements unicast and multicast Ethernet packet switching
between sessions, but drops any unicast packet not destined for a session
attached to the bus. This is in opposition to the behavior of a typical
Ethernet switch and is intending to create simple, software-defined
local-area-networks for native components as well as virtual machines.
In practice the component has been used for attaching VMs to the
[https://yggdrasil-network.github.io/ - Yggdrasil] overlay network via
a bus-local IPv6 prefix.
Distributed Genode
==================
In
[https://genode.org/documentation/release-notes/16.08#Network-transparent_ROM_sessions_to_a_remote_Genode_system - 16.08],
we initially released the _remote_rom_ components that act as communication
proxies. A communication proxy transparently relays a particular service to
another Genode system. As the name suggests, the remote_rom relays ROM
sessions.
Originally implemented as a proof of concept using bare IP packets, broadcast
MACs and static configuration of IP addresses, we added several improvements
to allow a more general use. First, we adopted the size-guard idea for packet
construction and processing from the NIC router. Furthermore, we adopted the
single-threaded implementation style that was already established in other NIC
components. Thanks to Edgard Schmidt for this contribution. Second, we
implemented ARP requests to eliminate broadcasting. Third, we moved from bare
IP packets to UDP/IP and implemented a go-back-N ARQ strategy in order to
reliably transmit larger ROM dataspaces.
As the remote_rom proved valuable for distributing functionality across
multiple Genode devices, we also applied this concept to the LOG session in
order to transmit LOG output from a headless Genode device to a
[https://genode.org/download/sculpt - Sculpt] system for instance. The udp_log
component provides a LOG service and sends the LOG messages as UDP packets to
another machine. The log_udp reverses this process by receiving these UDP
packets and forwarding the messages to a LOG service. An example can be found
in the world repository at _run/udp_log.run_ and _run/log_udp.run_.
Seoul and VirtualBox virtual machine monitors
=============================================
Besides the conversion of the Genode back end of Seoul to the new VM
interface, we added mouse-wheel support to the PS/2 model and changed the VMM
to request a single GUI/nitpicker session rather than distinct framebufer and
input sessions.
Similar to the Seoul VMM, the VirtualBox VMM was adjusted to the new VM
interface and now uses the GUI/nitpicker session. The original kernel-specific
VirtualBox version tied to the NOVA kernel is still available. Both versions
can be used simultaneously.
Use of Nim decoupled from Genode build system
=============================================
With this release, all integration with Nim tooling has been removed from the
Genode build system as a result of maturing support for additional languages
via Genode SDKs. Building Nim components independently of the Genode source
tree has the benefit of smaller upstream checkouts and faster build times, and
has yielded components such as the
[https://genodians.org/ehmry/2019-03-22-depot_9P - 9P server] used in some
Sculpt developer workflows. An example of an independent build system for Nim
components is
[https://genodians.org/ehmry/2019-04-27-nim_packaging - documented on the Genodians blog].
OpenJDK improvements
====================
Within the 19.05 release cycle, we further improved Genode's OpenJDK support
by enabling additional networking infrastructure required by the
[https://spring.io - Spring Framework]. The improvements especially concern
support for SSL connections, which enabled us to successfully execute an embedded
[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html - Tomcat]
server natively on Genode x86 and ARMv7 platforms using the same JAR archive.
This line of work continues our Java for embedded systems effort as described in
our [https://genodians.org/ssumpf/2019-02-27-java-19-02 - Boot2Java] article.
Having these features in place, our Java efforts will continue in the direction
of Java Swing and the support of input devices in the future, with the ultimate
goal of seamless Java application integration into
[https://genode.org/download/sculpt - Sculpt OS].
Device drivers
##############
Improved Zynq board support
===========================
The initial support of the Xilinx Zynq-7000 SoC was added to our custom kernel
in 15.11. Since then, the support of this hardware has been incrementally
extended. The definitions of memory maps, frequencies, and RAM sizes for
different Zynq-based boards are found in the world repository.
One of the major additions in this release is the initialization of the L2
cache. In this context, we also added a simple cache benchmark at
_repos/os/run/cache.run_ that measures the access times for memory regions of
different size and thereby reveals the number of cache levels and their sizes.
With the latest improvements of the network driver in 18.11, a zero-copy
approach was introduced as an effort to eliminate bottlenecks in the driver's
performance. However, this modification also introduced a kernel dependency of
the driver in order to flush packet-buffer memory from the cache before handing
it over to the DMA-controller. With this release, we moved back to using
uncached dataspaces in order to eliminate the cache flushes and the kernel
dependency. Interestingly, we could not recognize a significant impact on the
driver's performance, which confirms the presumption that flushing the cache
nullifies the gain from using cached dataspaces.
In order to enable the continuous operation of the network driver, we extended
the driver-internal error handling that is necessary to recover the network
driver in certain situations.
_Thanks to Johannes Schlatow for contributing and maintaining Genode's Zynq support!_
Updated Intel network drivers
=============================
As a result of recurring issues with modern Intel i219 laptop NICs, we
updated the driver sources for Intel chipsets to the latest upstream
iPXE version. This update also enables all NIC variants, which were
missing from our manually maintained PCI ID whitelist before.
New drivers-nic and drivers-interactive depot packages
======================================================
As already described in section [Unified build directories for ARM],
_drivers_nic_ packages nicely hide the driver configuration internals needed for
a specific board to communicate over the network. Until now there was only one
package available for x86 based PCs. Now, additional _drivers_nic_ packages
are available for:
:boards: imx53_qsb imx6q_sabrelite linux muen pbxa9 rpi zynq
Beside the formerly available _drivers_interactive_ packages for linux, pbxa9
and pc, there are now additional ones for the following:
:boards: imx53_qsb rpi muen
Platforms
#########
For most kernel environments, the core component provides a ROM module named
'platform_info', which comprises information provided by either the kernel or
the bootloader. The information entails e.g., the TSC clock frequency and
framebuffer dimensions. Most of the information is of interest for special
device driver components only.
Over the time, there was an increasing need to incorporate the information
about which kernel Genode runs on top of. Thereby, special test components,
like depot_autopilot could use the information to, e.g., skip certain tests
on kernels known to not support them. Moreover, there are rare corner-cases
where kernels behave differently, for instance, interrupts are enumerated
differently on certain ARM platforms. Rather than maintaining multiple driver
binaries with different names depending on specific kernels, the
'platform_info' ROM module can now be used to differentiate between kernels
when necessary.
Execution on bare hardware (base-hw)
====================================
This release comes with fundamental optimizations and corrections for
executing Genode on bare hardware when using the core component as the actual
kernel.
In the past, we could observe some serious peculiarities regarding the timing
behavior on the hw kernel. After a careful review, we identified the obstacles
that led to time drifts on several platforms and to quite different runtime
execution.
First and foremost, we limited the CPU-load wasted by the kernel, which
unnecessarily made new scheduling decisions quite often. When the hw kernel
was started as an experiment, there was less focus on performance, but more on
simplicity. Instead of caring about state changes that make a scheduling
decision necessary, the scheduler was asked for the next execution context
unconditionally, whenever the kernel was entered. Now, the scheduler gets
invoked only whenever an execution context gets blocked, or unblocked, or if
the kernel's timer fires due to a timeout. This dramatically influences the
CPU-load caused by the hw kernel in a positive way.
The timing accuracy got increased by reworking most hardware timer drivers
used in the kernel to let the timer never stop counting. Moreover, we limit
the scope in between reading the clock and adjusting the next timeout to a
minimum. The whole internal time representation got widened to 64-bit.
In some rare use cases, we could observe components that do I/O polling, and
thereby actively ask for pending signals, to starve. The reason was a gap in
the hw kernel's syscall API. Beside the ability to wait for signals, the
base-library offers the ability to check for pending signals without blocking
in the case of no available signals. The equivalent call in the kernel was
still missing, and is now present and integrated in the base-library of
base-hw.
ARM architecture
----------------
With this release, we add the i.MX 7 Dual SABRE reference board to the rich
hardware zoo Genode runs directly on top of. This includes the use of the
virtualization extensions available on this platform.
Apart from the new board support, several optimizations were added
specifically for the ARM architecture. Several unnecessary cache maintenance
operations were eliminated, which resided in the code base since the time when
the kernel used a separate address-space only. Moreover, the kernel-lock -
used when several execution contexts on different CPU-cores try to enter the
kernel - does not spin anymore. Instead, the CPU goes into a sleep-state to
save energy. As a side-effect, multi-core scenarios become usable when
executed in Qemu.
X86 architecture
----------------
Since the newly used compiler version makes aggressive use of FPU instructions
including the core component, the kernel itself makes use of FPU registers and
state. Therefore, lazy FPU switching becomes a no go for base-hw. Although, we
incorporated eager FPU switching into the ARM-specific part of the hw kernel
already, the x86 version was still missing it. Now, the FPU context of a thread
gets saved and restored on every kernel entry and exit on x86 too.
Updated Muen separation kernel
==============================
The Muen port has been updated to the latest development version, which comes
with many improvements under the hood. Most notably this version of Muen brings
support for Linux SMP subjects, GNAT Community 2018 toolchain support as well
as much improved build speed, which is most noticeable during autopilot runs.
Additionally, the debug server buffer size in the Genode system policy has been
increased to avoid potential message loss in case of rapid successive logging.
_Thanks to Adrian-Ken Rueegsegger of [https://codelabs.ch - Codelabs] for_
_this welcome contribution!_
NOVA microhypervisor
====================
The kernel got updated due to the tool-chain update to GNU G++ 8.3.0.
Additionally, several issues reported by Julian Stecklina regarding FPU and
page-table synchronization got addressed. The kernel memory allocation at boot
time got more flexible to address target machines with fragmented physical
memory. Additionally, the vTLB implementation is no longer used on AMD
machines whenever nested paging is available.
seL4 microkernel
================
With this release, we extend the variety of hardware to run Genode on top of
the seL4 kernel with NXP's i.MX 7 Dual SABRE reference board. To do so, we had
to update the seL4 tools used to craft a bootable ELF image to a state that is
consistent with the currently supported seL4 kernel version 9.0.1.
As a side-effect of this development work, the General Purpose Timer (GPT) used
in the i.MX series can now be used as a timer service component.
Fiasco.OC microkernel
=====================
As with base-hw and seL4, we add the i.MX 7 Dual SABRE reference board to the
list of working hardware for Genode running on top of the Fiasco.OC
microkernel. Moreover, with Fiasco.OC it is now possible to take the first
steps using Genode on the ARM 64-bit architecture. Therefore, we add Raspberry
Pi 3 as a candidate board to be used with Genode/Fiasco.OC. Currently, only
basic tests without peripheral dependencies are supported.
Tooling and build system
########################
Improved handling of missing ports
==================================
The depot tools _tool/depot/create_ and _tool/depot/extract_ now detect and
report all missing third-party sources - called ports - for a given set of
archives at once. Additionally, the user can tell the tools to download and
prepare such missing ports automatically by setting the argument
'PREPARE_PORTS=1'. Please be aware that doing so may cause downloads and
file operations in your _contrib/_ directory without further interaction.
These features make building archives with dependencies to many ports more
enjoyable. If you merely need a list of ports that are missing for your
archives, you can use the new tool _tool/depot/missing_ports_.
For more details you may read the
[https://genodians.org/m-stein/2019-05-21-depot-missing-ports - article on genodians.org].
Automated depot management
==========================
When using the 'import_from_depot' mechanism of the run tool, one frequently
encounters a situation where the depot lacks a particular archive. Whenever
the run tool detects such a situation, it prompts the user to manually curate
the depot content via the _tool/depot/create_ tool. The need for such manual
steps negatively interferes with the development workflow. The right manual
steps are sometimes not straight-forward to find, in particular after
switching between Git branches.
To relieve the developer from this uncreative manual labor, we extended the
run tool with the option '--depot-auto-update' for managing the depot
automatically according to the needs of the executed run script. To enable
this option, use the following line in the build configuration:
! RUN_OPT += --depot-auto-update
If enabled, the run tool automatically invokes the right depot-management
commands to populate the depot with the required archives, and to ensure the
consistency of the depot content with the current version of the source tree.
The feature comes at the price of a delay when executing the run script
because the consistency check involves the extraction of all used source
archives from the source tree. In regular run scripts, this delay is barely
noticeable. Only when working with a run script of a large system, it may be
better to leave the depot auto update disabled.
Please note that the use of the automated depot update may result in version
updates of the corresponding depot recipes in the source tree (recipe hash
files). It is a good practice to review and commit those hash files once the
local changes in the source tree have reached a good shape.

681
doc/release_notes-19-08.txt
View File

@ -1,681 +0,0 @@
===============================================
Release notes for the Genode OS Framework 19.08
===============================================
Genode Labs
The stated theme of this year's [https://genode.org/about/road-map - road map]
is "bridging worlds", which expresses our ambition to smoothen the practical
use of Genode-based systems such as Sculpt OS. The current release pays
tribute to this ambition by addressing a great number of practical concerns:
How to accommodate the staggering variety of keyboard layouts out there?
(Section [Flexible keyboard layouts])
How can the system gracefully respond when confronted with exotic USB devices?
(Section [Storage-stack improvements])
How to set the system time from within the system? How does SNTP fit in here?
(Section [General system time concept])
How to approach the remote administration of the system?
(Section [Enhanced SSH terminal])
How to copy and paste text securely between mutually distrusting subsystems?
(Section [Clipboard])
Or how to overcome the captive portal of a Hotel WiFi with Sculpt OS?
(Section [Disposable VM for handling captive portals])
By providing answers to those questions, we believe to make Genode - and Sculpt
OS in particular - generally more useful.
As another take on "bridging worlds", we continue our effort to bring the rich
Sculpt OS software stack to the 64-bit ARM world, in particular to our most
loved SoC family, namely NXP i.MX. Section [64-bit ARM and NXP i.MX8] reports
on our progress in this direction.
Under the hood, there are a few exciting developments that will greatly reduce
the effort of running existing software on Genode. In particular, Genode's
(entirely optional) C runtime has gained the ability to emulate the
traditional execve and fork mechanisms.
(Section [Consolidation of the C runtime and Noux]) This will eventually
alleviate the need for our present noux runtime environment to the benefits of
better performance and increased flexibility.
Further highlights of Genode 19.08 are a major update of Qt5 to version 5.13
(Section [Updated Qt5]) and the continuation of our kernel-agnostic
virtualization story (Section [Virtualization]).
Flexible keyboard layouts
#########################
Genode is used worldwide in a multilingual context beyond Germany and common
technical realms of English. Therefore, we had to address localized
keyboard-input handling for quite some time now and introduced the
_input-filter_ component in
[https://genode.org/documentation/release-notes/17.02#Input-event_filter - 17.02].
The component merges input streams and applies several forms of input
transformations, in particular the application of keyboard layouts to
supplement the input-event stream with character events.
But as we are by no means localization experts, our solution, while performing
a solid job for selected layouts, also had some quirks and rough edges when it
came to French or even Swiss German. First, our oversimplified notion of
[https://en.wikipedia.org/wiki/Caps_Lock - Caps Lock] as _just a pressed Shift_
_key_ is plain wrong but part of all our character-generator configurations.
We just missed this drawback because none of our developers uses Caps Lock
regularly. Further, US English and Germany layouts work very well without
[https://en.wikipedia.org/wiki/Dead_key - dead keys], but crossing any German
border (except the Austrian) is impossible without support for key sequences
composing special characters. The French keyboard layout in Genode tried to
alleviate the lack of compose sequences by adding an additional Circumflex
modifier and character mapping, which unfortunately is not standard.
[image keyboard_stack]
Beginning at this state of affairs, we researched common practice in
international keyboard-input handling, sought a quasi-standard source for
layout configurations, and addressed the drawbacks mentioned before. During
our research we found out that no current implementation is void of critique
and, therefore, decided to look more into X11/XKB as our open-source
quasi-standard solution, but always had an eye on the proprietary world.
The handling of key events in X11/XKB happens on three layers.
:Key codes: On the key-code layer, the device driver programs the
keyboard and generates a stream of key-code (i.e., scan-code)
events, which represent the physical location of the actual key on
the keyboard.
:Key symbols: These key codes are mapped to key symbols, which
represent the label imprinted on the key. So, the key code producing
US English _Q_ (QWERTY keyboard) generates _A_ on a French keyboard
(AZERTY). Modifiers like Shift, AltGr, and Caps Lock are included in
the key-symbol mapping. Additionally, some layouts map key codes to
dead key symbols, which start the before-mentioned compose
sequences. Key repeat is also implemented as key-symbol repeat
actually.
:Characters: On top of this stack, the key symbols are mapped to
characters represented as Unicode codepoints or UTF-8 strings.
The procedure obviously includes key symbols that have no character
representation (e.g. Control and Alt). Key symbols forming a valid compose
sequence generate characters on this level (e.g., dead-key circumflex plus
e generates ê).
We limited our research to Western keyboard-input handling and only had a
blink into the direction of Chinese-Japanese-Korean (CJK) and advanced input
methods (IM). This simplification is supported by the fact that CJK can also
be based on the mechanisms mentioned with some limitations only. Nevertheless,
we do not expect to never touch this topic again.
After doing our homework of keyboard-input handling, we worked on squeezing
all available layout information out of X11/XKB, which resulted in a small
tool residing in _tool/xkb2ifcfg_. For those wondering, the name is just a
silly acronym for _XKB to input-filter_ _configuration_ that pays tribute to
the boringness of this task. After building the tool by a run of 'make' in the
tool path, it can be used as follows. Please make sure you have libxkbcommon
development packages installed beforehand.
! xkb2ifcfg generate <layout> <variant> <locale>
!
! xkb2ifcfg generate us euro en_US.UTF-8
! xkb2ifcfg generate de nodeadkeys de_DE.UTF-8
If the parameter combination is available, xkb2ifcfg prints a input-filer
chargen configuration for the selected layout to standard output. Valid
'layout' and 'variant' options can be figured out from the LAYOUTS section in
'man 7 xkeyboard-config', where 'variant' strings are depicted in parentheses
after the layout (e.g., 'us(euro)'). The 'locale' option has the standard
locale syntax (see /usr/share/i18n/locales). The tool needs all three
parameters to gather the correct key-map and compose-sequence information. The
generated chargen configurations include '<map>' and '<key>' nodes
corresponding to significant modifier states and '<sequence>' nodes (described
later). For simplicity of the generator, the '<key>' nodes always use the
'code="..."' attribute, but also have a comment with the UTF-8 character
appended.
! <key name="KEY_MINUS" code="0x00df"/> <!-- ß -->
Last, we addressed the improvement of the input-filter character generator and
the actual chargen configuration files in Genode. Therefore, we specified the
modifier configuration assumed by the standard chargen files as '<mod1>'
corresponds to Shift, '<mod2>' to Control, '<mod3>' to AltGr, and '<mod4>' to
Caps Lock.
! <mod1> <key name="KEY_LEFTSHIFT"/> <key name="KEY_RIGHTSHIFT"/> </mod1>
! <mod2> <key name="KEY_LEFTCTRL"/> <key name="KEY_RIGHTCTRL"/> </mod2>
! <mod3> <key name="KEY_RIGHTALT"/> </mod3> <!-- AltGr -->
! <mod4> <rom name="capslock"/> </mod4>
As outlined above, the '<key>' nodes generated by xkb2ifcfg always use the
'code' attribute for the Unicode codepoint. Because of this and because UTF-8
also refers to codepoints, we deprecated the 'b0/b1/b2/b3' attributes for
character definition with this release.
The chargen is also extended by the '<sequence>' configuration node. A
sequence node permits the definition of dead-key/composing character
sequences. With such sequences, the character is not generated instantly on
key press but only after the sequence is completed. If an unfinished sequence
can't be completed due to an unmatched character, the sequence is aborted and
no character is generated. We support sequences of up to four characters at
the moment.
For example, the French AZERTY
[https://docs.microsoft.com/en-us/globalization/keyboards/kbdfr.html - keyboard layout]
has a dead key for Circumflex Accent _^_ right of the _P_ key (which is
bracket left _[_ on US keyboards). When Circumflex is pressed no visible
character should be generated instantly but the accent must be combined with a
follow-up character (e.g., Circumflex plus _a_ generates _â_).
Dead keys can be defined in the '<key>' nodes of any '<map>' by using
codepoints not used for direct output, for example, Combining Diacritical
Marks beginning at U+0300. The French Circumflex example can be configured
like follows.
! <mod1>
! <key name="KEY_LEFTSHIFT"/> <key name="KEY_RIGHTSHIFT"/>
! </mod1>
! <map>
! <key name="KEY_Q" code="0x0061"/> <!-- a -->
! <key name="KEY_LEFTBRACE" code="0x0302"/> <!-- dead_circumflex -->
! </map>
! <map mod1="true">
! <key name="KEY_Q" code="0x0041"/> <!-- A -->
! </map>
! <sequence first="0x0302" second="0x0061" code="0x00e2"/> <!-- â -->
! <sequence first="0x0302" second="0x0041" code="0x00c2"/> <!-- Â -->
Fortunately, the configuration is automatically generated by xkb2ifcfg, but
admittedly quite extensive. Therefore, we manually amended the chargen
configurations before adding them to Genode, which also gave us the chance to
apply some adjustments like follows for AltGr in Swiss German.
! <map mod1="false" mod2="false" mod3="true" mod4="false">
! <key name="KEY_1" code="0x00a6"/> <!-- ¦ (*) -->
! <key name="KEY_4" code="0x00b0"/> <!-- ° (*) -->
! <key name="KEY_5" code="0x00a7"/> <!-- § (*) -->
! </map>
Beside the advanced input methods mentioned before, there are still loose ends
we are going to address in the upcoming releases. For example, the current key
handling in our Qt5 back end maps localized key symbols incorrectly (think
AZERTY vs. QWERTY) in combination with shortcuts like Ctrl-A.
64-bit ARM and NXP i.MX8
########################
64-bit ARM support in our custom base-hw kernel
-----------------------------------------------
By introducing rudimentary Raspberry Pi 3 support on top of the Fiasco.OC
kernel in the previous release, the first ARM 64-bit support has entered the
Genode OS framework. We continued pursuing the ARM 64-bit path and introduce
support for Raspberry Pi 3 as well as the i.MX8 evaluation kit (EVK), this
time using our own base-hw kernel.
Noteworthy additions in the base-hw kernel are support for the AARCH64 system
level architecture, and the use of the modern GIC v3 interrupt controller on
top of the i.MX8 EVK board. In comparison to the GICv2, GICv3 adds support for
more than eight CPUs, more than 1020 interrupt IDs, and offers fast register
access to the CPU interface, instead of memory-mapped I/O access. Minor
changes had to be made to the page-table implementation of ARMv7 with Large
Physical Address Extension (LPAE) to re-use it for ARMv8. Moreover, the
internal kernel API for TLB maintenance needed to be changed slightly for all
ARM platforms.
We expanded our regular testing infrastructure with two AARCH64 platforms,
namely Raspberry Pi 3 via Qemu and the NXP i.MX8 EVK board as physical
hardware. Both platforms are driven with a single CPU core only at the moment.
Network driver for i.MX7 and i.MX8
----------------------------------
We updated the 'fec' network driver to version 4.16.3, which adds support for
i.MX7 and i.MX8 SoCs. This makes i.MX8 a viable platform for Genode-based
networking scenarios.
Enhanced packaging and test infrastructure for ARMv8
----------------------------------------------------
Besides the improved base-hw kernel, we enabled additional infrastructure for
ARMv8 platforms. For example, noux packages - like _coreutils_, _bash_ - are
now available, the standard C++ library is in place, and support for Genode's
port of the Linux TCP/IP stack is enabled.
Additionally, ARMv8 is now regularly tested within our nightly
_depot_autopilot_ runs.
Base framework and OS-level infrastructure
##########################################
Tracing
=======
Support for fast tracing has been built into Genode for a long time. However,
the stakes to take advantage of this feature remained high because convenience
functions were not in place. With the current release, we added the support
for easy trace setups through a VFS plugin. The plugin is called _vfs_trace_
and can be mounted into a Genode component as follows:
!<config>
! <vfs>
! <trace ram=32MB/>
! </vfs>
!</config>
This configuration will create a trace file system at the root of the VFS. The
_ram_ attribute is mandatory and determines the maximum size of all trace
buffers. The file system forms a recursive directory structure that represents
the parent/child relationship of running components, whereas the leaf
directories represent single threads within a component. Each leaf directory
currently contains three files:
:'enable': Start or stop the tracing of a thread by writing "true" or "false"
into the file.
:'buffer_size': Allows for the configuration of the trace-buffer size for the
thread in the usual Genode format (e.g. 5M, 512K, 1024).
:'trace_buffer': This read-only file contains the current content of the trace
buffer. Each trace entry can only be read once, after that only new entries
appear. "tail -f" can also be used to display continuous output.
As an example, tracing is started by writing _true_ to the _enable_ file:
! echo "true" > enable
The trace buffer can then be displayed using Unix tools like _tail_
! tail -f trace_buffer
which provides a continuous output.
Additionally, we have added the _trace_ function to _base/log.h_ that
facilitates identical functionality as _Genode::log_
! Genode::trace("Tracepoint value: ", value);
In order to enable tracing, the parent must provide the "TRACE" service. For a
real world example on Sculpt OS, please refer to this
[https://genodians.org/ssumpf/2019-06-18-trace_fs - Genodians article].
With the _vfs_trace_ plugin in place, we removed the outdated _trace_fs_.
Consolidation of the C runtime and Noux
=======================================
On our [https://genode.org/about/road-map#August_-_Release_19.08 - road map],
we vaguely hinted at our plan for the "consolidation" of the noux runtime,
which is actually meant as a polite way of announcing that we are going to
remove it. We introduced the
[https://genode.org/documentation/release-notes/11.02#Noux_-_an_execution_environment_for_the_GNU_userland - Noux runtime]
in 2011 as a way to execute command-line-based GNU software directly on
Genode. It has served us well over the years and is - in fact - a crucial
ingredient of Sculpt OS and other system scenarios such as the Genodians.org
web server. Noux supplements Genode with two valuable assets, namely a
flexible and expandable virtual file system (VFS) layer, and the
implementation of the
[https://genode.org/documentation/release-notes/12.02#Noux_support_for_fork_semantics - Unix way]
to spawn applications ('fork' and 'execve').
In the
[https://genode.org/documentation/release-notes/17.02#Enhanced_VFS_infrastructure - meantime],
noux' VFS implementation has become independent from the noux runtime and is
now prominently employed by Genode's C runtime and the VFS server component.
Genode's C runtime became more and more complete, alleviating the use of noux
as POSIX compatibility layer except for programs that depended on a working
implementation of 'fork' and 'execve'.
The current release fills this remaining gap in Genode's C runtime by
providing 'fork', 'execve', and cousins such as 'wait4' and 'getpid' as
regular parts of the libc. This will eventually make noux redundant.
Note that this change does *NOT* make Genode reliant on POSIX. The C runtime
including the Unix features are entirely optional.
As one stepping stone of this undertaking, noux applications, which previously
had to be compiled for noux, have become binary compatible with the regular C
runtime. So one can execute programs like 'bash' directly as a Genode
component without any friction.
There are a few collateral improvements of Genode's dynamic linker and the C
runtime on the account of the new 'fork' and 'execve' implementation. E.g., in
addition to the already supported 'stdin', 'stdout', and 'stderr'
configuration, the libc can be instructed to initialize arbitrary file
descriptors as follows:
! <config>
! ...
! <libc ...>
! <fd id="3" path="/dev/log" writeable="yes" readable="no" seek="10"/>
! ...
! </libc>
! </config>
The libc-based implementation of 'fork' and 'execve' can be tried out via
the new _ports/run/bash.run_ script. Note that there are still a number of
limitations such as the lack of signal and ioctl handling. Pipes are not
supported, and shebangs ('#!') are not interpreted yet. That said, once those
missing pieces come into place, we can fade out the use of noux within Genode.
General system time concept
===========================
Briefly speaking, up to now there has been no notion of an overall concept of
system time in Genode. Components that need to have access to some kind of
real time are either configured locally, e.g., libc-based components access a
configured "device" (/dev/rtc), which just might be an inline file system
containing an artificial timestamp or the VFS RTC plugin, while other
components query some RTC session directly. Most of the time, this session is
provided by the 'rtc_drv' on x86 machines, which is somewhat costly as reading
the RTC via I/O ports takes time and is therefore done scarcely. For example,
the libc will query an RTC source only once and uses this initial value to
interpolate the current time. However, for executing long-running components,
it will be necessary to adjust the clock to compensate for any occurring clock
drift or to correct a misconfigured clock in general. In addition it is
desirable to be able to use a remote time source, e.g., an NTP-server, to
synchronize the system time.
To address this, we came up with the following concept:
[image system_rtc]
The new "System RTC" component, located at
_repos/libports/src/server/system_rtc_, acts as proxy for the RTC service in
front of the actual RTC driver. It uses the driver to get the initial RTC
value and then uses a timer session (via the timeout framework) to locally
interpolate the time. In contrast to querying the RTC driver, querying the
System RTC is fast.
The RTC driver and the System RTC are bundled up together in the new
_drivers-rtc-pc_ package. The runtime of this package requests two ROM modules
used to update the RTC value. The first one, named 'system_set_rtc', is used
to update the proxy component while the second one, called 'hw_set_rtc', is
used by the RTC driver to write the value into the battery-backed RTC. A
separate component, potentially accessing a remote time source, may generate
these ROMs to adjust the time in the package's runtime.
The new native *SNTP* client at _repos/libports/src/app/sntp_client_ is such a
component. It periodically requests the current time from a given SNTP server
and generates a report. The report produced by the component contains the time
as UTC/GMT. Depending on the system policy, it can be used to update the time
of the System RTC and/or instruct the driver to set the RTC value.
To propagate such changes to RTC values, the RTC session was enhanced by the
new 'set' signal. A client of the session can install a signal handler to
adapt its own time when necessary. Based on this, the time back end of the
libc was changed to instantiate a watch handler for the RTC device, which,
when triggered, will cause the libc to re-read the RTC value.
This constellation should, under normal operation, allow for second to
sub-second granularity updates of the overall system time and avoid drifting
away from network time.
Accessing SMBIOS tables
=======================
The System Management BIOS (SMBIOS) is a specification that allows for reading
management information produced by the BIOS of a system as a collection of
data structures in memory. It has the potential to eliminate the need for the
operating system to probe hardware for discovering present devices and their
characteristics. Nowadays, the SMBIOS specification is implemented widely in
PC systems, which includes modern UEFI systems as well. The data structures
are referred to as _tables_ or _records_ by public documentation.
The new native SMBIOS decoder at _os/src/app/smbios_decoder_ can be used on
x86 to parse SMBIOS tables and report gathered information in a human-readable
way. Besides general table information like number and size of structures,
etc., the component supports complete parsing of SMBIOS structures of types
"BIOS", "System", and "Baseboard".
The component is free from any code for acquiring an SMBIOS table through
means like the bootloader or BIOS information. It expects a table to be
present through a regular Genode ROM session with a 'smbios_table' label. This
way, the underlying system is required to find, select, and save the raw table
on startup and create a ROM module out of it. This is currently achieved on
NOVA and base-hw through an interplay of kernel, the core component, and the
ACPI driver and was tested for legacy BIOSes as well as UEFI systems.
Clipboard
=========
Genode introduced a principle copy-and-paste mechanism already
[https://genode.org/documentation/release-notes/15.11#Copy_and_paste - four years ago].
However, originally created as a part of a tech demo, the mechanism remained
unused in our day to day Genode work. This changed now. We took the
integration of copy-and-paste support in Sculpt OS as an opportunity to revive
and refine the existing mechanism and supplement it with the features needed
to make it practical for daily use. We believe that the result aligns ease of
use nicely with security. The concept is described in a
[https://genodians.org/nfeske/2019-07-03-copy-paste - dedicated article]
at Genodians.org.
On a technical level, the existing clipboard component has received a new
option that allows for dynamic information-flow policies based on user
interactivity (keyboard focus, activity). When setting the config attribute
'match_labels="yes"', the clipboard performs plausibility checks for copy and
paste operations against the focus of the Nitpicker GUI server. All aspects of
the clipboard policy - including information-flow policies - have become
reconfigurable.
To make window-manager clients compatible with the clipboard's dynamic policy,
the window manager got enhanced with the ability to proxy the interaction with
the clipboard. GUI clients in turn - in particular the graphical *terminal* -
became able to interact with the clipboard. With the '<config>' attribute
'copy="yes"' specified, the terminal allows the user to select text to be
reported to a "clipboard" report. The selection mode is activated by holding
the left shift key. While the selection mode is active, the text position
under the mouse pointer is highlighted and the user can select text via the
left mouse button. Upon release of the mouse button, the selection is
reported. Vice versa, with the '<config>' attribute 'paste="yes"' specified,
the terminal allows the user to paste the content of a "clipboard" ROM session
to the terminal client by pressing the middle mouse button.
Finally, we integrated those new abilities into Sculpt OS and into several
installable packages, including virtual machines, the noux-system package,
and graphical Qt5-based applications.
Enhanced SSH terminal
=====================
This release paves the way for remotely managing Genode devices over SSH.
Until now, only interactive SSH sessions were supported. It is now possible to
execute commands from a remote SSH client. E.g., 'ssh noux@localhost -p 5555
"ls -hal /bin/"'. For non-interactive sessions, ssh_terminal requires a helper
component. This component is responsible to create the environment for the
command to run in. You can find an example for such a component at
_gems/src/test/exec_terminal_. It starts noux in a sub init and executes the
provided command inside of it. The new _ssh_exec_channel.run_ script gives a
demonstration on how this feature can be used.
This work is a contribution by Sid Hussmann of
[https://gapfruit.com - Gapfruit]. Thanks for this great new feature!
Storage-stack improvements
==========================
The desire of one Genode developer to exchange data via Iomega ZIP drives
between an Atari Falcon and Sculpt OS called for a number of small
improvements across several components of the storage stack.
First, the USB-block driver has been changed to exit on an initialization
failure instead of waiting for another (supported) device. This change enables
the Sculpt manager to detect such conditions and release the USB device
hardware by removing the driver component. Such a failed initialization may
happen with exotic USB-storage devices such as ZIP drives. With the device
released, however, it can be assigned to a virtual machine to access it using
a guest OS with a broader support of devices.
Second, the USB-block driver received new support for issuing the SCSI
START-STOP command at initialization time, thereby overcoming the ZIP-drive
initialization failure.
Third, we enhanced the part-block component with the ability to parse AHDI
partition schemes and detect the GEMDOS variant of FAT as used by Atari TOS.
Fourth, we enabled the Rump VFS plugin to access GEMDOS file systems. The
GEMDOS variant is readily supported by NetBSD's "msdos" file-system driver.
However, it must explicitly be enabled by a mount flag. Hence, we added the
principle ability for passing mount flags to NetBSD file-system drivers and
enabled the MSDOSFSMNT_GEMDOSFS flag based on the VFS plugin's config
attribute 'gemdos="yes"'.
With these changes in place, data can now be exchanged directly between
Atari-formatted disks and Sculpt OS. That said, advanced use cases such as
media changes at runtime are not covered yet.
Updated Ada/SPARK runtime
=========================
Genode's Ada/SPARK runtime is developed and maintained by
[https://componolit.com - Componolit]. Thanks for this excellent
collaboration!
The updated Componolit Ada runtime 1.1.0 increases the proof coverage and
cleans up the source-code structure. SPARK mode is now enabled wherever
possible and unneeded abstractions have been removed. Furthermore, the 64-bit
addition and subtraction have been proven to be free of runtime errors.
As a new feature, the runtime now supports the use of inline assembly in Ada.
The removal of unneeded features such as the incomplete threading support for
the secondary stack has greatly reduced the runtime's complexity while keeping
the current functionality available. Also GNAT.IO has been removed as its
implementation was incomplete and complex. A simpler replacement has been
introduced with 'Componolit.Runtime.Debug'.
Unrelated to Genode, the runtime now supports [https://muen.sk/ - Muen] and
the API/ABI of the runtime has been separated from the GNAT ABI.
Libraries and applications
##########################
Updated Qt5
===========
We updated our Qt5 port to the latest upstream version 5.13.0. Before
preparing the 'qt5' port, please make sure to build and install the updated
Qt5 host tools with the 'tool/tool_chain_qt5' script.
Virtualization
==============
As follow-up of our work on the
[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - kernel agnostic virtual-machine monitor interface]
on x86, we added principle support to run our port of VirtualBox on
Genode/Fiasco.OC. We write _principle_ support, since we managed to get the
VMM running with Fiasco.OC, but unfortunately not all features required by the
VMM are available using the Fiasco.OC kernel, e.g., guest FPU registers, PDPTE
registers, and task-priority support. In practice this means that the VMs with
Windows and Linux come up to a certain point but will fail later whenever the
guest state runs out of synchronization between VMM and hardware. In contrast,
the Seoul VMM runs fine on Fiasco.OC since it does not depend on the mentioned
missing features.
Our main working items have been the completion of transfer of the available
guest registers and control flow synchronization improvements between VMM and
Fiasco.OC kernel. Additionally, the usage of priorities for VirtualBox's
pthreads in the VMM had to be disabled. Finally, some tests for VirtualBox
with Genode/Fiasco.OC are enabled for nightly regular testing now.
As a side topic, we added support for using the VirtualBox
[https://forums.virtualbox.org/viewtopic.php?f=2&t=82299&start=15 - CPU profile]
feature, which allows for presenting a different CPUID to the VM than the one
of the real CPU. This can help when running Windows 7 on a Kaby Lake or newer
CPU, which are considered _unsupported hardware_ and reason enough not to
receive security updates from Microsoft. The feature can be used on Genode by
adding the 'CpuProfile' attribute to the '<CPU>' XML node in the .vbox file,
like:
! <CPU CpuProfile="Intel Core i7-5600U">
Disposable VM for handling captive portals
==========================================
It is common that WiFi networks require the user to interact with a specific
web page before gaining access to full network functionality. Such captive
portal pages are completely individual to the accessed network and not limited
in the use of common web techniques. Therefore, their handling is best be done
using a fully-featured web browser like Mozilla Firefox.
This is where, in a Genode-based desktop system like Sculpt, a disposable VM
for hosting a minimal browser setup becomes desirable. Its goal is to unlock a
network for the native Genode surroundings with as little inconvenience as
possible just to be thrown away afterwards without any side effects on the
system.
Now, one could use the Firefox appliance VM of Sculpt (see the
[https://genode.org/documentation/release-notes/18.05 - release notes] or the
[http://genodians.org/alex-ab/2019-03-06-disposal-browser-vm - Genodians article])
for this. But this VM aims for a long-term browsing experience which, in the
context of mere captive-portal handling, brings some drawbacks like a much
higher RAM consumption or the required sessions for USB detection and shared
folders.
Furthermore, in the captive portal VM, there's no need for managing windows or
browser tabs. The one browser tab needed can always be shown in fullscreen. It
is also unnecessary for the browser to maintain a content cache or remember
user data. This can reduce resource consumption.
[image captive_portal_vm]
The VM we came up with is provided as package for Sculpt by Martin Stein
(depot user 'mstein'). You'll possibly need to manually add Martin's
[https://github.com/genodelabs/genode/tree/master/depot/mstein - depot key and download location]
to your Sculpt depot directory. After enabling this user, the captive portal
VM can be found in the Sculpt menu under "Depot -> mstein -> Virtual
Machines -> vbox5-nova-captive-portal".
The VM is based on a TinyCore 10 Linux with Xserver, i3 WM, and a tailored
Firefox browser. The package runtime doesn't need access to your file system,
it merely loads some ROMs into a RAM FS, so, it will completely forget any
changes made during a session. Therefore, it's also safe to simply remove an
instance via the Leitzentrale component-view once you don't need it anymore.
The guest additions are also included to make the VM window resizable.
Build system and tools
######################
At Genode Labs, we have used _tool/autopilot_ for the steering of tests in our
Continuous Integration workflow for almost a decade now. This implied various
improvements over the years and with the completion of our work on
[https://genode.org/documentation/release-notes/19.05#Unified_build_directories_for_ARM - unified build directories]
it was time to amend this handy tool once again. Unified build directories
support building all components for one CPU architecture in one directory
saving the build server from the redundant work we previously had with
board-specific directories. With the new notion of boards during builds, the
definition of the target platform when integrating Genode system scenarios is
now a triplet of _CPU architecture_, _board_, and _kernel_. This is reflected
in the new '-t <architecture-board-kernel>' command line option, which
instructs autopilot to generate a build directory for _architecture_ and
execute tests for the _board-kernel_ combination.
! autopilot -t x86_64-pc-sel4 -t x86_64-pc-nova -r run/log
The known options for '-k kernel' and '-p platform' are still supported with
the small change that the platform must now be defined as
_architecture-board_.
! autopilot -p x86_64-pc -k sel4 -k nova -r run/log
Autopilot now also documents the hidden feature to propagate custom 'RUN_OPTs'
via the 'RUN_OPT_AUTOPILOT' environment variable to the run tool executed.
Besides that, the tool always appends 'RUN_OPT' with '--autopilot'.
! RUN_OPT_AUTOPILOT="--depot-dir /data/depot" autopilot ...

815
doc/release_notes-19-11.txt
View File

@ -1,815 +0,0 @@
===============================================
Release notes for the Genode OS Framework 19.11
===============================================
Genode Labs
On our [https://genode.org/about/road-map - road map] for this year, we stated
"bridging worlds" as our guiding theme of 2019. The current release pays
tribute to this ambition on several accounts.
First, acknowledging the role of POSIX in the real world outside the heavens
of Genode, the release vastly improves our (optional) C runtime with respect
to the emulation of POSIX signals, execve, and ioctl calls. With the line of
work described in Section [C runtime with improved POSIX compatibility], we
hope to greatly reduce the friction when porting and hosting existing
application software directly on Genode.
Second, we identified the process of porting or developing application
software worth improving. Our existing tools were primarily geared to
operating-system development, not application development. Application
developers demand different work flows and tools, including the freedom to use
a build system of their choice.
Section [New tooling for bridging existing build systems with Genode]
introduces our new take on this productivity issue.
Third, in cases where the porting of software to Genode is considered
infeasible, virtualization comes to the rescue. With the current release, a
new virtual machine monitor for the 64-bit ARM architecture enters the
framework. It is presented in Section [Virtualization of 64-bit ARM platforms].
As another goal for 2019, we envisioned a solution for block-level device
encryption, which is a highly anticipated feature among Genode users. We are
proud to present the preliminary result of our year-long development in
Section [Preliminary block-device encrypter].
Preliminary block-device encrypter
##################################
Over the past year, we worked on implementing a block-device encryption
component that makes use of the
[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
programming language for its core logic. In contrast to common
block-device encryption techniques where normally is little done besides
the encryption of the on-disk blocks, the _consistent block encrypter (CBE)_
aims for more. It combines multiple techniques to ensure integrity -
the detection of unauthorized modifications of the block-device -
and robustness against data loss. Robustness is achieved by keeping snapshots
of old states of the device that remain unaffected by the further operation of
the device. A copy-on-write mechanism (only the differential changes to the
last snapshot are stored) is employed to maintain this snapshot history with
low overhead. To be able to access all states of the device in the same manner,
some kind of translation from virtual blocks to blocks on the device is needed.
Hash-trees, where each node contains the hash of its sub-nodes, combine the
aspect of translating blocks and ensuring their integrity in an elegant way.
During the tree traversal, the computed hash of each node can be easily checked
against the hash stored in the parent node.
The CBE does not perform any cryptography by itself but delegates
cryptographic operations to another entity. It neither knows nor cares about
the used algorithm. Of all the nodes in the virtual block device (VBD), only
the leaf nodes, which contain the data, are encrypted. All other nodes, which
only contain meta-data, are stored unencrypted.
Design
------
As depicted in Figure [cbe_trees], all information describing the various
parts of the CBE is stored in the superblock. The referenced VBD is a set of
several hash trees, each representing a certain device state including the
current working state. Only the tree of the current working state is used to
write data to the block device. All other trees represent snapshots of older
states and are immutable. Each stored device state has a generation number
that provides the chronological order of the states.
As you can see, in the depicted situation, there exist four device states - the
snapshot with generation 3 is the oldest, followed by two newer snapshots and
generation 6 that marks the working state of the virtual device. The tree with
generation 6 is the current working tree. Each tree contains all changes done
to the VBD since the previous generation (for generation 6 the red nodes). All
parts of a tree that didn't change since the previous generation are references
into older trees (for generation 6 the gray nodes). Note that in the picture,
nodes that are not relevant for generation 6 are omitted to keep it manageable.
The actual data blocks of the virtual device are the leaf nodes of the trees,
shown as squares.
[image cbe_trees]
Whenever a block request from the client would override data blocks in
generation 6 that are still referenced from an older generation, new blocks for
storing the changes are needed. Here is where the so-called _Free Tree_ enters
the picture. This tree contains and manages the spare blocks. Spare blocks are
a certain amount of blocks that the CBE has in addition to the number of blocks
needed for initializing the virtual device. So, after having initialized a
virtual device, they remain unused and are only referenced by the Free Tree.
Therefore, in case the VBD needs new blocks, it consults the Free Tree (red
arrow).
In the depicted situation, writing the first data block (red square) would
require allocating 4 new blocks as all nodes in the branch leading to the
corresponding leaf node - including the leaf node itself - have to be written.
In contrast, writing the second data block would require allocating only one
new block as the inner nodes (red circles) now already exist. Subsequent write
requests affecting only the new blocks will not trigger further block
allocations because they still belong to the current generation and will be
changed in-place. To make them immutable we have to create a new snapshot.
The blocks in generation 5 that were replaced by the change to generation 6
(blue nodes) are not needed for the working state of the virtual device
anymore. They are therefore, in exchange for the allocated blocks, added to
the Free Tree. But don't be fooled by the name, they are not free for
allocation yet, but marked as "reserved" only. This means, they are
potentially still part of a snapshot (as is the case in our example) but the
Free Tree shall keep checking, because once all snapshots that referenced the
blue blocks have disappeared, they become free blocks and can be allocated
again.
To create a new snapshot, we first have to make all changes done to the VBDs
working state as well as the Free Tree persistent by writing all corresponding
blocks to the block-device. After that, the new superblock state is written to
the block-device. To safeguard this operation, the CBE always maintains several
older states of the superblock on the block device. In case writing the new
state of the superblock fails, the CBE could fall back to the last state that,
in our example, would contain only generations 3, 4, and 5. Finally, the
current generation of the superblock in RAM is incremented by one (in the
example to generation 7). Thereby, generation 6 becomes immutable.
A question that remains is when to create snapshots. Triggering a snapshot
according to some heuristics inside the CBE might result in unnecessary
overhead. For instance, the inner nodes of the tree change frequently during a
sequential operation. We might not want them to be re-allocated all the time.
Therefore, the creation of a snapshot must be triggered explicitly from the
outside world. This way, we can accommodate different strategies, for
instance, client-triggered, time-based, or based on the amount of data
written.
When creating a snapshot, it can be specified whether it shall be disposable
or persistent. A disposable snapshot will be removed automatically by the CBE
in two situations, either
* When there are not enough usable nodes in the Free Tree left to
satisfy a write request, or
* When creating a new snapshot and all slots in the superblock that might
reference snapshots are already occupied.
A persistent snapshot, or quarantine snapshot, on the other hand will never be
removed automatically. Its removal must be requested explicitly.
During initialization, the CBE selects the most recent superblock and reads the
last generation value from it. The current generation (or working state
generation) is then set to the value incremented by one. Since all old blocks,
that are still referenced by a snapshot, are never changed again, overall
consistency is guaranteed for every generation whose superblock was stored
safely on disk.
Implementation
--------------
Although we aimed for a SPARK implementation of the CBE, we saw several
obstacles with developing it in SPARK right from the beginning. These obstacles
mainly came from the fact that none of us was experienced in designing
complex software in SPARK. So we started by conducting a rapid design-space
exploration using our mother tongue (C++) while using only language features
that can be mapped 1:1 to SPARK concepts. Additionally, we applied a clear
design methodology that allowed us to keep implementation-to-test cycles
small and perform a seamless and gradual translation into SPARK:
* _Control flow_
The core logic of the CBE is a big state machine that doesn't block. On each
external event, the state machine gets poked to update itself accordingly.
C++ can call SPARK but SPARK never calls C++. The SPARK code therefore
evolves as self-contained library.
* _Modularity_
The complex state machine of the CBE as a whole is split-up into smaller
manageable sub-state-machines, working independently from each other. These
modules don't call each other directly. Instead, an additional superior
module handles the interplay. This is done by constantly iterating over all
modules with the following procedure until no further progress can be made:
# Try to enter requests of other modules into the current one
# Poke the state machine of the current module
# The current module may have generated requests - Try to enter them into
the targeted modules
# The current module may have finished requests - Acknowledge them at the
modules they came from
Each module is represented through a class (C++) respectively a package with
a private state record (SPARK).
* _No global state_
There are no static (C++) or package (SPARK) variables. All state is kept in
members of objects (C++) respectively records (SPARK). All packages are pure
and sub-programs have no side-effects. Therefore, memory management and
communication with other components is left to OS glue-code outside the
core logic.
This approach worked out well. Module by module, we were able to translate the
C++ prototype to SPARK without long untested phases, rendering all regression
bugs manageable. In Genode, the CBE library is currently integrated through
the CBE-VFS plugin. Figure [cbe_modules] depicts its current structure and the
integration via VFS plugin.
[image cbe_modules]
The green and blue boxes each represent an Ada/SPARK package. The translation
to SPARK started at the bottom of the picture moving up to the more abstract
levels until it reached the Library module. This is the module that handles
the interplay of all other modules. Its interface is the front end of the CBE
library. So, all green packages are now completely written in SPARK and
together form the CBE library. Positioned above, the CXX library in blue is
brought in by a separate library and exports the CBE interface to C++. This
way, the CBE can also be used in other environments including pure SPARK
programs. The CXX Library package is not written in SPARK but Ada and performs
all the conversions and checks required to meet the preconditions set by the
SPARK packages below.
At the C++ side, we have the VFS plugin. Even at this level, the already
mentioned procedure applies: The plugin continuously tries to enter requests
coming from the VFS client (above) into the CBE (below), pokes the CBE state
machine, and puts thereby generated block/crypto requests of the CBE into the
corresponding back-ends (left). This process is repeated until there is no
further progress without waiting for an external event.
Current state
-------------
In its current state, the CBE library is still pretty much in flux and is not
meant for productive use.
As the Free Tree does not employ copy-on-write semantics for its meta-data, a
crash, software- or hardware-wise, will corrupt the tree structure and renders
the CBE unusable on the next start.
This issue is subject to ongoing work. That being said, there are
components that, besides being used for testing, show how the interface of the
CBE library lends itself to be integrated in components in different ways. At
the moment, there are two components making use of the CBE library as
block-device provider.
The first one is the aforementioned CBE-VFS plugin. Besides r/w access to the
working tree and r/o access to all persistent snapshots, it also provides a
management interface where persistent snapshots can be created or discarded.
Its current layout is illustrated by Figure [cbe_vfs]. The VFS plugin
generates three top directories in its root directory. The first one is the
_control_ directory. It contains several pseudo files for managing the CBE:
[image cbe_vfs]
:'key': set a key by writing a string into the file.
:'create_snapshot': writing 'true' to this file will attempt to create
a new snapshot. (Eventually the snapshot will
appear in the 'snapshots' directory if it could be
created successfully.)
:'discard_snapshot': writing a snapshot ID into this file will discard
the snapshot
The second is the 'current' directory. It gives access to the current
working tree of the CBE and contains the following file:
:'data': this file represents the virtual block device and gives
read and write access to the data stored by the CBE.
The third and last is the 'snapshots' directory. For each persistent snapshot,
there is a sub-directory named after the ID of the snapshot. This directory,
like the 'current' directory, contains a 'data' file. This file, however,
gives only read access to the data belonging to the snapshot.
The CBE-VFS plugin itself uses the VFS to access the underlying block device.
It utilizes the file specified in its configuration. Here is a '<vfs>'
snippet that shows a configured CBE-VFS plugin where the block device is
provided by the block VFS plugin.
! <vfs>
! <dir name="dev">
! <block name="block"/>
! <cbe name="cbe" block="/dev/block"/>
! </dir>
! </vfs>
An exemplary ready-to-use run script can be found in the CBE repository
at _run/cbe_vfs_snaps.run_. This run script uses a bash script to
automatically perform a few operations on the CBE using the VFS plugin.
Afterwards it will drop the user into a shell where further operations
can be performed manually, e.g.:
! dd if=/dev/zero of=/dev/cbe/current/data bs=4K
The second component is the CBE server. In contrast to the CBE-VFS plugin,
it is just a simple block-session proxy component that uses a block connection
as back end to access a block-device. It provides a front-end block session to
its client, creates disposable snapshots every few seconds, and uses the
'External_Crypto' library to encrypt the data blocks using AES-CBC-ESSIV. The
used key is a plain passphrase. The following snippet illustrates its
configuration:
! <start name="cbe">
! <resource name="RAM" quantum="4M"/>
! <provides><service name="Block"/></provides>
! <config sync_interval="5" passphrase="All your base are belong to us"/>
! </start>
The _run/cbe.run_ run script in the CBE repository showcases the use of the
CBE server.
Both run scripts will create the initial CBE state in a RAM-backed
block device that is then accessed by the CBE server or the CBE-VFS
plugin.
The run-script and the code itself can be found on the
[https://github.com/cnuke/cbe/tree/cbe_19.11 - cbe/cbe_19.11] branch on
GitHub. If you intend to try it out, you have to checkout
the corresponding
[https://github.com/cnuke/genode/tree/cbe_19.11 - genode/cbe_19.11]
branch in the Genode repository as well.
Future plans
------------
Besides addressing the current shortcomings and getting the CBE library
production-ready so that it can be used in Sculpt, there are still
a few features that are currently unimplemented. For one we would like
to add support for making it possible to resize the VBD as well as the
Free Tree. For now the geometry is fixed at initialization time and cannot
be changed afterwards. Furthermore, we would like to enable re-keying,
i.e., changing the used cryptographic key and re-encrypting the tree
set of the VBD afterwards. In addition to implementing those features, the
overall tooling for the CBE needs to be improved. E.g., there is currently
no proper initialization component. For now, we rely on a component
that was built merely as a test vehicle to generate the initial trees.
Virtualization of 64-bit ARM platforms
######################################
Genode has a long history regarding support of all kinds of
virtualization-related techniques including
[https://genode.org/documentation/release-notes/9.11#Paravirtualized_Linux_on_Genode_OKL4 - para-virtualization],
[https://genode.org/documentation/articles/trustzone - TrustZone],
hardware-assisted virtualization on
[https://genode.org/documentation/articles/arm_virtualization - ARM],
[https://genode.org/documentation/release-notes/13.02#Full_virtualization_on_NOVA_x86 - x86],
up to the full virtualization stack of
[https://genode.org/documentation/release-notes/14.02#VirtualBox_on_top_of_the_NOVA_microhypervisor - VirtualBox].
We regard those techniques as welcome stop-gap solutions for using non-trivial
existing software stacks on top of Genode's clean-slate OS architecture. The
[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - recent]
introduction of a kernel-agnostic interface to control virtual machines (VM)
ushered a new level for the construction respectively porting of
virtual-machine monitors (VMM). By introducing a new ARMv8-compliant VMM
developed from scratch, we continue this line of work.
The new VMM builds upon our existing proof-of-concept (PoC) implementation for
ARMv7 as introduced in release
[https://genode.org/documentation/release-notes/15.02#Virtualization_on_ARM - 15.02].
In contrast to the former PoC implementation, however, it aims to be complete
to a greater extent. Currently, it comprises device models for the following
virtual hardware:
* RAM
* System Bus
* CPU
* Generic Interrupt Controller v2 and v3
* Generic Timer
* PL011 UART (limited)
* Pass-through devices
The VMM is able to load diverse 64-bit Linux kernels including
Device-Tree-Binary (DTB) and Initramfs. Currently, the implementation uses a
fixed memory layout for the guest-physical memory view, which needs to be
reflected by the DTB used by the guest OS. An example device-tree source file
can be found at _repos/os/src/server/vmm/spec/arm_v8/virt.dts_. The actual VMM
is located in the same directory.
Although support for multi-core VMs is already considered internally, it is
not yet finished. Further outstanding features that are already in development
are Virtio device model support for networking and console. As the first - and
by now only - back end, we tied the VMM to the ARMv8 broadened Kernel-agnostic
VM-session interface as implemented by Genode's custom base-hw kernel. As a
side effect of this work, we consolidated the generic VM session interface
slightly. The RPC call to create a new virtual-CPU now returns an identifier
for identification.
The VMM has a strict dependency on ARM's hardware virtualization support
(EL2), which comprises extensions for the ARMv8-A CPU, ARM's generic timer,
and ARM's GIC. This rules out the Raspberry Pi 3 board as a base platform
because it does not include a GIC but a custom interrupt-controller without
hardware-assisted virtualization of interrupts. To give the new VMM a try, we
recommend using the run script _repos/os/run/vmm_arm.run_ as a starting point
for executing the VMM on top of the i.MX8 Evaluation Kit board.
New tooling for bridging existing build systems with Genode
###########################################################
Genode's development tools are powerful and intimidating at the same time.
Being designed from the perspective of a whole-systems developer, they put
emphasis on the modularity of the code base (separating concerns like
different kernels or system abstraction levels), transitive dependency
tracking between libraries, scripting of a wide variety of system-integration
tasks, and the continuous integration of complete Genode-based
operating-system scenarios. Those tools are a two-edged sword though.
On the one hand, the tools are key for the productivity of seasoned Genode
developers once the potential of the tools is fully understood and leveraged.
For example, during the development of Sculpt OS, we are able to
change an arbitrary line of code in any system component and can test-drive
the resulting Sculpt system on real hardware within a couple of seconds.
As another example, the almost seamless switching from one OS kernel to
another has become a daily routine that we just take for granted without
even thinking about it.
On the other hand, the sophistication of the tools stands in the way of
application developers who are focused on a particular component instead
of the holistic Genode system. In this case, the powerful system-integration
features remain unused but the complexity of the tools and the build system
prevails. Speaking of build systems, this topic is ripe of emotions
anyway. _Developers use to hate build systems._ Forcing Genode's build
system down the throats of application developers is probably not the best
idea to make Genode popular.
This line of thoughts prompted us to re-approach the tooling for Genode from
the perspective of an application developer. The intermediate result is a new
tool called Goa:
:Goa project at GitHub:
[https://github.com/nfeske/goa]
Unlike Genode's regular tools, Goa's work flow is project-centered. A project
is a directory that may contain source code, data, instructions how to
download source codes from a 3rd party, descriptions of system scenarios, or
combinations thereof. Goa is independent from Genode's regular build system.
It combines Genode's package management (depot) with commodity build systems
such a CMake. In addition to building and test-driving application software
directly on a Linux-based development system, Goa is able to aid the process
of exporting and packaging the software in the format expected by Genode
systems like Sculpt OS.
At the current stage, Goa should be considered as work in progress. It's a new
approach and its success is anything but proven. That said, if you are
interested in developing or porting application software for Genode, your
feedback would be especially valuable. As a starting point, you may find the
following introductory article helpful:
:Goa - streamlining the development of Genode applications:
[https://genodians.org/nfeske/2019-11-25-goa]
Base framework and OS-level infrastructure
##########################################
File-system session
===================
The file-system session interface received a much anticipated update.
Writing modification times
--------------------------
The new operation WRITE_TIMESTAMP allows a client to update the modification
time of a file-system node. The time is defined by the client to keep
file-system servers free from time-related concerns. The VFS server implements
the operation by forwarding it to the VFS plugin interface. At present, this
new interface is implemented by the rump VFS plugin to store modification
times on EXT2 file systems.
Enhanced file-status info
-------------------------
The status of a file-system node as returned by the 'File_system::Status'
operation has been revisited. First, we replaced the fairly opaque "mode" bits -
which were an ad-hoc attempt to stay compatible with Unix - with the explicit
notion of 'readable', 'writeable', and 'executable' attributes. We completely
dropped the notion of users and groups. Second, we added the distinction
between *continuous* and *transactional* files to allow for the robust
implementation of continuous write operations across component boundaries. A
continuous file can be written-to via a sequence of arbitrarily sized chunks
of data. For such files, a client can split a large write operation into any
number of smaller operations in accordance to the size of the used I/O
buffers. In contrast, a write to a transactional file is regarded as a
distinct operation. The canonical example of a transactional file is a
socket-control pseudo file.
Virtual file-system infrastructure
==================================
First fragments of a front-end API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The VFS is mostly used indirectly via the C runtime. However, it is also
useful for a few components that use the Genode API directly without any
libc. To accommodate such users of the VFS, we introduced the front-end
API at _os/vfs.h_ that covers a variety of current use cases. Currently, those
use cases revolve around the watching, reading, and parsing of files and
file-system structures - as performed by Sculpt's deployment mechanism.
Writing to files is not covered.
Improved file-watching support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All pseudo files that use the VFS-internal 'Readonly_value_file_system'
utility have become able to deliver watch notifications. This change enables
VFS clients to respond to VFS-plugin events (think of terminal resize)
dynamically.
Speaking of the *terminal VFS plugin*, the current release enhances the plugin
in several respects. First, it now delivers status information such as the
terminal size via pseudo files. Second, we equipped the VFS terminal file
system with the ability to detect user interrupts in the incoming data stream,
and propagate this information via the new pseudo file '.terminal/interrupts'.
Each time, the user presses control-c in the terminal, the value stored in
this pseudo file is increased. Thereby, a VFS client can watch this file to
get notified about the occurrences of user interrupts.
VFS plugin for emulating POSIX pipes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We added a new VFS plugin for emulating POSIX pipes. The new plugin creates
pipes between pairs of VFS handles. It replaces the deprecated libc_pipe
plugin. In contrast to the libc_pipe plugin, which was limited to pipes within
one component, the new VFS plugin can also be used to establish pipes between
different components by mounting the plugin at a shared VFS server.
C runtime with improved POSIX compatibility
===========================================
Within Genode, we used to think of POSIX as a legacy that is best avoided.
In fact, the foundational components of the framework do not depend on a
C runtime at all. However, higher up the software stack - at the latest when
3rd-party libraries enter the picture - a working C runtime is unavoidable. In
this statement, the term "working" is rather muddy though. Since we have never
fully embraced POSIX, we were content with cutting corners here and there. For
example, given Genode's architecture, supporting 'fork' and 'execve' seemed
totally out of question because those mechanisms would go against the grain of
Genode.
However, our growing aspiration to bridge the gap between existing popular
applications and Genode made us re-evaluate our stance towards POSIX.
All technical criticism aside, POSIX is immensely useful because it is
a universally accepted stable interface. To dissolve friction between
Genode and popular application software, we have to satisfy the application's
expectations. This ignited a series of developments, in particular
the added support for 'fork' and 'execve' - of all things - in
[https://genode.org/documentation/release-notes/19.08#Consolidation_of_the_C_runtime_and_Noux - Genode 19.08],
which was nothing short of surprising, even to us.
The current release continues this line of development and brings the
following improvements.
Execve
------
The libc's 'execve' implementation got enhanced to evaluate the path of the
executable binary according to the information found on the VFS, in particular
by traversing directories and following symbolic links. This enables the libc
to execute files stored at sub directories of the file system.
Furthermore, 'execve' received handling for *executing shell scripts* by
parsing the shebang marker at the beginning of the executable file. This way,
the 'execve' mechanism of the libc reaches parity with the feature set of the
Noux runtime that we traditionally used to host Unix software on top of
Genode.
Modification-time handling
--------------------------
By default, the libc uses the just added facility for updating the timestamp
of file-system nodes when closing a written-to file, which clears the path
towards using tools like 'make' that rely on file-modifications times.
The libc's mechanism can be explicitly disabled by specifying
! <libc update_mtime="no"...>
This is useful for applications that have no legitimate access to a time
source.
Emulation of 'ioctl' operations via pseudo files
------------------------------------------------
With the current release, we introduce a new scheme of handling ioctl
operations, which maps 'ioctl' calls to pseudo-file accesses, similar to how
the libc already maps socket calls to socket-fs operations.
A device file can be accompanied with a (hidden) directory that is named after
the device file and hosts pseudo files for triggering the various device
operations. For example, for accessing a terminal, the directory structure
looks like this:
! /dev/terminal
! /dev/.terminal/info
! /dev/.terminal/rows
! /dev/.terminal/columns
! /dev/.terminal/interrupts
The 'info' file contains device information in XML format. The type of the XML
node corresponds to the device type. Whenever the libc receives a TIOCGWINSZ
ioctl for _/dev/terminal_, it reads the content of _/dev/.terminal/info_ to
obtain the terminal-size information. In this case, the _info_ file looks as
follows:
! <terminal rows="25" columns="80/>
Following this scheme, VFS plugins can support ioctl operations by providing
an ioctl directory in addition to the actual device file.
Emulation of POSIX signals
--------------------------
Even though there is no notion of POSIX signals at the Genode level, we
can reasonably emulate certain POSIX signals at the libc level. The current
release introduces the first bunch of such emulated signals:
:SIGWINCH: If 'stdout' is connected to a terminal, the libc watches the
terminal's ioctl pseudo file _.terminal/info_. Whenever the terminal
size changes, the POSIX signal SIGWINCH is delivered to the application.
With this improvement, Vim becomes able to dynamically adjust itself
to changed window dimensions when started as a native Genode component
(w/o the Noux runtime environment).
:SIGINT: If 'stdin' is connected to a terminal, the libc watches the
terminal's pseudo file _.terminal/interrupts_. Since, the terminal VFS
plugin modifies the file for each occurred user interrupt (control-c),
the libc is able to reflect such an event as SIGINT signal to the
application.
:Process-local signal delivery: The libc's implementation of 'kill' got
enhanced with the ability to submit signals to the local process.
Support for arbitrarily large write operations
----------------------------------------------
The number of bytes written by a single 'write' call used to be constrained by
the file's underlying I/O buffer size. Even though our libc correctly returned
this information to the application, we found that real-world applications
rarely check the return value of 'write' because partial writes do usually not
occur on popular POSIX systems. Thanks to the added distinction between
continuous and transactional files as described in Section
[File-system session], we became able to improve the libc's write operation to
iterate on partial writes to continuous files until the original write count
is reached. The split of large write operations into small partial writes as
dictated by the VFS infrastructure becomes invisible to the libc-using
application.
Input-event handling
====================
In Genode 19.08, we undertook a comprehensive rework of our keyboard-event
handling in the light of localization and also promised to tie up remaining
loose ends soon.
First, we again dived into our character generators for a thorough check of
our stack of keyboards and fixed remaining inconsistencies in French and
German layouts. En passant, we also increased the default RAM quotas for
the input filter to 1280K in our recipes to cope with the increased
layout-configuration sizes in corner cases.
Next - and more importantly - we subdued the monsters lurking in our Qt5
keyboard back end and enabled transparent support for system-wide keyboard
layout configuration for Qt5 components. One important change during this work
was to move the handling of control key sequences into the clients. For
example, the graphical terminal and Qt5 interpret key events in combination
with the CTRL modifier based on characters and, thus, support CTRL-A with
AZERTY and QWERTY layouts correctly. As a result we removed all CTRL modifier
(mod2) configurations from our character-generator configurations.
Finally we'd like to point out one important change of our rework that
repeatedly led to surprises: For keys without character mappings the reworked
character-generator mechanism emits invalid codepoints in contrast to
codepoints with value 0. For that reason, components interpreting character
events should check 'Codepoint::valid()' to prevent the processing of invalid
characters (and not the frequent pattern of 'codepoint.value != 0').
NIC router
==========
The NIC router has received the ability to report the link state of its NIC
interfaces (downlinks and uplinks). To control this mechanism, there are two
new boolean attributes 'link_state' and 'link_state_triggers' in the <report>
tag of the NIC router configuration. If the former is set to "true", the report
will contain the current link state for each interface:
! <domain name="domain1">
! <interface label="uplink1" link_state="false"/>
! <interface label="downlink1" link_state="true"/>
! </domain>
! <domain name="domain2">
! <interface label="downlink2" link_state="true"/>
! </domain>
The second attribute decides whether to trigger a report update each time the
link state of an interface changes. By default, both attributes are set to
"false".
Device drivers
==============
Platform driver on x86
~~~~~~~~~~~~~~~~~~~~~~
During our enablement of Genode on a
[https://genodians.org/chelmuth/2019-10-21-sculpt-elitebook - recent notebook],
we spotted some PC platform shortcomings, we address with this release. Most
prominently we added support for
[https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration - 64-bit PCI base address registers]
to the x86 platform driver. This allows the use of PCI devices that are
assigned to physical I/O-memory regions beyond 4 GiB by the boot firmware.
Wireless driver
~~~~~~~~~~~~~~~
We added the firmware images for the 5000 and 9000 series of Intel wireless
devices to the firmware white-list in the _wifi_drv_ component. Such devices
as 5100AGN, 5300AGN and 5350AGN as well as 9461, 9462 and 9560 should now be
usable on Genode.
Libraries and applications
##########################
VirtualBox improvements
=======================
The GUI handling of our VirtualBox port got improved to react on window-size
changes more instantly. The effect is that an interactive adjustment of the
window size, e.g., on Sculpt, becomes quickly visible to the user. Still, the
VM may take some time to adjust to the resolution change, which ultimately
depends on the behavior of the driver of the VirtualBox guest additions.
Updated 3rd-party software
==========================
With the addition of the 64-bit ARM architecture (AARCH64) with the
[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - 19.05]
release, it became necessary to update the libraries the Genode tool chain
(gcc) depends on in order to support AARCH64 properly. This concerns the GNU
multi precision arithmetic library (gmp), which has been updated from version
4.3.2 to 6.1.2, as well as the libraries that depend on it: Multi precision
floating point (mpfr) and multi precision complex arithmetic (mpc). All those
old versions did not offer support for the AARCH64 architecture, which is a
requirement to make Genode self hosting. Targets for building binutils and GCC
within Genode for AARCH64 are in place, GNU make is in place, and even code
coverage (gcov) has been added. This work puts AARCH64 in line with other
supported CPU architectures and emphasizes our interest in the ARM 64-bit
architecture.
Platforms
#########
Execution on bare hardware (base-hw)
====================================
With the previous release, Genode's base-hw kernel got extended to support the
ARMv8-A architecture in principle. The first hardware supported was the
Raspberry Pi 3 as well as the i.MX8 evaluation kit (EVK). But only a single
CPU-core was usable at that time. Now, we lifted this limitation. On both
boards, all four CPU-cores are available henceforth.
Removed components
##################
The current release removes the following components:
:gems/src/app/launcher:
The graphical launcher remained unused for a few years now. It is not
suitable for systems as flexible as Sculpt OS.
:os/src/app/cli_monitor:
CLI monitor was a runtime environment with a custom command-line interface
to start and stop subsystems. It was part of the user interface of our
first take on a Genode-based desktop OS called
[https://genode.org/documentation/release-notes/15.11#Genode_as_desktop_OS - Turmvilla].
Nowadays, we use standard command-line tools like Vim to edit init
configurations dynamically, which is more flexible and - at the same time -
alleviates the need for a custom CLI. The CLI-monitor component was too
limited for use cases like Sculpt anyway.
Along with the CLI monitor, we removed the ancient (and untested for long
time) _terminal_mux.run_ script, which was the only remaining user of the CLI
monitor.
:fatfs_fs, rump_fs, and libc_fatfs plugin:
The stand-alone file-system servers fatfs_fs and rump_fs as well as the
fatfs libc plugin have been superseded by the fatfs and rump VFS plugins.
The stand-alone servers can be replaced by using the VFS server plus the
corresponding VFS plugin as a drop-in replacement.

106
doc/tool_chain.txt
View File

@ -23,22 +23,20 @@ Unified tool chain
##################
Starting with Genode version 11.11, there is a unified tool chain for all base
platforms and supported CPU architectures (x86_32, x86_64, ARM, AARCH64, and
RISC-V).
For Genode development, we highly recommend the use of the official Genode
tool chain. It can be obtained in two ways: as pre-compiled binaries or
manually compiled:
platforms and supported CPU architectures (x86_32, x86_64, ARM, and RISC-V). For
Genode development, we highly recommend the use of the official Genode tool
chain. It can be obtained in two ways: as pre-compiled binaries or manually
compiled:
:Pre-compiled:
Our pre-compiled tool chain is runnable on Linux x86_32 and x86_64. The
archives for both versions will be extracted to
_/usr/local/genode/tool/<version>_.
To extract the archive, use the following command:
archives for both versions will be extracted to '/usr/local/genode-gcc'. To
extract the archive, use the following command:
! sudo tar xPf genode-toolchain-<version>-<arch>.tar.xz
The use of the 'P' option ensures that the tool chain will be installed at
the correct absolute path where the build system expects it to reside by
default. Please note, Genode OS Framework releases require a Genode tool
chain with an equal or next smaller version number.
the correct absolute path '/usr/local/genode-gcc' where the build system
expects it to reside by default. Please note, Genode OS Framework releases
require a Genode tool chain with an equal or next smaller version number.
[https://sourceforge.net/projects/genode/files/genode-toolchain/ - Download the pre-compiled tool chain...]
:Compile from source:
@ -47,16 +45,82 @@ manually compiled:
find the tool in Genode's source tree at 'tool/tool_chain'. For usage
instructions, just start the tool without arguments.
In both cases, the tool chain is installed to _/usr/local/genode/tool/<version>_.
This install location is expected by the build system by default.
The tools are prefixed with 'genode-x86-', 'genode-arm-', 'genode-riscv-', or
'genode-aarch64-' respectively so that it is safe to add the
_/usr/local/genode/tool/<version>/bin/_ path to our 'PATH' environment
variable (optional).
Should you desire to use a different tool chain, create a file called
_tools.conf_ in the _etc/_ subdirectory of your build directory where you can
define the tool-chain prefix to be used:
In both cases, the Genode tool chain will be installed to '/usr/local/genode-gcc'.
All tools are prefixed with 'genode-x86-', 'genode-arm-', or 'genode-riscv-'
respectively such that it is safe to add the installation directory to our
'PATH' variable (optional). The Genode tool chain will be used by the Genode
build system by default. If you desire to use a different tool chain, create a
file called 'tools.conf' in the 'etc/' subdirectory of your build directory
where you can define the tool-chain prefix to be used:
! CROSS_DEV_PREFIX = /path/to/your/custom/tool_chain/your-x86-
However, we recommend you to stick with the official Genode tool chain. If you
see a valid reason not to use it, please contact us (e.g., via the mailing
list).
Background information - Why do we need a special tool chain?
#############################################################
Early on in the genesis of Genode, we introduced a custom tool chain to
overcome several problems inherent to the use of standard tool chains installed
on Linux host platforms.
First, GCC and binutils versions vary a lot between different Linux systems.
Testing the Genode code with all those different tool chains and constantly
adapting the code to the peculiarities of certain tool-chain versions is
infeasible and annoying. Second, Linux tool chains use certain features that
stand in the way when building low-level system components. For example, the
'-fstack-protector' option is enabled by default on some Linux distributions.
Hence, we have to turn it off when building Genode. However, some tool chains
lack this option. So the attempt to turn it off produces an error. The most
important problem with Linux tool chains is the dependency of their respective
GCC support libraries on the glibc. When not using a Linux glibc, as the case
with Genode, this leads to manifold problems, most of them subtle and extremely
hard to debug. For example, the support libraries expect the Linux way of
implementing thread-local storage (using segment registers on x86_32). This
code will simply crash on other kernels. Another example is the use of certain
C-library functions, which are not available on Genode. Hence, Genode provides
custom implementations of those functions (in the 'cxx' library).
Unfortunately, the set of functions used varies across tool-chain versions. For
these reasons, we introduced a custom configured tool chain where we mitigated
those problems by pinning the tools to certain versions and tweaking the
compiler configuration to our needs (i.e., preventing the use of Linux TLS).
That said, the use a our custom configured tool chain was not free from
problems either. In particular, the script for creating the tool chain relied
on a libc being present on the host system. The header files of the libc would
be used to build the GCC support libraries. This introduced two problems. When
adding Genode's libc to the picture, which is based on FreeBSD's C library, the
expectations of the GCC support libraries did not match 100% with the semantics
implemented by Genode's libc (e.g., the handling of 'errno' differs). The
second problem is the limitation that the tool chain could only be built for
the platform that corresponds to the host. For example, on a Linux-x86_32
system, it was not possible to build a x86_64 or ARM tool chain. For this
reason we used the ARM tool chains provided by CodeSourcery.
With Genode 11.11, we addressed the root of the tool-chain problem by
completely decoupling the Genode tool chain from the host system that is used
to build it. The most important step was the removal of GCC's dependency on
a C library, which is normally needed to build the GCC support libraries. We
were able to remove the libc dependency by sneaking-in a small custom libc stub
into the GCC build process. This stub comes in the form of the single header
file 'tool/libgcc_libc_stub.h' and brings along all type definitions and
function declarations expected by the support-library code. Furthermore, we
removed all GNU-specific heuristics from the tool chain. Technically, the
Genode tool chain is a bare-metal tool chain. But in contrast to existing
bare-metal tool chains, C++ is fully supported.
With the libc dependency out of the way, we are now free to build the tool
chain for arbitrary architectures, which brings us two immediate benefits. We
do no longer have to rely on the CodeSourcery tool chain for ARM. There is now
a 'genode-arm' tool chain using the same compiler configuration as used on x86.
The second benefit is the use of multiarch libs on the x86 platform. The
genode-x86 tool chain can be used for both x86_32 and x86_64 as build target,
the latter being the default.
Since we introduced GDB support into Genode, we added GDB in addition to GCC
and binutils to the Genode tool chain. The version is supposed to match the one
expected by Genode's GDB facility, avoiding potential problems with mismatching
protocols between GDB monitor and GDB.

56
flake.lock
View File

@ -1,56 +0,0 @@
{
"inputs": {
"genodepkgs": {
"inputs": {
"dhall-haskell": {
"inputs": {
"nixpkgs": {
"inputs": {},
"narHash": "sha256-wJg4DA700SoQbEz61448sR6BgxRa1R92K3vvCV1g+HY=",
"originalUrl": "git+https://github.com/nixos/nixpkgs.git?ref=18.09-beta&rev=1d4de0d552ae9aa66a5b8dee5fb0650a4372d148",
"url": "git+https://github.com/nixos/nixpkgs.git?ref=18.09-beta&rev=1d4de0d552ae9aa66a5b8dee5fb0650a4372d148"
},
"nixpkgsStaticLinux": {
"inputs": {},
"narHash": "sha256-famU3pJZ4vkElV9qc71HmyRVSvcrAhfMZ0UJKpmmKP8=",
"originalUrl": "git+https://github.com/nh2/nixpkgs.git?ref=static-haskell-nix-stack-dhall-working",
"url": "git+https://github.com/nh2/nixpkgs.git?ref=static-haskell-nix-stack-dhall-working&rev=925aac04f4ca58aceb83beef18cb7dae0715421b"
}
},
"narHash": "sha256-KJl9ZLcMcEsLSPcwcWoc0Ac74/6HKC9LkVMeLwhyhlg=",
"originalUrl": "git+https://github.com/dhall-lang/dhall-haskell?ref=flake",
"url": "git+https://github.com/dhall-lang/dhall-haskell?ref=flake&rev=aea28adf3d10ff1982aa4ddd176d1476251b932f"
},
"genode-depot": {
"inputs": {
"nixpkgs": {
"inputs": {},
"narHash": "sha256-NB+H7zK3BB//zM127FqgbG4iAfY+nS/IOyO+uGWA5Ho=",
"originalUrl": "nixpkgs",
"url": "github:edolstra/nixpkgs/7845bf5f4b3013df1cf036e9c9c3a55a30331db9"
}
},
"narHash": "sha256-7eL2MfGgeEaIwJXPc4LQ7pBa4JeGicm9th7onjKgzsE=",
"originalUrl": "git+https://gitea.c3d2.de/ehmry/genode-depot.git",
"url": "git+https://gitea.c3d2.de/ehmry/genode-depot.git?ref=master&rev=8c2aafed45b4075e37f1cd93de0ebf93f38c83c3"
},
"nixpkgs": {
"inputs": {},
"narHash": "sha256-EqxCk6ORqq4fkewWttpvks0VycBec9X9spAZ+Pq/CEI=",
"originalUrl": "github:ehmry/nixpkgs",
"url": "github:ehmry/nixpkgs/cf50f3b8bdc28832249afab6bca68acad832e011"
}
},
"narHash": "sha256-78eloDNkEjWAckNLbfNait0zb6QBG4QxltX6FyV1vAk=",
"originalUrl": "git+https://git.sr.ht/~ehmry/genodepkgs",
"url": "git+https://git.sr.ht/~ehmry/genodepkgs?ref=master&rev=dad28cc17b17542ada59ba2005fbf1af5d5f8209"
},
"nixpkgs": {
"inputs": {},
"narHash": "sha256-NB+H7zK3BB//zM127FqgbG4iAfY+nS/IOyO+uGWA5Ho=",
"originalUrl": "nixpkgs",
"url": "github:edolstra/nixpkgs/7845bf5f4b3013df1cf036e9c9c3a55a30331db9"
}
},
"version": 3
}

14
flake.nix
View File

@ -1,14 +0,0 @@
{
description = "Genode development flake";
edition = 201909;
inputs.genodepkgs.uri = "git+https://git.sr.ht/~ehmry/genodepkgs";
outputs = { self, nixpkgs, genodepkgs }: {
devShell.x86_64-linux =
genodepkgs.packages.x86_64-linux-x86_64-genode.genode.base;
};
}

50
repos/Tuprules.tup
View File

@ -1,50 +0,0 @@
# Tup rules that are local to this Git repo and
# should not be shared with other projects.
&LD_SCRIPT_SO = base/src/ld/genode_rel.ld
ifeq (@(TUP_ARCH),x86_64)
ASM_SYM_DEPENDENCY = movq \1@GOTPCREL(%rip), %rax
else
ASM_SYM_DEPENDENCY = .long \1
endif
!abi_stub = |> ^ STUB %o^\
sed \
-e "s/^\(\w\+\) D \(\w\+\)\$/.data; .global \1; .type \1,%%object; .size \1,\2; \1:/" \
-e "s/^\(\w\+\) V/.data; .weak \1; .type \1,%%object; \1:/" \
-e "s/^\(\w\+\) T/.text; .global \1; .type \1,%%function; \1:/" \
-e "s/^\(\w\+\) R \(\w\+\)\$/.section .rodata; .global \1; .type \1,%%object; .size \1,\2; \1:/" \
-e "s/^\(\w\+\) W/.text; .weak \1; .type \1,%%function; \1:/" \
-e "s/^\(\w\+\) B \(\w\+\)\$/.bss; .global \1; .type \1,%%object; .size \1,\2; \1:/" \
-e "s/^\(\w\+\) U/.text; .global \1; $(ASM_SYM_DEPENDENCY)/" \
%f > stub.s; \
$(CC) $(CC_MARCH) -x assembler -c stub.s; \
$(LD) -o %o \
-shared \
-T &(LD_SCRIPT_SO) \
stub.o; \
rm -v stub.o stub.s; \
|> $(DEV_LIB_DIR)/%B.lib.so $(DEV_DIR)/<lib>
BASE_DIR = $(GENODE_DIR)/repos/base
&BASE_DIR = base
ifeq (@(TUP_ARCH),i386)
CPPFLAGS += -I$(BASE_DIR)/include/spec/x86_32
CPPFLAGS += -I$(BASE_DIR)/include/spec/x86
CPPFLAGS += -I$(BASE_DIR)/include/spec/32bit
endif
ifeq (@(TUP_ARCH),x86_64)
CPPFLAGS += -I$(BASE_DIR)/include/spec/x86_64
CPPFLAGS += -I$(BASE_DIR)/include/spec/x86
CPPFLAGS += -I$(BASE_DIR)/include/spec/64bit
endif
ifeq (@(TUP_ARCH),arm64)
CPPFLAGS += -I$(BASE_DIR)/include/spec/arm_64
CPPFLAGS += -I$(BASE_DIR)/include/spec/64bit
endif
CPPFLAGS += -I$(BASE_DIR)/include

4
repos/base-fiasco/lib/mk/kernel-fiasco.inc
View File

@ -20,8 +20,8 @@ $(FIASCO_BUILD_DIR):
$(FIASCO): $(FIASCO_BUILD_DIR)
$(VERBOSE_MK) set -o pipefail; \
MAKEFLAGS= CFLAGS="-std=gnu89 $(CWARN)" \
CXXFLAGS="-std=gnu++98 -fno-delete-null-pointer-checks $(CXXWARN)" \
MAKEFLAGS= CFLAGS="-std=gnu89" \
CXXFLAGS="-std=gnu++98 -fno-delete-null-pointer-checks" \
$(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
$(VERBOSE_DIR) -C $(FIASCO_BUILD_DIR) \
$(KERNEL_BUILD_OUTPUT_FILTER)

12
repos/base-fiasco/lib/mk/l4_pkg.inc
View File

@ -48,14 +48,6 @@ endif
#
.NOTPARALLEL: $(PKG_TAGS)
WARN = -Wno-attributes -Wno-cast-function-type -Wno-format-truncation \
-Wno-frame-address -Wno-ignored-qualifiers -Wno-implicit-fallthrough \
-Wno-maybe-uninitialized -Wno-misleading-indentation \
-Wno-nonnull-compare -Wno-nonnull-compare -Wno-restrict \
-Wno-tautological-compare -Wno-unused-but-set-variable -Wno-unused-result
CWARN = $(WARN) -Wno-int-conversion -Wno-pointer-sign -Wno-pointer-to-int-cast
CXXWARN = $(WARN) -Wno-bool-compare -Wno-c++11-compat -Wno-class-memaccess
#
# The '_GNU_SOURCE' definition is needed to convince uClibc to define the
# 'off64_t' type, which is used by bootstrap.
@ -63,8 +55,8 @@ CXXWARN = $(WARN) -Wno-bool-compare -Wno-c++11-compat -Wno-class-memaccess
%.tag:
$(VERBOSE_MK) set -o pipefail; \
MAKEFLAGS= CPPFLAGS="$(CC_MARCH)" \
CFLAGS="$(CC_MARCH) -std=gnu89 $(CWARN)" \
CXXFLAGS="$(CC_MARCH) -D_GNU_SOURCE -std=gnu++98 $(CXXWARN)" \
CFLAGS="$(CC_MARCH) -std=gnu89" \
CXXFLAGS="$(CC_MARCH) -D_GNU_SOURCE -std=gnu++98" \
ASFLAGS="$(CC_MARCH)" LDFLAGS="$(LD_MARCH)" \
$(MAKE) $(VERBOSE_DIR) O=$(L4_BUILD_DIR) $(L4_VERBOSE) \
-C $(L4_PKG_DIR)/$* \

2
repos/base-fiasco/recipes/src/base-fiasco/hash
View File

@ -1 +1 @@
2019-11-25 c7e2a3eca5820b2304b4520d0fc831ede73691f2
2019-02-25 fdd7327c61039906dc79d684513972a0472fa430

3
repos/base-fiasco/src/core/include/platform_thread.h
View File

@ -17,7 +17,6 @@
/* Genode includes */
#include <base/native_capability.h>
#include <base/thread_state.h>
#include <base/trace/types.h>
/* core includes */
#include <pager.h>
@ -179,7 +178,7 @@ namespace Genode {
/**
* Return execution time consumed by the thread
*/
Trace::Execution_time execution_time() const { return { 0, 0 }; }
unsigned long long execution_time() const { return 0; }
/*******************************

4
repos/base-foc/config/arndale.kernel
View File

@ -3,10 +3,8 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
CONFIG_HAS_CPU_VIRT=y
@ -57,7 +55,6 @@ CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A15=y
# CONFIG_CPU_VIRT is not set
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
CONFIG_HAVE_ARM_SECMONIF_NONE=y
CONFIG_HAVE_ARM_SECMONIF_MC=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
@ -90,7 +87,6 @@ CONFIG_INLINE=y
CONFIG_SERIAL=y
CONFIG_JDB=y
# CONFIG_JDB_LOGGING is not set
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/arndale.user
View File

@ -43,23 +43,25 @@ CONFIG_PLATFORM_TYPE_exynos5=y
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="exynos5"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

9
repos/base-foc/config/imx6q_sabrelite.kernel
View File

@ -3,10 +3,8 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
@ -54,7 +52,6 @@ CONFIG_PF_IMX_6_TIMER_MPTIMER=y
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A9=y
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
@ -62,13 +59,14 @@ CONFIG_ARM_EM_STD=y
# CONFIG_ARM_SMC_USER is not set
CONFIG_ARM_CACHE_L2CXX0=y
# CONFIG_ARM_ENABLE_SWP is not set
CONFIG_HAS_ARM_PSCI=y
# CONFIG_ARM_PSCI is not set
CONFIG_ARM_CPU_ERRATA=y
#
# Kernel options
#
CONFIG_MP=y
CONFIG_MP_MAX_CPUS=4
# CONFIG_MP is not set
CONFIG_CONTEXT_4K=y
# CONFIG_FINE_GRAINED_CPUTIME is not set
CONFIG_SCHED_FIXED_PRIO=y
@ -85,7 +83,6 @@ CONFIG_NO_FRAME_PTR=y
CONFIG_SERIAL=y
CONFIG_JDB=y
CONFIG_JDB_LOGGING=y
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/imx6q_sabrelite.user
View File

@ -43,23 +43,25 @@ CONFIG_CPU_ARMV6PLUS=y
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
CONFIG_PLATFORM_TYPE_imx6=y
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="imx6"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

116
repos/base-foc/config/imx7.kernel
View File

@ -1,116 +0,0 @@
#
# Automatically generated file; DO NOT EDIT.
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
CONFIG_HAS_CPU_VIRT=y
#
# Target configuration
#
# CONFIG_IA32 is not set
# CONFIG_AMD64 is not set
CONFIG_ARM=y
# CONFIG_MIPS is not set
# CONFIG_PF_INTEGRATOR is not set
# CONFIG_PF_REALVIEW is not set
# CONFIG_PF_SUNXI is not set
# CONFIG_PF_BCM283X is not set
# CONFIG_PF_SA1100 is not set
# CONFIG_PF_XSCALE is not set
# CONFIG_PF_ARMADA38X is not set
# CONFIG_PF_KIRKWOOD is not set
# CONFIG_PF_TEGRA is not set
# CONFIG_PF_LAYERSCAPE is not set
CONFIG_PF_IMX=y
# CONFIG_PF_ARM_VIRT is not set
# CONFIG_PF_RCAR3 is not set
# CONFIG_PF_EXYNOS is not set
# CONFIG_PF_S3C2410 is not set
# CONFIG_PF_OMAP is not set
# CONFIG_PF_ZYNQ is not set
# CONFIG_PF_ZYNQMP is not set
CONFIG_BSP_NAME="imx"
CONFIG_CAN_ARM_CPU_CORTEX_A7=y
CONFIG_ARM_V7=y
CONFIG_ARM_V6PLUS=y
CONFIG_ARM_V7PLUS=y
# CONFIG_PF_IMX_21 is not set
# CONFIG_PF_IMX_28 is not set
# CONFIG_PF_IMX_35 is not set
# CONFIG_PF_IMX_51 is not set
# CONFIG_PF_IMX_6 is not set
# CONFIG_PF_IMX_6UL is not set
CONFIG_PF_IMX_7=y
CONFIG_PF_IMX_RAM_PHYS_BASE=0x80000000
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A7=y
# CONFIG_CPU_VIRT is not set
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
# CONFIG_ARM_EM_TZ is not set
# CONFIG_ARM_SMC_USER is not set
# CONFIG_ARM_ENABLE_SWP is not set
CONFIG_ARM_LPAE=y
CONFIG_HAS_ARM_PSCI=y
# CONFIG_ARM_PSCI is not set
CONFIG_ARM_CPU_ERRATA=y
#
# Kernel options
#
CONFIG_MP=y
CONFIG_MP_MAX_CPUS=2
CONFIG_CONTEXT_4K=y
# CONFIG_FINE_GRAINED_CPUTIME is not set
CONFIG_SCHED_FIXED_PRIO=y
CONFIG_VIRT_OBJ_SPACE=y
#
# Debugging
#
CONFIG_INLINE=y
# CONFIG_NDEBUG is not set
# CONFIG_NO_FRAME_PTR is not set
# CONFIG_STACK_DEPTH is not set
# CONFIG_LIST_ALLOC_SANITY is not set
CONFIG_SERIAL=y
CONFIG_JDB=y
# CONFIG_JDB_LOGGING is not set
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set
CONFIG_WARN_WARNING=y
# CONFIG_WARN_ANY is not set
#
# ARM debugging options
#
# CONFIG_VMEM_ALLOC_TEST is not set
# CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set
#
# Compiling
#
CONFIG_CC="gcc"
CONFIG_CXX="g++"
CONFIG_HOST_CC="gcc"
CONFIG_HOST_CXX="g++"
# CONFIG_MAINTAINER_MODE is not set
CONFIG_LABEL=""
# CONFIG_EXPERIMENTAL is not set
CONFIG_PERF_CNT=y
CONFIG_BIT32=y
CONFIG_WARN_LEVEL=1
CONFIG_XARCH="arm"
CONFIG_ABI="vf"

84
repos/base-foc/config/imx7.user
View File

@ -1,84 +0,0 @@
#
# Automatically generated file; DO NOT EDIT.
# L4Re Configuration
#
CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y
# CONFIG_BUILD_ARCH_amd64 is not set
CONFIG_BUILD_ARCH_arm=y
# CONFIG_BUILD_ARCH_arm64 is not set
# CONFIG_BUILD_ARCH_mips is not set
# CONFIG_BUILD_ARCH_ppc32 is not set
# CONFIG_BUILD_ARCH_sparc is not set
# CONFIG_BUILD_ARCH_x86 is not set
CONFIG_BUILD_ARCH="arm"
CONFIG_BUILD_ABI_l4f=y
CONFIG_BUILD_ABI="l4f"
# CONFIG_CPU_ARM_ARMV4 is not set
# CONFIG_CPU_ARM_ARMV4T is not set
# CONFIG_CPU_ARM_ARMV5 is not set
# CONFIG_CPU_ARM_ARMV5T is not set
# CONFIG_CPU_ARM_ARMV5TE is not set
# CONFIG_CPU_ARM_ARMV6 is not set
# CONFIG_CPU_ARM_ARMV6T2 is not set
# CONFIG_CPU_ARM_ARMV6ZK is not set
CONFIG_CPU_ARM_ARMV7A=y
CONFIG_CPU="armv7a"
CONFIG_CPU_ARMV6KPLUS=y
CONFIG_CPU_ARMV6PLUS=y
# CONFIG_PLATFORM_TYPE_exynos4 is not set
# CONFIG_PLATFORM_TYPE_imx35 is not set
# CONFIG_PLATFORM_TYPE_zedboard is not set
# CONFIG_PLATFORM_TYPE_beagleboard is not set
# CONFIG_PLATFORM_TYPE_rv_pbx is not set
# CONFIG_PLATFORM_TYPE_exynos5 is not set
# CONFIG_PLATFORM_TYPE_kirkwood is not set
# CONFIG_PLATFORM_TYPE_ls1012afrdm is not set
# CONFIG_PLATFORM_TYPE_pandaboard is not set
# CONFIG_PLATFORM_TYPE_arm_virt is not set
# CONFIG_PLATFORM_TYPE_tegra2 is not set
# CONFIG_PLATFORM_TYPE_rv is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress_a15 is not set
# CONFIG_PLATFORM_TYPE_cubieboard2 is not set
# CONFIG_PLATFORM_TYPE_omap3_am33xx is not set
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
CONFIG_PLATFORM_TYPE_imx7=y
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="imx7"
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y
#
# Building
#
CONFIG_YACC="yacc"
CONFIG_LEX="flex"
CONFIG_CTAGS="ctags"
CONFIG_ETAGS="etags"
CONFIG_HAVE_LDSO=y
CONFIG_INT_CPP_NAME_SWITCH=y
CONFIG_INT_LD_NAME_SWITCH=y
# CONFIG_BID_STRIP_PROGS is not set
# CONFIG_BID_GCC_OMIT_FP is not set
CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR=y
# CONFIG_BID_GCC_STACK_PROTECTOR_ALL is not set
CONFIG_BID_GCC_STACK_PROTECTOR=y
# CONFIG_BID_BUILD_DOC is not set
# CONFIG_RELEASE_MODE is not set
CONFIG_MAKECONFS_ADD=""

4
repos/base-foc/config/odroid_x2.kernel
View File

@ -3,10 +3,8 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
@ -56,7 +54,6 @@ CONFIG_PF_EXYNOS_TIMER_MCT=y
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A9=y
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
CONFIG_HAVE_ARM_SECMONIF_NONE=y
CONFIG_HAVE_ARM_SECMONIF_MC=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
@ -91,7 +88,6 @@ CONFIG_NO_FRAME_PTR=y
CONFIG_SERIAL=y
CONFIG_JDB=y
# CONFIG_JDB_LOGGING is not set
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/odroid_x2.user
View File

@ -43,23 +43,25 @@ CONFIG_PLATFORM_TYPE_exynos4=y
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="exynos4"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

4
repos/base-foc/config/panda.kernel
View File

@ -3,10 +3,8 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
@ -49,7 +47,6 @@ CONFIG_PF_OMAP4_PANDABOARD=y
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A9=y
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
@ -80,7 +77,6 @@ CONFIG_INLINE=y
CONFIG_SERIAL=y
CONFIG_JDB=y
CONFIG_JDB_LOGGING=y
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/panda.user
View File

@ -43,23 +43,25 @@ CONFIG_PLATFORM_TYPE_pandaboard=y
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="pandaboard"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

4
repos/base-foc/config/pbxa9.kernel
View File

@ -3,10 +3,8 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
@ -52,7 +50,6 @@ CONFIG_PF_REALVIEW_RAM_PHYS_BASE=0x70000000
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A9=y
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
@ -82,7 +79,6 @@ CONFIG_NO_FRAME_PTR=y
CONFIG_SERIAL=y
CONFIG_JDB=y
CONFIG_JDB_LOGGING=y
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/pbxa9.user
View File

@ -43,23 +43,25 @@ CONFIG_PLATFORM_TYPE_rv_pbx=y
# CONFIG_PLATFORM_TYPE_parallella is not set
# CONFIG_PLATFORM_TYPE_rpi_b is not set
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="rv_pbx"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

5
repos/base-foc/config/rpi.kernel
View File

@ -3,9 +3,7 @@
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
#
@ -40,11 +38,9 @@ CONFIG_ARM_V6PLUS=y
CONFIG_PF_BCM283X_RPI1=y
# CONFIG_PF_BCM283X_RPI2 is not set
# CONFIG_PF_BCM283X_RPI3 is not set
# CONFIG_PF_BCM283X_RPIZW is not set
CONFIG_ABI_VF=y
CONFIG_ARM_1176=y
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
@ -73,7 +69,6 @@ CONFIG_NO_FRAME_PTR=y
CONFIG_SERIAL=y
CONFIG_JDB=y
# CONFIG_JDB_LOGGING is not set
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set

6
repos/base-foc/config/rpi.user
View File

@ -42,23 +42,25 @@ CONFIG_CPU_ARMV6PLUS=y
# CONFIG_PLATFORM_TYPE_parallella is not set
CONFIG_PLATFORM_TYPE_rpi_b=y
# CONFIG_PLATFORM_TYPE_imx21 is not set
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
# CONFIG_PLATFORM_TYPE_tegra3 is not set
# CONFIG_PLATFORM_TYPE_imx7 is not set
# CONFIG_PLATFORM_TYPE_imx28 is not set
# CONFIG_PLATFORM_TYPE_omap3evm is not set
# CONFIG_PLATFORM_TYPE_rcar3_m3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_imx6 is not set
# CONFIG_PLATFORM_TYPE_imx6ul is not set
# CONFIG_PLATFORM_TYPE_armada38x is not set
# CONFIG_PLATFORM_TYPE_omap5 is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
# CONFIG_PLATFORM_TYPE_imx51 is not set
# CONFIG_PLATFORM_TYPE_rpi_a is not set
# CONFIG_PLATFORM_TYPE_integrator is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="rpi_b"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

113
repos/base-foc/config/rpi3.kernel
View File

@ -1,113 +0,0 @@
#
# Automatically generated file; DO NOT EDIT.
# Fiasco configuration
#
CONFIG_HAS_FPU_OPTION=y
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_JDB_DISASM_OPTION=y
CONFIG_HAS_JDB_GZIP_OPTION=y
CONFIG_HAS_MP_OPTION=y
CONFIG_HAS_CPU_VIRT=y
#
# Target configuration
#
# CONFIG_IA32 is not set
# CONFIG_AMD64 is not set
CONFIG_ARM=y
# CONFIG_MIPS is not set
# CONFIG_PF_INTEGRATOR is not set
# CONFIG_PF_REALVIEW is not set
# CONFIG_PF_SUNXI is not set
CONFIG_PF_BCM283X=y
# CONFIG_PF_SA1100 is not set
# CONFIG_PF_XSCALE is not set
# CONFIG_PF_ARMADA38X is not set
# CONFIG_PF_KIRKWOOD is not set
# CONFIG_PF_TEGRA is not set
# CONFIG_PF_LAYERSCAPE is not set
# CONFIG_PF_IMX is not set
# CONFIG_PF_ARM_VIRT is not set
# CONFIG_PF_RCAR3 is not set
# CONFIG_PF_EXYNOS is not set
# CONFIG_PF_S3C2410 is not set
# CONFIG_PF_OMAP is not set
# CONFIG_PF_ZYNQ is not set
# CONFIG_PF_ZYNQMP is not set
CONFIG_BSP_NAME="bcm283x"
CONFIG_HAS_64BIT=y
CONFIG_CAN_ARM_CPU_CORTEX_A53=y
CONFIG_ARM_V6PLUS=y
CONFIG_ARM_V7PLUS=y
CONFIG_ARM_V8=y
# CONFIG_PF_BCM283X_RPI1 is not set
# CONFIG_PF_BCM283X_RPI2 is not set
CONFIG_PF_BCM283X_RPI3=y
# CONFIG_PF_BCM283X_RPIZW is not set
CONFIG_ABI_VF=y
CONFIG_ARM_CORTEX_A53=y
# CONFIG_CPU_VIRT is not set
CONFIG_FPU=y
CONFIG_LAZY_FPU=y
# CONFIG_ARM_ALIGNMENT_CHECK is not set
CONFIG_ARM_EM_STD=y
# CONFIG_ARM_EM_NS is not set
# CONFIG_ARM_SMC_USER is not set
CONFIG_BIT64_CHOICE=y
CONFIG_ARM_LPAE=y
# CONFIG_ARM_CPU_ERRATA is not set
#
# Kernel options
#
CONFIG_MP=y
CONFIG_MP_MAX_CPUS=4
CONFIG_CONTEXT_8K=y
# CONFIG_FINE_GRAINED_CPUTIME is not set
CONFIG_SCHED_FIXED_PRIO=y
# CONFIG_SCHED_WFQ is not set
# CONFIG_SCHED_FP_WFQ is not set
# CONFIG_DISABLE_VIRT_OBJ_SPACE is not set
CONFIG_VIRT_OBJ_SPACE=y
#
# Debugging
#
CONFIG_INLINE=y
# CONFIG_NDEBUG is not set
# CONFIG_NO_FRAME_PTR is not set
# CONFIG_STACK_DEPTH is not set
# CONFIG_LIST_ALLOC_SANITY is not set
CONFIG_SERIAL=y
CONFIG_JDB=y
CONFIG_JDB_LOGGING=y
# CONFIG_JDB_DISASM is not set
CONFIG_JDB_GZIP=y
# CONFIG_JDB_ACCOUNTING is not set
# CONFIG_WARN_NONE is not set
CONFIG_WARN_WARNING=y
# CONFIG_WARN_ANY is not set
#
# ARM debugging options
#
# CONFIG_VMEM_ALLOC_TEST is not set
# CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set
#
# Compiling
#
CONFIG_CC="gcc"
CONFIG_CXX="g++"
CONFIG_HOST_CC="gcc"
CONFIG_HOST_CXX="g++"
# CONFIG_MAINTAINER_MODE is not set
CONFIG_LABEL=""
CONFIG_EXPERIMENTAL=y
CONFIG_PERF_CNT=y
CONFIG_BIT64=y
CONFIG_WARN_LEVEL=1
CONFIG_XARCH="arm"
CONFIG_ABI="vf"

47
repos/base-foc/config/rpi3.user
View File

@ -1,47 +0,0 @@
#
# Automatically generated file; DO NOT EDIT.
# L4Re Configuration
#
CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y
# CONFIG_BUILD_ARCH_amd64 is not set
# CONFIG_BUILD_ARCH_arm is not set
CONFIG_BUILD_ARCH_arm64=y
# CONFIG_BUILD_ARCH_mips is not set
# CONFIG_BUILD_ARCH_ppc32 is not set
# CONFIG_BUILD_ARCH_sparc is not set
# CONFIG_BUILD_ARCH_x86 is not set
CONFIG_BUILD_ARCH="arm64"
CONFIG_BUILD_ABI_l4f=y
CONFIG_BUILD_ABI="l4f"
CONFIG_CPU="armv8a"
CONFIG_CPU_ARM_ARMV8A=y
# CONFIG_PLATFORM_TYPE_ls1012afrdm is not set
# CONFIG_PLATFORM_TYPE_arm_virt is not set
# CONFIG_PLATFORM_TYPE_rv_vexpress_a15 is not set
CONFIG_PLATFORM_TYPE_rpi_b=y
# CONFIG_PLATFORM_TYPE_rcar3 is not set
# CONFIG_PLATFORM_TYPE_zynqmp is not set
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="rpi_b"
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y
#
# Building
#
CONFIG_YACC="yacc"
CONFIG_LEX="flex"
CONFIG_CTAGS="ctags"
CONFIG_ETAGS="etags"
CONFIG_HAVE_LDSO=y
CONFIG_INT_CPP_NAME_SWITCH=y
CONFIG_INT_LD_NAME_SWITCH=y
# CONFIG_BID_STRIP_PROGS is not set
CONFIG_BID_GCC_OMIT_FP=y
CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR=y
# CONFIG_BID_GCC_STACK_PROTECTOR_ALL is not set
CONFIG_BID_GCC_STACK_PROTECTOR=y
# CONFIG_BID_BUILD_DOC is not set
# CONFIG_RELEASE_MODE is not set
CONFIG_MAKECONFS_ADD=""

5
repos/base-foc/config/x86_32.kernel
View File

@ -2,7 +2,6 @@
# Automatically generated file; DO NOT EDIT.
# Fiasco configuration
#
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_WATCHDOG_OPTION=y
@ -22,12 +21,10 @@ CONFIG_IA32=y
CONFIG_PF_PC=y
# CONFIG_PF_UX is not set
CONFIG_ABI_VF=y
CONFIG_CPU_VIRT=y
# CONFIG_CPU_VIRT is not set
CONFIG_SCHED_APIC=y
# CONFIG_WORKAROUND_AMD_FPU_LEAK is not set
CONFIG_REGPARM3=y
CONFIG_FPU=y
# CONFIG_LAZY_FPU is not set
#
# Kernel options

2
repos/base-foc/config/x86_32.user
View File

@ -17,6 +17,8 @@ CONFIG_CPU="586"
CONFIG_PLATFORM_TYPE_pc=y
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="pc"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

5
repos/base-foc/config/x86_64.kernel
View File

@ -2,7 +2,6 @@
# Automatically generated file; DO NOT EDIT.
# Fiasco configuration
#
CONFIG_HAS_LAZY_FPU=y
CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
CONFIG_HAS_SERIAL_OPTION=y
CONFIG_HAS_WATCHDOG_OPTION=y
@ -21,11 +20,9 @@ CONFIG_AMD64=y
# CONFIG_MIPS is not set
CONFIG_PF_PC=y
CONFIG_ABI_VF=y
CONFIG_CPU_VIRT=y
# CONFIG_CPU_VIRT is not set
CONFIG_SCHED_APIC=y
# CONFIG_WORKAROUND_AMD_FPU_LEAK is not set
CONFIG_FPU=y
# CONFIG_LAZY_FPU is not set
#
# Kernel options

2
repos/base-foc/config/x86_64.user
View File

@ -17,6 +17,8 @@ CONFIG_CPU="K8"
CONFIG_PLATFORM_TYPE_pc=y
# CONFIG_PLATFORM_TYPE_custom is not set
CONFIG_PLATFORM_TYPE="pc"
# CONFIG_USE_DROPS_STDDIR is not set
# CONFIG_USE_DICE is not set
CONFIG_DROPS_STDDIR="/path/to/l4re"
CONFIG_DROPS_INSTDIR="/path/to/l4re"
CONFIG_BID_COLORED_PHASES=y

16
repos/base-foc/include/foc/native_capability.h
View File

@ -48,7 +48,7 @@ namespace Fiasco {
static constexpr l4_cap_idx_t THREAD_AREA_BASE = 0xcUL << L4_CAP_SHIFT;
/* size of one thread slot */
static constexpr l4_cap_idx_t THREAD_AREA_SLOT = 0x5UL << L4_CAP_SHIFT;
static constexpr l4_cap_idx_t THREAD_AREA_SLOT = 0x3UL << L4_CAP_SHIFT;
/* offset to the ipc gate cap selector in the slot */
static constexpr l4_cap_idx_t THREAD_GATE_CAP = 0;
@ -59,26 +59,16 @@ namespace Fiasco {
/* offset to the irq cap selector in the slot */
static constexpr l4_cap_idx_t THREAD_IRQ_CAP = 0x2UL << L4_CAP_SHIFT;
/* offset to the irq cap selector in the slot */
static constexpr l4_cap_idx_t TASK_VCPU_CAP = 0x3UL << L4_CAP_SHIFT;
/* offset to the irq cap selector in the slot */
static constexpr l4_cap_idx_t TASK_VCPU_IRQ_CAP = 0x4UL << L4_CAP_SHIFT;
/* shortcut to the main thread's gate cap */
static constexpr l4_cap_idx_t MAIN_THREAD_CAP = THREAD_AREA_BASE
+ THREAD_GATE_CAP;
/*********************************************************
** Capability selectors controlled by the task itself **
** Capability seclectors controlled by the task itself **
*********************************************************/
static constexpr unsigned THREAD_MAX = (1 << 7);
static constexpr l4_cap_idx_t USER_BASE_CAP = 0x300 << L4_CAP_SHIFT;
static_assert(USER_BASE_CAP > THREAD_MAX * THREAD_AREA_SLOT,
"USER_BASE_CAP too small for supported maximal threads");
static constexpr l4_cap_idx_t USER_BASE_CAP = 0x200UL << L4_CAP_SHIFT;
struct Capability
{

6
repos/base-foc/lib/import/import-syscall-foc.mk
View File

@ -13,12 +13,6 @@ ifeq ($(filter-out $(SPECS),arm),)
CC_OPT += -DARCH_arm
endif # ARM
ifeq ($(filter-out $(SPECS),arm_64),)
INC_DIR += $(L4_INCLUDE_DIR)/arm64/l4f $(L4_INCLUDE_DIR)/arm64
CC_OPT += -DARCH_arm64
endif # ARM
INC_DIR += $(L4_INCLUDE_DIR)/l4f $(L4_INCLUDE_DIR)
CC_OPT += -DCONFIG_L4_CALL_SYSCALLS

15
repos/base-foc/lib/mk/base-foc-common.inc
View File

@ -1,15 +0,0 @@
#
# \brief Portions of base library shared by core and non-core processes
# \author Norman Feske
# \date 2013-02-14
#
include $(BASE_DIR)/lib/mk/base-common.inc
LIBS += syscall-foc startup-foc
SRC_CC += spin_lock.cc cap_map.cc
SRC_CC += rpc_dispatch_loop.cc
SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc utcb.cc
SRC_CC += capability.cc
SRC_CC += signal_source_client.cc

10
repos/base-foc/lib/mk/base-foc-common.mk
View File

@ -4,4 +4,12 @@
# \date 2013-02-14
#
include $(REP_DIR)/lib/mk/base-foc-common.inc
include $(BASE_DIR)/lib/mk/base-common.inc
LIBS += syscall-foc startup-foc
SRC_CC += spin_lock.cc cap_map.cc
SRC_CC += rpc_dispatch_loop.cc
SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc utcb.cc
SRC_CC += capability.cc
SRC_CC += signal_source_client.cc

1
repos/base-foc/lib/mk/base-foc.inc
View File

@ -3,7 +3,6 @@ include $(BASE_DIR)/lib/mk/base.inc
LIBS += base-foc-common syscall-foc cxx
SRC_CC += cap_map_remove.cc cap_alloc.cc
SRC_CC += cache.cc
SRC_CC += thread_start.cc
SRC_CC += signal_transmitter.cc signal.cc
SRC_CC += stack_area_addr.cc

4
repos/base-foc/lib/mk/core-foc.inc
View File

@ -27,6 +27,7 @@ SRC_CC += stack_area.cc \
platform.cc \
platform_rom_modules.cc \
platform_pd.cc \
platform_services.cc \
platform_thread.cc \
pd_session_component.cc \
ram_dataspace_support.cc \
@ -38,8 +39,6 @@ SRC_CC += stack_area.cc \
signal_receiver.cc \
thread_start.cc \
trace_session_component.cc \
vm_session_component.cc \
vm_session_common.cc \
heartbeat.cc
INC_DIR += $(REP_DIR)/src/core/include \
@ -73,6 +72,5 @@ vpath core_rpc_cap_alloc.cc $(GEN_CORE_DIR)
vpath core_region_map.cc $(GEN_CORE_DIR)
vpath platform_rom_modules.cc $(GEN_CORE_DIR)
vpath heartbeat.cc $(GEN_CORE_DIR)
vpath vm_session_common.cc $(GEN_CORE_DIR)
vpath %.cc $(REP_DIR)/src/core
vpath %.cc $(REP_DIR)/src/lib/base

5
repos/base-foc/lib/mk/kernel-foc.inc
View File

@ -1,5 +1,4 @@
BOARD ?= unknown
FOC_BUILD_DIR = $(shell pwd)/$(BOARD)-build
FOC_BUILD_DIR = $(shell pwd)/build
FOC = $(FOC_BUILD_DIR)/foc
FOC_SRC := $(call select_from_ports,foc)/src/kernel/foc/kernel/fiasco
@ -42,7 +41,7 @@ PKGS := l4re-core/crtn \
drivers-frst/include drivers-frst/of drivers-frst/uart \
bootstrap
L4_BUILD_DIR := $(LIB_CACHE_DIR)/syscall-foc/$(BOARD)-build
L4_BUILD_DIR := $(LIB_CACHE_DIR)/syscall-foc/build
#
# Supress several warnings especially of the uclibc-minimal

9
repos/base-foc/lib/mk/l4_pkg.inc
View File

@ -24,18 +24,13 @@ ifeq ($(filter-out $(SPECS),arm_v6),)
L4_BUILD_ARCH := arm_armv6
endif
ifeq ($(filter-out $(SPECS),arm_v8),)
L4_BUILD_ARCH := arm64_armv8a
endif
ifeq ($(L4_BUILD_ARCH),)
$(error L4_BUILD_ARCH undefined, architecture not supported)
endif
L4_BUILD_OPT = CROSS_COMPILE=$(CROSS_DEV_PREFIX)
L4_PKG_DIR := $(call select_from_ports,foc)/src/kernel/foc/l4/pkg
PKG_TAGS = $(addsuffix .tag,$(addsuffix .$(BOARD),$(PKGS)))
PKG_TAGS = $(addsuffix .tag,$(PKGS))
BUILD_OUTPUT_FILTER = 2>&1 | sed "s~^~ [$*] ~"
@ -54,7 +49,7 @@ endif
#
.NOTPARALLEL: $(PKG_TAGS)
%.$(BOARD).tag:
%.tag:
$(VERBOSE_MK) set -o pipefail; \
$(MAKE) $(VERBOSE_DIR) O=$(L4_BUILD_DIR) -C $(L4_PKG_DIR)/$* \
"$(L4_BUILD_OPT)" WARNINGS=$(WARNINGS) $(BUILD_OUTPUT_FILTER)

3
repos/base-foc/lib/mk/spec/arm/base-foc.mk
View File

@ -1,3 +1,6 @@
# override default stack-area location
INC_DIR += $(REP_DIR)/src/include/spec/arm
LIBS += timeout-arm
include $(REP_DIR)/lib/mk/base-foc.inc

3
repos/base-foc/lib/mk/spec/arm/core-foc.mk
View File

@ -1,7 +1,6 @@
REQUIRES += arm
SRC_CC += spec/arm/platform_arm.cc \
spec/arm/ipc_pager.cc \
platform_services.cc
spec/arm/ipc_pager.cc
# override default stack-area location
INC_DIR += $(REP_DIR)/src/include/spec/arm

3
repos/base-foc/lib/mk/spec/arm_64/base-foc.mk
View File

@ -1,3 +0,0 @@
LIBS += timeout
include $(REP_DIR)/lib/mk/base-foc.inc

8
repos/base-foc/lib/mk/spec/arm_64/core-foc.mk
View File

@ -1,8 +0,0 @@
REQUIRES += arm_64
SRC_CC += spec/arm/platform_arm.cc \
spec/arm_64/ipc_pager.cc \
platform_services.cc
include $(REP_DIR)/lib/mk/core-foc.inc
vpath platform_services.cc $(GEN_CORE_DIR)

3
repos/base-foc/lib/mk/spec/arm_64/ld-foc.mk
View File

@ -1,3 +0,0 @@
BASE_LIBS += base-foc-common base-foc
include $(BASE_DIR)/lib/mk/spec/arm_64/ld-platform.inc

5
repos/base-foc/lib/mk/spec/arm_64/startup-foc.mk
View File

@ -1,5 +0,0 @@
LIBS += syscall-foc
include $(BASE_DIR)/lib/mk/startup.inc
vpath crt0.s $(BASE_DIR)/src/lib/startup/spec/arm_64

2
repos/base-foc/lib/mk/spec/arndale/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/arndale.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/arndale-build/bin/arm_armv7a
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/imx6q_sabrelite/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/imx6q_sabrelite.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/imx6q_sabrelite-build/bin/arm_armv7a
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

3
repos/base-foc/lib/mk/spec/imx7d_sabre/kernel-foc.mk
View File

@ -1,3 +0,0 @@
KERNEL_CONFIG := $(REP_DIR)/config/imx7.kernel
include $(REP_DIR)/lib/mk/kernel-foc.inc

5
repos/base-foc/lib/mk/spec/imx7d_sabre/syscall-foc.mk
View File

@ -1,5 +0,0 @@
L4_CONFIG := $(call select_from_repositories,config/imx7.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/imx7d_sabre-build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/odroid_x2/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/odroid_x2.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/odroid_x2-build/bin/arm_armv7a
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/panda/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/panda.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/panda-build/bin/arm_armv7a
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/pbxa9/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/pbxa9.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/pbxa9-build/bin/arm_armv7a
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv7a
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/rpi/syscall-foc.mk
View File

@ -1,5 +1,5 @@
L4_CONFIG := $(call select_from_repositories,config/rpi.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/rpi-build/bin/arm_armv6
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/arm_armv6
include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

3
repos/base-foc/lib/mk/spec/rpi3/kernel-foc.mk
View File

@ -1,3 +0,0 @@
KERNEL_CONFIG := $(REP_DIR)/config/rpi3.kernel
include $(REP_DIR)/lib/mk/kernel-foc.inc

18
repos/base-foc/lib/mk/spec/rpi3/syscall-foc.mk
View File

@ -1,18 +0,0 @@
L4_CONFIG := $(call select_from_repositories,config/rpi3.user)
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/rpi3-build/bin/arm64_armv8a
L4_INC_TARGETS = arm64/l4/sys \
arm64/l4f/l4/sys \
arm64/l4/vcpu
CC_OPT += -Iinclude/arm64
include $(REP_DIR)/lib/mk/syscall-foc.inc
SRC_C += utcb.c
utcb.c:
$(VERBOSE)ln -sf $(L4_BUILD_DIR)/source/pkg/l4re-core/l4sys/lib/src/utcb.c
utcb.c: $(PKG_TAGS)

9
repos/base-foc/lib/mk/spec/x86/base-foc-common.mk
View File

@ -1,9 +0,0 @@
#
# \brief Portions of base library shared by core and non-core processes
# \author Norman Feske
# \date 2013-02-14
#
vpath vm_session.cc $(REP_DIR)/src/lib/base/x86
include $(REP_DIR)/lib/mk/base-foc-common.inc

4
repos/base-foc/lib/mk/spec/x86/core-foc.inc
View File

@ -1,10 +1,10 @@
SRC_CC += io_port_session_component.cc \
io_port_session_support.cc \
spec/x86/ipc_pager.cc \
spec/x86/platform.cc \
spec/x86/platform_services.cc
spec/x86/platform.cc
vpath io_port_session_component.cc $(BASE_DIR)/src/core/spec/x86
vpath io_port_session_support.cc $(BASE_DIR)/src/core/spec/x86
vpath platform_services.cc $(BASE_DIR)/src/core/spec/x86
include $(REP_DIR)/lib/mk/core-foc.inc

2
repos/base-foc/lib/mk/spec/x86_32/syscall-foc.mk
View File

@ -4,7 +4,7 @@ L4_INC_TARGETS := x86/l4/sys x86/l4f/l4/sys x86/l4/vcpu
CC_OPT += -Iinclude/x86
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/pc-build/bin/x86_586
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/x86_586
include $(REP_DIR)/lib/mk/spec/x86/syscall-foc.inc

2
repos/base-foc/lib/mk/spec/x86_64/syscall-foc.mk
View File

@ -4,6 +4,6 @@ L4_INC_TARGETS := amd64/l4/sys amd64/l4f/l4/sys amd64/l4/vcpu
CC_OPT += -Iinclude/amd64
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/pc-build/bin/amd64_K8
L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/build/bin/amd64_K8
include $(REP_DIR)/lib/mk/spec/x86/syscall-foc.inc

11
repos/base-foc/lib/mk/syscall-foc.inc
View File

@ -6,9 +6,8 @@
# userland (L4re) that comes with Fiasco.OC.
#
BOARD ?= unknown
L4_SRC_DIR := $(call select_from_ports,foc)/src/kernel/foc
L4_BUILD_DIR := $(shell pwd)/$(BOARD)-build
L4_BUILD_DIR := $(shell pwd)/build
#
# Create mirror for architecture-specific L4sys header files
@ -68,14 +67,14 @@ $(SRC_S) $(SRC_C) : $(PKG_TAGS)
# included in the depot's base-foc binary archives.
#
ifneq ($(INSTALL_DIR),)
all: $(INSTALL_DIR)/sigma0-foc-$(BOARD) $(INSTALL_DIR)/bootstrap-foc-$(BOARD)
all: $(INSTALL_DIR)/sigma0-foc $(INSTALL_DIR)/bootstrap-foc
$(INSTALL_DIR)/sigma0-foc-$(BOARD) $(INSTALL_DIR)/bootstrap-foc-$(BOARD): $(PKG_TAGS)
$(INSTALL_DIR)/sigma0-foc $(INSTALL_DIR)/bootstrap-foc: $(PKG_TAGS)
$(INSTALL_DIR)/sigma0-foc-$(BOARD):
$(INSTALL_DIR)/sigma0-foc:
$(VERBOSE)ln -sf $(L4_BIN_DIR)/l4f/sigma0 $@
$(INSTALL_DIR)/bootstrap-foc-$(BOARD):
$(INSTALL_DIR)/bootstrap-foc:
$(VERBOSE)ln -sf $(L4_BIN_DIR)/bootstrap $@
endif

24
repos/base-foc/patches/0001-L4RE-Remove-moe-from-switch_ram_base-target.patch
View File

@ -1,24 +0,0 @@
From dde7b7a8de121c4569fdec32ada623146dd430dc Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Wed, 20 Feb 2013 12:30:53 +0100
Subject: [PATCH 01/15] L4RE: Remove 'moe' from 'switch_ram_base' target
---
l4/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/l4/Makefile b/l4/Makefile
index 61f55524..814d5fe3 100644
--- a/l4/Makefile
+++ b/l4/Makefile
@@ -480,7 +480,6 @@ define switch_ram_base_func
echo "# File semi-automatically generated by 'make switch_ram_base'" > $(OBJ_BASE)/Makeconf.ram_base; \
echo "RAM_BASE := $(1)" >> $(OBJ_BASE)/Makeconf.ram_base; \
PWD=$(PWD)/l4re-core/pkg/sigma0/server/src $(MAKE) RAM_BASE=$(1) -C pkg/l4re-core/sigma0/server/src; \
- PWD=$(PWD)/l4re-core/pkg/moe/server/src $(MAKE) RAM_BASE=$(1) -C pkg/l4re-core/moe/server/src; \
echo "RAM_BASE_SWITCH_OK := yes" >> $(OBJ_BASE)/Makeconf.ram_base
endef
--
2.11.0

42
repos/base-foc/patches/0002-FOC-change-l4_task_cap_equal-semantic.patch
View File

@ -1,42 +0,0 @@
From 1b5b4c951c4f5d5495ab6acb98c586b85d123295 Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Fri, 11 Jan 2013 17:14:26 +0100
Subject: [PATCH 02/15] FOC: change l4_task_cap_equal semantic
The syscall l4_task_cap_equal almost returns false although the referenced
kernel-objects are equal. This patch changes the semantic of the syscall so that
whenever two capabilities refering the same kernel-object are compared it will
return true. Please refer to the discussion of the following mail thread:
http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg05162.html
Was 'foc_caps_equal.patch'
---
kernel/fiasco/src/kern/task.cpp | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/fiasco/src/kern/task.cpp b/kernel/fiasco/src/kern/task.cpp
index 693da581..e30867e2 100644
--- a/kernel/fiasco/src/kern/task.cpp
+++ b/kernel/fiasco/src/kern/task.cpp
@@ -518,10 +518,15 @@ Task::sys_caps_equal(Syscall_frame *, Utcb *utcb)
if (obj_a.special() || obj_b.special())
return commit_result(obj_a.special_cap() == obj_b.special_cap());
- Obj_space::Capability c_a = lookup(obj_a.cap());
- Obj_space::Capability c_b = lookup(obj_b.cap());
+ Kobject_iface* ki_a = lookup(obj_a.cap()).obj();
+ Kobject_iface* ki_b = lookup(obj_b.cap()).obj();
- return commit_result(c_a == c_b);
+ if (!ki_b || !ki_a) return commit_result(0);
+
+ Mword o_a = ki_a->obj_id();
+ Mword o_b = ki_b->obj_id();
+
+ return commit_result(o_a == o_b);
}
PRIVATE inline NOEXPORT
--
2.11.0

43
repos/base-foc/patches/0003-Sigma0-raise-sigma0-s-priority-to-maximum.patch
View File

@ -1,43 +0,0 @@
From a7c9b9eaf75f9574c2ae80094df15942bf54c4ca Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Fri, 11 Jan 2013 17:38:28 +0100
Subject: [PATCH 03/15] Sigma0: raise sigma0's priority to maximum.
When sigma0 runs on a lower priority than the rest of the threads in the system
it might come to the point that while answering a page fault or I/O memory area
request the timeslice of the caller (core-pager) gets fully consumed. As long as
other threads are still executable and don't block sigma0 won't do progress
anymore, because it runs at the lowest priority. This commit simply sets
sigma0's priority to the highest in the system.
Was: 'sigma0_prio.patch'
---
l4/pkg/l4re-core/sigma0/server/src/init.cc | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/l4/pkg/l4re-core/sigma0/server/src/init.cc b/l4/pkg/l4re-core/sigma0/server/src/init.cc
index c2608ceb..ebd8d479 100644
--- a/l4/pkg/l4re-core/sigma0/server/src/init.cc
+++ b/l4/pkg/l4re-core/sigma0/server/src/init.cc
@@ -27,6 +27,7 @@
#include "ioports.h"
#include "mem_man_test.h"
#include <l4/sys/debugger.h>
+#include <l4/sys/scheduler.h>
/* started as the L4 sigma0 task from crt0.S */
@@ -61,6 +62,10 @@ init(l4_kernel_info_t *info)
l4_debugger_set_object_name(L4_BASE_FACTORY_CAP, "root factory");
l4_debugger_set_object_name(L4_BASE_THREAD_CAP, "sigma0");
+ l4_sched_param_t params = l4_sched_param(255);
+ l4_scheduler_run_thread(L4_BASE_SCHEDULER_CAP, L4_BASE_THREAD_CAP, &params);
+
+
Page_alloc_base::init();
init_memory(info);
--
2.11.0

30
repos/base-foc/patches/0005-FOC-Increase-name-buffer-of-JDB-to-32K.patch
View File

@ -1,30 +0,0 @@
From 09f403d2eb2c7dc089796f58c9a1f359fdea2c35 Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Fri, 11 Jan 2013 17:34:06 +0100
Subject: [PATCH 05/15] FOC: Increase name buffer of JDB to 32K
Increase the size of the JDB kernel object names buffer. The original size was
too small for some Genode scenarios and caused missing thread names in the
kernel debugger thread list.
Was: 'jdb_kobject_names.patch'
---
kernel/fiasco/src/jdb/jdb_kobject_names.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fiasco/src/jdb/jdb_kobject_names.cpp b/kernel/fiasco/src/jdb/jdb_kobject_names.cpp
index 5b5adbad..d65fbd56 100644
--- a/kernel/fiasco/src/jdb/jdb_kobject_names.cpp
+++ b/kernel/fiasco/src/jdb/jdb_kobject_names.cpp
@@ -43,7 +43,7 @@ IMPLEMENTATION:
enum
{
- Name_buffer_size = 8192,
+ Name_buffer_size = 4*8192,
Name_entries = Name_buffer_size / sizeof(Jdb_kobject_name),
};
--
2.11.0

34
repos/base-foc/patches/0006-FOC-adjust-panda-timer-to-version-A6.patch
View File

@ -1,34 +0,0 @@
From 8ce1c02d02fa8a9e50124e3237c2e01ae73c248c Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Wed, 8 Mar 2017 16:58:27 +0100
Subject: [PATCH 06/15] FOC: adjust panda timer to version A6
A6 runs at 800 not 700 MHz (as the ES2 does) when bootstrapped by U-boot
(thanks to mstein)
---
.../fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp b/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
index 72ef9b90..c0aef990 100644
--- a/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
+++ b/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
@@ -4,5 +4,13 @@ INTERFACE [arm && mptimer && pf_omap4_pandaboard]:
EXTENSION class Timer
{
private:
- static Mword interval() { return 499999; }
+ static Mword interval()
+ {
+ /*
+ * This is only valid for Panda A6, as we run it at our offices. For A6
+ * U-Boot will clock the board at 800 MHz leading to a 400 MHz private timer
+ * tick.
+ */
+ return 399999;
+ }
};
--
2.11.0

28
repos/base-foc/patches/0007-L4RE-fix-x86-syscall-bindings-to-use-in-C-namespace.patch
View File

@ -1,28 +0,0 @@
From 266d89b9a54653bfe5cae2744ab72cf83ec13d6d Mon Sep 17 00:00:00 2001
From: Stefan Kalkowski <stefan.kalkowski@genode-labs.com>
Date: Wed, 3 May 2017 15:01:31 +0200
Subject: [PATCH 07/15] L4RE: fix x86 syscall bindings to use in C++ namespace
---
l4/pkg/l4re-core/l4sys/include/ARCH-x86/ipc-invoke.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/l4/pkg/l4re-core/l4sys/include/ARCH-x86/ipc-invoke.h b/l4/pkg/l4re-core/l4sys/include/ARCH-x86/ipc-invoke.h
index 6e635697..18ef1f6d 100644
--- a/l4/pkg/l4re-core/l4sys/include/ARCH-x86/ipc-invoke.h
+++ b/l4/pkg/l4re-core/l4sys/include/ARCH-x86/ipc-invoke.h
@@ -48,7 +48,11 @@
#if 1
#ifdef __PIC__
+#ifndef __cplusplus
extern void (*__l4sys_invoke_indirect)(void);
+#else
+extern "C" void (*__l4sys_invoke_indirect)(void);
+#endif
#endif
# define IPC_SYSENTER "# indirect sys invoke \n\t" \
"call *%[func] \n\t"
--
2.11.0

35
repos/base-foc/patches/0009-Bootstrap-read-out-comport-on-x86-from-BDA-area.patch
View File

@ -1,35 +0,0 @@
From 2cf8f6f608aa4ade16402c10751aaa7d90b994f8 Mon Sep 17 00:00:00 2001
From: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Date: Mon, 10 Jun 2013 10:30:49 +0200
Subject: [PATCH 09/15] Bootstrap: read out comport on x86 from BDA area
With this patch the comport are tried to read out from the BIOS Data Area
on x86 machines. The BDA Area are part of the first physical page and may
contain the non-default io ports of the comport.
When used together with 'bender' from the 'morbo' toolchain, even serial PCI
cards (also Intel's AMT Serial Over Line adapter) are detected automatically.
---
l4/pkg/bootstrap/server/src/platform/x86_pc-base.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/l4/pkg/bootstrap/server/src/platform/x86_pc-base.h b/l4/pkg/bootstrap/server/src/platform/x86_pc-base.h
index c3e8c12f..95579c09 100644
--- a/l4/pkg/bootstrap/server/src/platform/x86_pc-base.h
+++ b/l4/pkg/bootstrap/server/src/platform/x86_pc-base.h
@@ -957,7 +957,11 @@ public:
}
else if (comport == -1)
{
- legacy_uart(1, comirq, &board);
+ /* try to read Bios Data Area (BDA) to get comport information */
+ unsigned short comport_count = (*((unsigned short *)0x410) >> 9) & 0x7;
+ if (comport_count) comport = *((unsigned short *)0x400), comirq, &board;
+ else comport = 1;
+ legacy_uart(comport, comirq, &board);
comport = 0;
}
else
--
2.11.0

47
repos/base-foc/patches/0010-L4RE-get-rid-of-__builtin_strlen-usage.patch
View File

@ -1,47 +0,0 @@
From f3d44f2a42763bbcba7085f3005ee8a36dbf23e9 Mon Sep 17 00:00:00 2001
From: Stefan Kalkowski <stefan.kalkowski@genode-labs.com>
Date: Tue, 30 May 2017 09:03:57 +0200
Subject: [PATCH 10/15] L4RE: get rid of __builtin_strlen usage
---
l4/pkg/l4re-core/l4sys/include/kdebug.h | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/l4/pkg/l4re-core/l4sys/include/kdebug.h b/l4/pkg/l4re-core/l4sys/include/kdebug.h
index cfb17464..64ee9900 100644
--- a/l4/pkg/l4re-core/l4sys/include/kdebug.h
+++ b/l4/pkg/l4re-core/l4sys/include/kdebug.h
@@ -133,6 +133,13 @@ __kdebug_op_1(unsigned op, l4_mword_t val) L4_NOTHROW
return res;
}
+L4_INLINE unsigned __kdebug_strlen(char const * s)
+{
+ unsigned r = 0;
+ for (; s && *s; s++, r++);
+ return r;
+}
+
L4_INLINE void enter_kdebug(char const *text) L4_NOTHROW
{
/* special case, enter without any text and use of the UTCB */
@@ -144,14 +151,14 @@ L4_INLINE void enter_kdebug(char const *text) L4_NOTHROW
return;
}
- __kdebug_text(L4_KDEBUG_ENTER, text, __builtin_strlen(text));
+ __kdebug_text(L4_KDEBUG_ENTER, text, __kdebug_strlen(text));
}
L4_INLINE void outnstring(char const *text, unsigned len)
{ __kdebug_text(L4_KDEBUG_OUTNSTRING, text, len); }
L4_INLINE void outstring(char const *text)
-{ outnstring(text, __builtin_strlen(text)); }
+{ outnstring(text, __kdebug_strlen(text)); }
L4_INLINE void outchar(char c)
--
2.11.0

45
repos/base-foc/patches/0011-Ex_regs-Change-user_flags.patch
View File

@ -1,45 +0,0 @@
From b9323143eead13223b658c92010c923c959e2159 Mon Sep 17 00:00:00 2001
From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
Date: Fri, 11 Jan 2013 17:27:42 +0100
Subject: [PATCH 11/15] Ex_regs: Change 'user_flags'
Return true if thread is ready.
Was: 'foc_exregs_ret_state.patch'
---
kernel/fiasco/src/kern/arm/thread-arm.cpp | 2 +-
kernel/fiasco/src/kern/ia32/thread-ia32.cpp | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/fiasco/src/kern/arm/thread-arm.cpp b/kernel/fiasco/src/kern/arm/thread-arm.cpp
index 82b62998..7bce193b 100644
--- a/kernel/fiasco/src/kern/arm/thread-arm.cpp
+++ b/kernel/fiasco/src/kern/arm/thread-arm.cpp
@@ -325,7 +325,7 @@ Thread::user_sp(Mword sp)
IMPLEMENT inline
Mword
Thread::user_flags() const
-{ return 0; }
+{ return state() & Thread_ready; }
PUBLIC inline NEEDS ["trap_state.h"]
int
diff --git a/kernel/fiasco/src/kern/ia32/thread-ia32.cpp b/kernel/fiasco/src/kern/ia32/thread-ia32.cpp
index 3777821d..62a561a9 100644
--- a/kernel/fiasco/src/kern/ia32/thread-ia32.cpp
+++ b/kernel/fiasco/src/kern/ia32/thread-ia32.cpp
@@ -80,7 +80,10 @@ Thread::user_ip() const
IMPLEMENT inline
Mword
Thread::user_flags() const
-{ return regs()->flags(); }
+{
+ // pass thread-ready state in carry flag (Thread_ready is bit 0)
+ return (regs()->flags() & ~Thread_ready) | (state() & Thread_ready);
+}
PRIVATE static inline
Mword
--
2.11.0

29
repos/base-foc/patches/0012-Flush-the-TLB-after-idle-operation.patch
View File

@ -1,29 +0,0 @@
From 43cd446fe9bcba67a7d7312b14004e9063343a89 Mon Sep 17 00:00:00 2001
From: Christian Prochaska <christian.prochaska@genode-labs.com>
Date: Wed, 28 Aug 2013 19:53:23 +0200
Subject: [PATCH 12/15] Flush the TLB after idle operation
While a CPU executes the idle thread, it receives no cross-CPU TLB flush
requests. Therefore, the TLB needs to get flushed when leaving the idle
thread to compensate for any missed flush requests.
Fixes ssumpf/foc#9.
---
kernel/fiasco/src/kern/kernel_thread.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/fiasco/src/kern/kernel_thread.cpp b/kernel/fiasco/src/kern/kernel_thread.cpp
index 348fde9c..7e4a0d31 100644
--- a/kernel/fiasco/src/kern/kernel_thread.cpp
+++ b/kernel/fiasco/src/kern/kernel_thread.cpp
@@ -182,6 +182,7 @@ Kernel_thread::idle_op()
arch_tickless_idle(cpu);
Mem_space::enable_tlb(cpu);
+ Mem_unit::tlb_flush();
Rcu::leave_idle(cpu);
Timer_tick::enable(cpu);
}
--
2.11.0

35
repos/base-foc/patches/0014-Always-enable-user-mode-access-for-performance-monit.patch
View File

@ -1,35 +0,0 @@
From b74e427801f045578c401a140a8e66404bb3ff19 Mon Sep 17 00:00:00 2001
From: Christian Prochaska <christian.prochaska@genode-labs.com>
Date: Tue, 12 Feb 2019 19:54:06 +0100
Subject: [PATCH 14/15] Always enable user mode access for performance monitors
QEMU implements the cycle count register read by
'Genode::Trace::timestamp()', but does not report a supported debug model
version for Cortex-A9.
---
kernel/fiasco/src/kern/arm/perf_cnt-arm.cpp | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/fiasco/src/kern/arm/perf_cnt-arm.cpp b/kernel/fiasco/src/kern/arm/perf_cnt-arm.cpp
index b7d6a935..bff54286 100644
--- a/kernel/fiasco/src/kern/arm/perf_cnt-arm.cpp
+++ b/kernel/fiasco/src/kern/arm/perf_cnt-arm.cpp
@@ -190,8 +190,13 @@ PUBLIC static FIASCO_INIT_CPU
void
Perf_cnt::init_cpu()
{
- if (!is_avail())
- return;
+ /*
+ * QEMU implements the cycle count register read by
+ * 'Genode::Trace::timestamp()', but does not report a supported debug model
+ * version for Cortex-A9.
+ */
+ //if (!is_avail())
+ //return;
_nr_counters = (pmcr() >> 11) & 0x1f;
--
2.11.0

29
repos/base-foc/patches/0015-VMX-disable-event-injection-if-requested-by-VMM.patch
View File

@ -1,29 +0,0 @@
From a8411389dffc3c55dc5809d2e849b3afac94ee5d Mon Sep 17 00:00:00 2001
From: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Date: Fri, 12 Apr 2019 13:53:24 +0200
Subject: [PATCH 15/15] VMX: disable event injection if requested by VMM
---
kernel/fiasco/src/kern/ia32/vm_vmx.cpp | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/fiasco/src/kern/ia32/vm_vmx.cpp b/kernel/fiasco/src/kern/ia32/vm_vmx.cpp
index 7de4110f..44483b48 100644
--- a/kernel/fiasco/src/kern/ia32/vm_vmx.cpp
+++ b/kernel/fiasco/src/kern/ia32/vm_vmx.cpp
@@ -306,6 +306,12 @@ Vm_vmx_t<X>::load_guest_state(Cpu_number cpu, void *src)
Vmx::vmwrite(Vmx::F_entry_int_info, irq_info);
}
+ else
+ {
+ // switch off event injection if requested but still pending in hw
+ if (Vmx::vmread<Mword>(Vmx::F_entry_int_info) & (1UL << 31))
+ Vmx::vmwrite(Vmx::F_entry_int_info, irq_info);
+ }
// hm, we have to check for sanitizing the cr0 and cr4 shadow stuff
load(0x6000, 0x6006, src);
--
2.11.0

24
repos/base-foc/patches/0016-svm-provide-cr0-to-guest-if-np-enabled.patch
View File

@ -1,24 +0,0 @@
From 518f0ab153ab528fb78c3643d490c2cbefe0dd80 Mon Sep 17 00:00:00 2001
From: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Date: Sat, 4 May 2019 19:19:22 +0200
Subject: [PATCH 16/17] svm: provide cr0 to guest if np enabled
---
kernel/fiasco/src/kern/ia32/vm_svm.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/fiasco/src/kern/ia32/vm_svm.cpp b/kernel/fiasco/src/kern/ia32/vm_svm.cpp
index 9960a830..1330e36a 100644
--- a/kernel/fiasco/src/kern/ia32/vm_svm.cpp
+++ b/kernel/fiasco/src/kern/ia32/vm_svm.cpp
@@ -656,6 +656,7 @@ Vm_svm::do_resume_vcpu(Context *ctxt, Vcpu_state *vcpu, Vmcb *vmcb_s)
if (EXPECT_TRUE(kernel_vmcb_s->np_enabled()))
{
+ vmcb_s->state_save_area.cr0 = kernel_vmcb_s->state_save_area.cr0;
vmcb_s->state_save_area.cr3 = kernel_vmcb_s->state_save_area.cr3;
vmcb_s->state_save_area.cr4 = kernel_vmcb_s->state_save_area.cr4;
}
--
2.11.0

25
repos/base-foc/patches/0017-svm-avoid-forceful-exit-on-task-switch.patch
View File

@ -1,25 +0,0 @@
From 45bf2c699552d1e2891d322bea479d95f8c93d02 Mon Sep 17 00:00:00 2001
From: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Date: Sat, 4 May 2019 19:20:41 +0200
Subject: [PATCH 17/17] svm: avoid forceful exit on task switch
---
kernel/fiasco/src/kern/ia32/vm_svm.cpp | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/fiasco/src/kern/ia32/vm_svm.cpp b/kernel/fiasco/src/kern/ia32/vm_svm.cpp
index 1330e36a..9ac5b87b 100644
--- a/kernel/fiasco/src/kern/ia32/vm_svm.cpp
+++ b/kernel/fiasco/src/kern/ia32/vm_svm.cpp
@@ -486,8 +486,6 @@ Vm_svm::do_resume_vcpu(Context *ctxt, Vcpu_state *vcpu, Vmcb *vmcb_s)
kernel_vmcb_s->control_area.intercept_instruction0 |= (1 << 22);
// intercept HLT
kernel_vmcb_s->control_area.intercept_instruction0 |= (1 << 24);
- // intercept task switch
- kernel_vmcb_s->control_area.intercept_instruction0 |= (1 << 29);
// intercept shutdown
kernel_vmcb_s->control_area.intercept_instruction0 |= (1 << 31);
// intercept MONITOR/MWAIT
--
2.11.0

2
repos/base-foc/ports/foc.hash
View File

@ -1 +1 @@
91ca3363690c5b9c992a110375242f5d426a6848
1367e8214fa7c02682a97bbb3b375b0d792f4fed

46
repos/base-foc/ports/foc.port
View File

@ -1,40 +1,6 @@
LICENSE := GPLv2
VERSION := git
DOWNLOADS := mk.git foc.git l4re-core.git drivers-frst.git bootstrap.git
URL(mk) := https://github.com/kernkonzept/mk.git
REV(mk) := dc4501f9cc3910c2038e0703ffdcd9062d2610e1
DIR(mk) := src/kernel/foc/l4
URL(foc) := https://github.com/kernkonzept/fiasco.git
REV(foc) := 4367c50b1df878604b9833d4b41ae311d6e12e03
DIR(foc) := src/kernel/foc/kernel/fiasco
URL(l4re-core) := https://github.com/kernkonzept/l4re-core.git
REV(l4re-core) := fe794038e477e5a54762126689483c0e91a177a8
DIR(l4re-core) := src/kernel/foc/l4/pkg/l4re-core
URL(drivers-frst) := https://github.com/kernkonzept/drivers-frst.git
REV(drivers-frst) := ce2d7d33294cb7034a4226912463b24f6ffe1bc7
DIR(drivers-frst) := src/kernel/foc/l4/pkg/drivers-frst
URL(bootstrap) := https://github.com/kernkonzept/bootstrap.git
REV(bootstrap) := 36500c1253f46f527098febd4da7cbc9d0e2c218
DIR(bootstrap) := src/kernel/foc/l4/pkg/bootstrap
PATCHES := $(addprefix patches/,$(notdir $(wildcard $(REP_DIR)/patches/*.patch)))
PATCH_OPT(patches/0001-L4RE-Remove-moe-from-switch_ram_base-target.patch) := -p2 -d${DIR(mk)}
PATCH_OPT(patches/0002-FOC-change-l4_task_cap_equal-semantic.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0003-Sigma0-raise-sigma0-s-priority-to-maximum.patch) := -p4 -d${DIR(l4re-core)}
PATCH_OPT(patches/0005-FOC-Increase-name-buffer-of-JDB-to-32K.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0006-FOC-adjust-panda-timer-to-version-A6.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0007-L4RE-fix-x86-syscall-bindings-to-use-in-C-namespace.patch) := -p4 -d${DIR(l4re-core)}
PATCH_OPT(patches/0009-Bootstrap-read-out-comport-on-x86-from-BDA-area.patch) := -p4 -d${DIR(bootstrap)}
PATCH_OPT(patches/0010-L4RE-get-rid-of-__builtin_strlen-usage.patch) := -p4 -d${DIR(l4re-core)}
PATCH_OPT(patches/0011-Ex_regs-Change-user_flags.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0012-Flush-the-TLB-after-idle-operation.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0014-Always-enable-user-mode-access-for-performance-monit.patch):= -p3 -d${DIR(foc)}
PATCH_OPT(patches/0015-VMX-disable-event-injection-if-requested-by-VMM.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0016-svm-provide-cr0-to-guest-if-np-enabled.patch) := -p3 -d${DIR(foc)}
PATCH_OPT(patches/0017-svm-avoid-forceful-exit-on-task-switch.patch) := -p3 -d${DIR(foc)}
LICENSE := GPLv2
VERSION := git
DOWNLOADS := foc.git
URL(foc) := https://github.com/cproc/foc.git
REV(foc) := b74e427801f045578c401a140a8e66404bb3ff19
DIR(foc) := src/kernel/foc

0
repos/base-foc/recipes/src/base-foc-imx7d_sabre/README → repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/README
View File

7
repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/content.mk Normal file
View File

@ -0,0 +1,7 @@
RECIPE_DIR := $(REP_DIR)/recipes/src/base-foc-pbxa9
include $(GENODE_DIR)/repos/base-foc/recipes/src/base-foc_content.inc
content: enable_board_spec
enable_board_spec: etc/specs.conf
echo "SPECS += pbxa9" >> etc/specs.conf

1
repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/hash Normal file
View File

@ -0,0 +1 @@
2018-11-14 778d83a4be78dcd6d1e4d45f1ca103def7b298a5

0
repos/base-foc/recipes/src/base-foc-imx7d_sabre/used_apis → repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/used_apis
View File

6
repos/base-foc/recipes/src/base-foc-arndale/content.mk
View File

@ -1,3 +1,7 @@
BOARD := arndale
RECIPE_DIR := $(REP_DIR)/recipes/src/base-foc-arndale
include $(GENODE_DIR)/repos/base-foc/recipes/src/base-foc_content.inc
content: enable_board_spec
enable_board_spec: etc/specs.conf
echo "SPECS += arndale" >> etc/specs.conf

2
repos/base-foc/recipes/src/base-foc-arndale/hash
View File

@ -1 +1 @@
2019-11-25 9a459c4fd8a907810d91041751affcf3e119fcb1
2019-02-25 a1f619a0e6559e000f3053b8160f369ffa408f21

6
repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/content.mk
View File

@ -1,3 +1,7 @@
BOARD := imx6q_sabrelite
RECIPE_DIR := $(REP_DIR)/recipes/src/base-foc-imx6q_sabrelite
include $(GENODE_DIR)/repos/base-foc/recipes/src/base-foc_content.inc
content: enable_board_spec
enable_board_spec: etc/specs.conf
echo "SPECS += imx6q_sabrelite" >> etc/specs.conf

2
repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash
View File

@ -1 +1 @@
2019-11-25 d8ff4913b8aa117aef77a7918bc82808e38a4ee7
2019-02-25 7e77af2966855ccf2a86c6bdd970906307bb99b7

Some files were not shown because too many files have changed in this diff Show More