This data structure allows the association of objects with IDs. IDs are
kept in an AVL tree. So in contrast to a bit allocator, the ID space can be
sparsely populated and does not need to be dimensioned. The lifetime of
an ID is bound to an 'Element' object, which relieves the programmer
from manually allocating/deallocating IDs for objects.
Issue #2120
We preserve lower RAM for device drivers with physical memory
constraints. If no physical RAM constraint exists, the allocations above
3G (32-bit) or 4G (64-bit) are preferred.
Limit the number of generations to 4 to prevent hitting the
socket-descriptor limit on Linux. Also, all possible configuration
parameters for bomb our now customizable in the run script and the
current config is logged by bomb master.
The 'connected_scan_interval' config attribute specifies the scan
interval in seconds. The commit also removes the deprecated ram_fs
component from the test run script.
VirtualBox mainly derives the initial link-state for its device models
from checking the <Adapter ... cable="true"/> attribute. Our backend
only propagates the current state of the Nic session if it receives a
link-state signal. This may lead to problems if a guest detects a link
up state when it is actually down and wants to use the interface. The
backend now queries the Nic session and sets the link-state accordingly
when it is constructed.
In case there is no link do not attempt to submit a packet to the packet
stream but return with an error so that upper layers can handle it.
Enable signals for network on poweron and not already during
construction. The network model may be not yet ready to process incoming
signals and data.
Fixes#2117.
This fixes a regression on Ubuntu 16.04 (resp. Linux systems with recent
kernel versions) and address-space randomization originating from an
uninitialized relocation base of 0.
This patch is a preparation of the forthcoming async parent interface.
Note that this patch increases the size of connection objects.
Furthermore it adds a diagnostic message whenever a connection fails.
Issue #2166
Because of the session-argument buffering added to 'Connection' objects
when changing the parent interface to be non-blocking, the
'Device_component' has grown in size from 1.5 KiB to 5 KiB. The slab
allocator was configured with a block size of 4 KiB. So it does not work
with the grown 'Device_component' size.
Once the transition to the new API is completed (when we can remove the
buffering of session arguments from the 'Connection' objects), we may
revert this change.
Issue #2120
Unfortunately, the volatile object does not inherit the noncopyable
attribute of the enclosed object. By making all volatile objects
noncopyable, we prevent the accidental copying of a noncopyable object
wrapped in a volatile object.
This feature is not compatible with the forthcoming nonblocking parent
interface. The patch removes the use of feature in all places except for
the components of the demo repository, which will under go a redesign
anyway.
Issue #2120
Issue #2165
Replace 'dump()' debug utilities within Allocator_avl with Output::print
equivalents, and use the new Avl_tree::for_each utility to simplify
the implementation.
Ref #2159
Instead of using a somewhat incomplete module_param_named() macro,
which will influence other drivers, patch the driver that requires
this treatment.
Fixes#2169Fixes#2155
This overload covers the common case for initializing a string from a
literal without employing the 'Output' mechanism. This way, such
strings can by constructed without calling virtual functions, which in
turn makes the 'String' usable for the 'init_rtld' phase of the dynamic
linker.
This patch fixes a race condition triggered by the thread test running
on Linux inside VirtualBox. The 'test_stack_alloc' sporadically produced
one of two errors: A segfault in the 'Thread::deinit_platform_thread' on
the attempt to access the 'native_thread' of the to-be-destructed thread
(this data structure is located on the thread's stack). Or, an error
message about a region conflict within the stack area.
The problem was that two instances of 'Region_map_mmap' issued a
sequence of munmap and mmap each. Even though each instance locked the
attach/detach operations, the lock was held per instance. In a situation
where two instances performed attach/detach operations in parallel, the
syscall sequences could interfere with each other.
In the test scenario, the two region-map instances are the test's
address space and the stack area. When creating a thread, the thread's
trace-control dataspace is attached at an arbitrary place (picked by
the Linux kernel) within the address space whereas the stack is attached
at the stack area. The problem is the following sequence:
Thread A wants to destruct a thread:
1. Remove stack from stack area
(issue unmap syscall)
2. Preserve virtual address range that was occupied from the stack
so that Linux won't use it
(issue mmap syscall)
Thread B wants to construct a thread:
1. Request trace-control dataspace from CPU session
2. Attach trace-control dataspace to address space at a location
picked by the Linux kernel
(issue mmap syscall)
The problem occurs when thread B's second step is executed in between
the steps 1 and 2 of thread A and the Linux kernel picks the
just-unmapped address as the location for the new trace-control mapping.
Now, the trace control dataspace is mapped at the virtual address that
was designated for the stack of the to-be-created thread, and the
attempt to map the real stack fails.
The patch fixes the problem by replacing the former region-map-local
locks by a component-global lock.
Furthermore, it cleans up core's implementation of the support function
for the region-map-mmap implementation, eliminating the temporary
unlocking of the region-map lock during RPC.
Prepared for internal test machine, which has 8 logical cores.
6 Win7 64bit VMs are started, each having 2 vCPUs, using the same image and
different overlays. Changes to the VM are written to the overlays of ram_fs
and dropped after the test.
lCPU 0 : Genode base system and drivers
lCPU 1-2: VM1 2 vCPUs
lCPU 2-3: VM2 "
lCPU 3-4: VM3 "
lCPU 4-5: VM4 "
lCPU 5-6: VM5 "
lCPU 6-7: VM6 "
Fixes#2143
