This commit generalizes the bit array in 'base/util/bit_array.h',
so that it can be used in a statically, when the array size is known
at compile time, or dynamically. It uses the dynamic approach of the
bit array for a more generalized version of the packet allocator,
formerly only used by NIC session clients. The more generic packet
allocator is used by the block cache to circumvent the allocation
deadlock described in issue #1059.
Fixes#1059
Base libraries are already contained within ldso.lib.so. Remove unnecessary
filtering from 'dep_lib.mk', make ldso depend on base libs.
Issue #1017
Issue #989
For a main thread a thread object is created by the CRT0 before _main gets
called so that _main can already run in a generic environment that, e.g.,
catches stack overflows as a page-fault instead of corrupting the BSS.
Additionally dynamic programs have only one CRT0 - the one of the LDSO -
which does the initialization for both LDSO and program.
ref #989
This patch adds accessors to obtain the buffer of an attribute value,
which is useful to avoid the copying-out of such information by
maintaining pointers into the XML string as meta data.
This utility allows for the manual placement of objects without the need
to have a global placement new operation nor the need for type-specific
new operators.
Issue #989
The trace_fs server provides access to a Trace_session by using a
File_system_session as frontend.
Each trace subject is represented by a directory ('thread_name.subject')
that contains specific files ('active', 'cleanup', 'enable', 'events',
'buffer_size' and 'policy'), which are used to control the tracing
process of the thread as well as storing the content of its trace
buffer.
The tracing of a thread is only activated if there is a valid policy
installed and the intend to trace the subject was made clear by writing
'1' to the 'enable' file.
The tracing of a thread may be deactived by writing a '0' to the
'enable' file.
A policy may be changed by overwriting the currently used one. In this
case the old policy is replaced by the new policy and is automatically
utilize.
Writing a value to the 'buffer_size' file changes the appointed size of
the trace buffer. This value is only evaluted by reactivating the
tracing process.
The content of the trace buffer may be accessed by reading from the
'events' file. Throughout all tracing session new trace events are
appended to this file.
Nodes of UNTRACED subjects are kept as long as they do not change their
tracing state to DEAD. In this case all nodes are removed from the
file system. Subjects that were traced before and are now UNTRACED will
only be removed by writing '1' to the 'cleanup' file - even if they
are DEAD by now.
To use the trace_fs a config similar to the following may be used:
! <start name="trace_fs">
! <resource name="RAM" quantum="128M"/>
! <provides><service name="File_system"/></provides>
! <config>
! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" />
! </config>
! </start>
'interval' sets the periode in which the Trace_session is polled. The
time is given in milliseconds.
'subject_limit' speficies how many trace subject should by acquired at
most when the Trace_session is polled.
'trace_quota' is the amount of quota the trace_fs should use for the
Trace_session connection. The remaing amount of RAM quota will be used
for the actual nodes of the file system and the 'policy' as well as the
'events' files.
In addiition there are 'buffer_size' and 'buffer_size_limit' that define
the initial and the upper limit of the size of a trace buffer.
Tracing of parent processes or rather threads may be enabled by setting
'parent_levels' to a value greater than '0' (though this attribute is
available, the trace session component within core still lacks support
for it).
A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'.
Fixes#1049.
Until now, block drivers had to deal with a pointer to the client
session component, e.g.: to acknowledge block packets already processed.
When a session was closed, the driver object wasn't informed explicitly,
which leads to defensive programming, or lastly to a race-condition in
test-blk-srv. To prevent from this class of errors, the pointer is now
private to the generic block driver base class, and not accessible to
the concrete driver implementation. Moreover, the driver gets explicitly
informed when a session got invalidated.
Ref #113
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.
Fixes#113
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.
Related to #113
The new Attached_dataspace complements the existing Attached_*
utilities with a simple version that can be used with any kind of
dataspaces. It may be even useful as a common base type for the other
variants. For example, this patch simplifies Attached_rom_dataspace
and removes the Terminal::Client::Io_buffer.
This patch re-arranges nitpicker's graphics backend in a more modular
and expandable way. Generalized versions of the 'Canvas',
'Chunky_canvas', and 'Pixel_*' classes have been moved to
'os/include/util/' and 'os/include/os'. The only remaining parts that
are specific to nitpicker's needs are a few drawing functions, each
located in a distinct header at 'os/include/nitpicker_gfx/'.
This patch makes nitpicker's geometry utilities available for the use
by other programs. Thereby, the 'Point', 'Area', and 'Rect' classes
have become templates that take the coordinate type and distance type
as arguments.
Instead of, passing responsibility to manage and dissolve Signal_rpc_member
objects at a corresponding entrypoint to the user, hand over entrypoint's
reference to the constructor, and do it in the constructor resp. destructor
of the class.
Fixes#1022
Users of a File_system_session might want to force a file system
to flush or rather to synchronize its internal cache. A concret
default implementation is provided because not all file systems
maintain an internal cache and are not required to synchronize
caches.
Fixes#1007.
Make 'set_program_var' accessible outside of 'rtld.c'. Also, compile
dynamically linked programs with the '-fPIC' option. Doing not so,
yields to program-global symbols being put in the '.symtab' section
(which can be stripped) only. In order to get access to global
variables from the dynamic linker, the symbols need to reside within
the '.dynsym' section additionally. Hence the '-fPIC'.
ref #989fix#1002
* Increase entrypoint stack size for part_blk server,
since it crashes on 64 bit
* Consider packet alignment in bulk buffer size calculation of test-blk-cli
* allow to handle a maximum of packets in parallel
that fits free slots in the ack queue
* stop processing packets, when the driver can't handle
more requests in parallel, and resume packet handling,
when the driver is ready again
Instead of using an additional thread in each Session_component of a
block server, which uses the generic block component and driver classes,
replace it with signal dispatchers.
Ref #113
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
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.
This patch enables the recursive startup of launchpad instances, which
was not possible since the recent removal of launchpad's built-in
default configuration.
In general, requesting a dataspace from a server twice is no good
idea. The server might react in a unrecoverable fashion. E.g. the rom_fs
service always throws away the corresponding dataspace from the first call
of dataspace(), and constructs a new one.
This patch adds a 'gdb' command to 'cli_monitor', which makes it possible
to debug an application with GDB.
The command works similarly to the 'start' command, but instead of
starting the subsystem binary directly, an 'init' subsystem gets
started, which then starts 'terminal_crosslink', 'noux', GDB and
'gdb_monitor' (which starts the application binary as its target).
So, for the 'gdb' command to work, these additional components need to
be available, too. 'terminal_crosslink', 'noux', 'gdb_monitor' and the
file 'gdb_command_config' are expected to be ROM modules. The Noux GDB
client needs to get mounted at '/bin' in Noux and the target binaries need
to be available as ROM modules (loaded by 'gdb_monitor') and also mounted
at '/gdb' in Noux (loaded by the GDB client).
Additionally, the source code of the target application can be provided
at '/gdb/src/ in Noux. How the Noux mountings get established can
be configured in the 'gdb_command_config' file. The default configuration
in 'os/src/server/cli_monitor/gdb_command_config' mounts GDB from a tar
archive named 'gdb.tar', the GDB target binaries from a tar archive named
'gdb_target.tar' and the target source code from a tar archive named
'gdb_target-src.tar'.
The patch includes an 'expect' include file (ports/run/noux_gdb.inc)
which provides functions that help to create those tar files:
- 'create_gdb_tar' creates a tar archive for the 'gdb' client
- 'create_binary_tar' creates a tar archive for the target application
- 'create_source_tar' creates a tar archive for the source code of
the target application
- 'create_binary_and_source_tars' is a convenience wrapper for the previous
two functions
The patch also includes an example run script
(ports/run/noux_gdb_dynamic.run).
The 'gdb' command supports the following command line options:
- --ram: the initial RAM quota provided to the whole subsystem
(including the GDB-related components)
- --ram-limit: limit for expanding RAM quota
- --gdb-ram-preserve: the RAM quota that 'gdb_monitor' ahould preserve
for itself
Fixes#928.
When a child requests more ram resources, it gets blocked immediately when
the preservation limit is reached. Otherwise, it might happen that the
cli_monitor runs out of memory.
When a command was executed, it is necessary to check not only whether the
preservation limit of the ram quota is reached, but also whether new ram quota
is available (e.g.: consequence of the kill command), and children are waiting
for additional resources.
