Since dde_linux now contains the port of the Linux IP stack available for all
Genode base-* platforms move the repository out of drivers_arm and drivers_x86
build.conf to the optional build.conf (available to all platforms).
To support components, which implement the block session's server side
rpc object, and which doesn't write data to their device backend immediately,
an additional synchronization call is needed. Thereby, clients like for
instance a file system can tell these components, when a synchronization is
required.
Ref #113
Issue #949
Related to issue #808 - one way to nearly double the maximum VM size for
VMs on 32bit Genode/Nova host if decreased performance is acceptable.
To ease the creation of custom virtual machine monitors on top of
NOVA, this patch moves generic utilities from vancouver resp. seoul to the
public include location 'ports/include/vmm'. As a nice side effect,
this change simplifies 'vancouver/main.cc'.
Issue #949
The platform driver is used to access the features provided by the
Videocore mboxes, i.e., power configuration and framebuffer setup. The
framebuffer driver uses the platform interface to setup a screen mode of
1024x768.
At the current stage, the USB HID and storage drivers are prinicpally
working but not stable. If interrupts are not processed fast enough,
devices will get sporadically disconnected.
The USB host-controller driver is not part of the normal Linux kernel.
For this reason, we need to download it separately. There exists a
'prepare_rpi' rule in the 'dde_linux/Makefile' to automate this process.
This patch principally allows to install symlinks to out-of-Linux tree
drivers into the contrib directory. Those files are then considered for
the 'lx_emul.h' symlink procedure. Is useful as a temporary mechanism
while developing the rpi USB driver.
When saving/resuming translation table base registers, and data fault register
a VMM is able to translate the VM's virtual addresses, and to analyse aborts
it has generated.
Every thread receives a startup message from its creator through the initial
state of its userland thread-context. The thread-startup code remembers the
kernel name of the new thread by reading this message before the userland
thread-context gets polluted. This way, Kernel::current_thread_id becomes
unnecessary.
fix#953
Don't set priority and label in platform thread and then communicate this
core object via Kernel::new_thread but communicate priority and label directly.
This way kernel doesn't need to know anymore what a platform thread is.
ref #953
Instead of writing initial thread context to the platform-thread members
and then communicating this core object to kernel, core calls
Kernel::access_thread_regs first to initialize thread context and then
Kernel::start_thread without a platform-thread pointer. This way
the frontend as well as the backend of Kernel::start_thread loose
complexity and it is a first step to remove platform thread from the
vocabulary of the kernel.
ref #953
