The 'noux_bash.run' script has become able to present the user with an
interactive bash shell for executing various coreutils programs. It is
still pretty limited, i.e., the environment is not correctly passed to
child processes and pipes are not supported. But bash and coreutils are
operational.
Replace 'Reg_array' in 'Genode::Mmio' by 'Register_array' and 'Subreg'
in 'Genode::Register', 'Genode::Mmio::Register'and
'Genode::Mmio::Register_array' by 'Bitfield'.
Update and beautify comments in the according headers and test programs.
'Reg_array' contains items whose width can be the width of the register
storage type at a max. Nethertheless they can be smaller and iterate all
subregs that are covered by the item width. The array uses as much
successive instances of its storage type as needed.
The test 'run/util_mmio' also tests these new features heavily.
The run script 'run/util_mmio.run' runs a test over basic
functionalities of 'Mmio::Register' and 'Mmio::Register::Subreg'. The
test covers the functions 'read' and 'bits', 'set', 'clear' and 'get'.
Inline function in 'Mmio::Register::Subreg' whose definition otherwise
looks ugly.
To accommodate CPU registers, which have a structured layout but don't
depend on a region base address, this patch introduces the generic
'Genode::Register' and 'Genode::Subreg' to 'register.h'.
'Mmio::Register' and 'Mmio::Subreg' inherit from them.
The MMIO access framework consists of an abstraction for a contiguous
MMIO area with a base address set dynamically. Within this class 'Mmio'
are declarations for 'Register' and 'Subreg'. These two can be
parameterized statically via template parameters to create arbitrary
MMIO structures.
Whereas 'Register' relies to a POD like subregion of 'Mmio', 'Subreg'
relies to a MMIO region within a specific 'Register' and therefore is
smaller or equal then the storage type of its superior 'Register'.
Furthermore with 'Reg_array' and 'Subreg_array', there exists the
possibility to handle arrays of uniform contiguous registers or subregs
by index. 'Subreg_array' therefore abstracts from the width boundary of
its superior 'Register' and handles a steady distance between its
members in addition. Both also check array size limits.
Related to issue #69.
This patch removes the hardcoded parent cap for the new child by
introducing a facility called 'poke' similar to copy-to-user. This
change makes the fork mechanism kernel-agnostic. The 'noux_fork'
test works on L4/Fiasco, OKL4, NOVA, Fiasco.OC, and L4ka::Pistachio.
Linux is not supported yet.
If using the libc for Noux programs, the default implementation of these
functions cannot be used because they rely on a dedicated
timeout-scheduler thread. Noux programs, however, are expected to
contain only the main thread. By turning the functions into weak
symbols, the noux libc-plugin can provide custom implementations.
The resource virtualization layer has been extended to support sub RM
sessions because this feature is used by the dynamic linker. Currently,
the address space of the forking process is copied eagerly. However,
different dataspace types are treated differently. For example, only RAM
dataspaces are copied but no ROM dataspaces.
At the libc side, a setjmp/longjmp-based trampoline mechanism is used to
implement the continuation of the main thread inside the new process.
This procedure is also responsible for re-establishing the relationship
to the new process' parent as well as its Noux session.
This version is still in flux and has many rough edges. It is tied to
OKL4 for now.
The startup procedure of forked processes differs from Genode's
normal process creation by omitting all steps related to ELF loading
and the start of the main thread. To let the process lib support this
distinction, an invalid ELF-binary capability is handled as valid
argument now.
Because 'Noux::Child' implements several abstract Genode interfaces, the
'Genode::' prefix became almost ubiquitous, making the code harder to
read. By importing the 'Genode' namespace into the 'Noux' namespace,
this patch remedies this inconvenience.
To implement fork semantics, we need to customize the bootstrapping of
the newly created process, in particular the startup of the main thread.
The CPU session interface provides a suitable hook. By virtualizing the
CPU connection of the process to core, we can defer (and parametrize)
the startup of the main thread. Furthermore, this enables us to detect
illegal attempts by the Noux process to create threads in addition to
the main thread.
By letting Noux processes talk to service implementations local to the
Noux server, we can track RAM allocations and RM operations. This is
needed as a prerequisite to implement fork.
The 'Child' framework used to perform the transfer of session quota
using 'env()->ram_session()' as hard-wired reference account. When
locally virtualizing the RAM session supplied to the 'Child', this
policy does not work. When closing a session, core would try to transfer
session quota to the virtualized RAM service, which is of course not
possible. This patch makes the reference RAM session configable via the
'Child_policy' interface.
The new function 'Platform_env::reload_parent_cap' triggers a reload
of the parent capability and its respective resources. It is needed
during the bootstrap of a new process forked from an existing Noux
process.
This patch fixes printf errors caused by sign extension of values that
were supposed to be unsigned. Fixes#6. Also handles the case where
sizeof(long long) != sizeof(long).
This patch introduces the basic key handling required to browse through
a multi-page PDF document ([page-up] or [enter] -> next page,
[page-down] or [backspace] -> previous page).
This way, we can register a meaningful 'user_data' pointer to at the
'pdfapp_t' structure and avoid the use of singletons for 'Framebuffer'
and 'pdfapp'.
This version of MuPDF will use Genode's framebuffer session and input
session to display a PDF file. At the current stage, the program is
merely a skeleton that compiles and starts. Neither the actual rendering
not the response to user input are implemented. To try it out, there
is a ready-to-use run script at 'libports/run/mupdf.run'.
