This patch enhances the 'Child' and 'Child_policy' with the ability to
separate the different steps of bootstrapping children. If the
'Child_policy::initiate_env_sessions()' returns false, the child's
environment sessions remain unrouted at construction time. This way,
child objects for many children can be initialized to a state that
allows the children to represent services for other children. Therefore,
session routing can be applied before any child executes.
At this stage, the environment RAM sessions of all children can be
created. Note that this step still has the limitation that RAM sessions
are generally expected to be provided by either the parent or a local
service.
Once all children are equipped with RAM, they can in principle receive
session-quota donations. Hence, all other environment sessions can now
be arbitrarily routed and initiated.
Once the environment of a child is complete, the child's process and
initial thread is created.
This patch improves the accounting for the backing store of
session-state meta data. Originally, the session state used to be
allocated by a child-local heap partition fed from the child's RAM
session. However, whereas this approach was somehow practical from a
runtime's (parent's) point of view, the child component could not count
on the quota in its own RAM session. I.e., if the Child::heap grew at
the parent side, the child's RAM session would magically diminish. This
caused two problems. First, it violates assumptions of components like
init that carefully manage their RAM resources (and giving most of them
away their children). Second, if a child transfers most of its RAM
session quota to another RAM session (like init does), the child's RAM
session may actually not allow the parent's heap to grow, which is a
very difficult error condition to deal with.
In the new version, there is no Child::heap anymore. Instead, session
states are allocated from the runtime's RAM session. In order to let
children pay for these costs, the parent withdraws the local session
costs from the session quota donated from the child when the child
initiates a new session. Hence, in principle, all components on the
route of the session request take a small bite from the session quota to
pay for their local book keeping
Consequently, the session quota that ends up at the server may become
depleted more or less, depending on the route. In the case where the
remaining quota is insufficient for the server, the server responds with
'QUOTA_EXCEEDED'. Since this behavior must generally be expected, this
patch equips the client-side 'Env::session' implementation with the
ability to re-issue session requests with successively growing quota
donations.
For several of core's services (ROM, IO_MEM, IRQ), the default session
quota has now increased by 2 KiB, which should suffice for session
requests to up to 3 hops as is the common case for most run scripts. For
longer routes, the retry mechanism as described above comes into effect.
For the time being, we give a warning whenever the server-side quota
check triggers the retry mechanism. The warning may eventually be
removed at a later stage.
This patch equips init with the ability to report its internal state in
the form of a "state" report. This feature can be enabled by placing a
'<report>' node in init's configuration.
The report node accepts the following arguments (with their default
values):
'delay_ms="100"': specifies the number of milliseconds to wait before
producing a new report. This way, many consecutive state changes -
like they occur during the startup - do not result in an overly
large number of reports but are merged into one final report.
'buffer="4K"': the maximum size of the report in bytes. The attribute
accepts the use of K/M/G as units.
'init_ram="no"': if enabled, the report will contain a '<ram>' node
with the memory stats of init.
'ids="no"': supplement the children in the report with unique IDs, which
may be used to infer the lifetime of children accross configuration
updates in the future;
'requested="no"': if enabled, the report will contain information about
all session requests initiated by the children.
'provided="no"': if enabled, the report will contain information about
all sessions provided by all servers.
'session_args="no"': level of detail of the session information
generated via 'requested' or 'provided'.
'child_ram="no"': if enabled, the report will contain a '<ram>' node
for each child based on the information obtained from the child's RAM
session.
Issue #2246
This method is a hook to enable a runtime to respond to state changes.
In particular, in init this hook is used to trigger the generation of a
new state report, if configured.
Furthermore, the patch introduces the 'generate_client_side_info' and
'generate_server_side_info' methods to the 'Session_state', which
generates an XML representation of the session states to appear in
reports produced by init.
Issue #2246
Normally, the platform driver helpers adapt the global run variables directly
via append. But the introduction of a more elegant run script style, that
incorporates dependent strings inline may be a good idea. Thus, we need the
backends of the helpers available as functions that return their string rather
than appending it.
The old interface still exists and uses the new interface as backend.
Ref #2193
The 'server_ip' and 'server_port' attributes for 'lxip/udp_client' and
'lwip/http_clnt' as well as the 'port' attribute for 'lxip/udp_echo' and
'lwip/http_srv_static' are not directly libc-related so they should not
live in the libc tag but in the config tag of the component.
Ref #2193
This patch enhances init with the support for rewriting session labels
in the target node of a matching session route. For example, a Noux
instance may have the following session route for the "home" file
system:
<route>
<service name="File_system" label="home">
<child name="rump_fs"/>
</service>
...
</route>
At the rump_fs file-system server, the label of the file-system session
will appear as "noux -> home". This information may be evaluated by
rump_fs's server-side policy. However, when renaming the noux instance,
we'd need to update this server-side policy.
With the new mechanism, the client's identity can be hidden from the
server. The label could instead represent the role of the client, or a
name of a physical resource. For example, the Noux route could be
changed to this:
<route>
<service name="File_system" label="home">
<child name="rump_fs" label="primary_user"/>
</service>
...
</route>
When the rump_fs receives the session request, it is presented with the
label "primary_user". The fact that the client is "noux" is not taken
into account for the server-side policy selection.
Issue #2248
The new return value of 'resolve_session_request' allows the child
policy to define the label used as the policy selector at the server.
Because this patch introduces the distinction of the child-provided
label from the label as presented to the server along with the session
request, the latter is now handled as a dedicated 'Session_state'
argument.
Issue #2248
This commit includes changes to the Nic::Session_component interface.
We now pass the entire env to the component instead of only ram, rm and
the ep because we need the env to open connections from within the
Session_component implemenation. So far only the cadence_gem driver
needs this, though.
Issue #2280.
Libc components cannot use regular calls to select() as this may suspend
their execution. In this case incoming RPCs will be deferred until
select() returns and the component returns to the entrypoint dispatch
loop. The Libc::Signal_handler solves this problem with a its select()
that either returns the currently ready file descriptors immediately or
calls the registered handler function during libc resume.
Now, the libc kernel supports to execute application code from all RPC
functions not only Component::construct(). This is enabled by the
Libc::with_libc() scope function.
This commit extends an easy-to-use mechanism to allow Genode component
code to enter/leave the libc application context. This is needed
whenever low-level component code (like signal handlers or RPC
functions) need to interact with potentially blocking libc I/O
functions.
Please note that this commit contains the API-level design only. The
actual context switching code 'execute_in_application_context' is
missing.
The socket file system can be configured in the "socket" attribute of
the libc config node like follows.
<vfs> <dir name="socket"> <fs/> </dir> </vfs>
<libc ... socket="/socket"/>
This configures the socket file system libc backend to access files in
"/socket" for socket operations.
There existed a race when 'wait_and_dispatch_one_signal' is called form
a RPC context, because the 'signal_proxy' or 'main' will block and the
signal semaphore, when the EP then calls 'wait_and_dispatch_one_signal',
the signal proxy is woken up ands sends an RPC to the EP, leading to a
dead lock if no further signal arrive, because the EP will then remain
blocked in the signal semaphore.
Therefore, for this case, the signal proxy will now perform a semaphore
up operation and does not perform an RPC if the EP is within
'wait_and_dispatch_one_signal'.
