In contrast to most information of init's state reports, which can be
monitored at a relatively low rate (like 2 seconds in Sculpt's runtime),
resource requests call for an immediate response by the consumer of the
report. Otherwise the requesting child stays unnecessarily blocked until
the next rate-limited state report is due. This patch adds a fast lane
for such low-latency state updates to init.
Do not send nor buffer packets at interfaces with link state "down". This
prevents that packets that were routed to one network (allowed to see them),
due to a sudden link down/up, are leaked to another network that is not
allowed to see them.
When updating an interface in the NIC router to a new configuration and
the domain name of the interface has not changed but the domain
disappeared, the NIC router did not detach from the old domain correctly
which led to broken remnants of interface state objects (like connection
states).
Adapt the nic_router_uplinks run script to work with the fix.
fs_report truncated the report file on construction of the report
session to mimic an "empty report". This prevented existing use cases
where the initial state was already written to the file system by other
means.
I doubt that use cases exist where the inital empty-report mimic is
needed and (if I'm wrong) there is still the race of the consumer
reading the file just before the report session is constructed.
Reporters that want to enforce an empty initial report should send it
explicitly.
Clients may wish to act on missing files. In any case the fs_rom
needs to reopen a watch handle when a file is deleted, and this
sort of change to the internal state machine is propelled by
client RPC requests.
Fix#2839
The new 'displays' report contains information about the used
framebuffer backend. It is issued when nitpicker has successfully passed
all initialization, in particular the connection to the framebuffer
driver. Hence, it can be taken as an indicator of whether the framebuffer
is available or not (e.g., caused by a faulty driver).
When re-configuring the NIC router, determine for each domain if at least one
interface stays with the domain. If a domain fullfills this and has a
dynamic IP config (received via a DHCP client), keep the IP config.
To achieve this, the following changes have been made to the existing NIC
router code:
* Split-up Interface::handle_config into three steps:
1) Determine for each interface if its domain can keep its IP config or
or if it has to mark it invalid. This must be done before (re-)attaching
any interface because during "attach" several decisions are made based on
the validity of the IP config of corresponding the domain.
(E.g. whether to participate in sending DHCP DISCOVERs {IP config
invalid} or whether to participate in sending pending ARP REQUESTs
{IP config valid} ).
2) Detach, attach, or re-attach each interface according to the
configuration. This must be done before re-considering the temporary
state objects of each interface because the latter might have effects
on the interfaces of remote domains which must then be in place already.
3) Re-consider temporary state objects of each interface. (E.g. transport
layer connection states)
* Re-work IP-config setter in a way that it works as follows:
1) If the old IP config is valid, let all local interfaces as well as remote
interfaces that depend on the IP config of the domain detach from the old
IP config.
2) Overwrite with new IP config
3) If the new IP config is valid, let all local interfaces as well as remote
interfaces that depend on the IP config of the domain attach to the new
IP config.
Issue #2815
The new attribute config.domain.label has effect only at the uplink
domain-tag. It determines which label the NIC router shall use when
requesting the NIC session for the uplink domain. If value of this
attribute changes at the uplink domain-tag, the NIC router closes and
re-requests the NIC session of the uplink with the new label.
Issue #2815
Set DHCP-DISCOVER retry timeout and DHCP-REQUEST retry timeout from 10
seconds to 2 seconds. This prevents problems with tests where the NIC
driver comes up slowly and the first packets of the DHCP client get
dropped.
Issue #2837
The Ethernet destination MAC address of a DHCP reply is not the same as the
DHCP client MAC address. The DHCP server of the NIC router did not take care
of this by now.
Issue #2837
When an environment session is provided by a async service such as a
sibling component, the session metadata must be preserved until end of
the lifetime of the session at the server has been acknowledged by the
server. Since the session meta data of env sessions are always part of
the 'Child' object, the destruction of this object must be deferred
until this point.
Merge the 'Packet_handle' into the 'Rom_root' and use an Id_space to
match File_system handles to session objects rather than a list. This
avoids the need to override 'Root_component::_destroy_session'.
Fix#2833
When exhausted of RAM quota while starting children, init used to throw
an uncaught 'Out_of_ram' exception as this condition was considered
fatal. However, this behavior is undesired when init is used in a highly
dynamic yet long-running fashion like sculpt's runtime subsystem. This
change keeps init running despite the error condition, giving the user
the chance to relieve the resource pressure.
The 'View_stack::draw_rec' method limited the redraw to parts of the
view that were explicitly marked as dirty. This does not produce the
desired result when stacking multiple transparent views. Here, the
background views must be drawn regardless of whether they are marked as
dirty or not.
The file may also be changed by other components, so a open-close cycle
for write() is more robust. For example, Vim removes the original file
and recreates with the new content.
The '_active_mode' must not be changed at any time except when the
client asks for the 'Framebuffer::mode'. Otherwise, the dimensions of
dataspace used by the client is not always consistent with the mode
information as gathered by the client.
Normally, the NIC sessions are independent from the domain tags.
However, by now the uplink session, in contrast to the sessions of the
other domains, is still not a server but a client. This means that only
the NIC router itself can decide when to open and close uplink sessions
and how many. Thus, with this commit, we break with the pattern that
session lifetime is independent from domains by letting the NIC router
create the uplink session when the uplink domain appears and close the
session when the domain disappears.
Fixes#2795
Since the router MAC is allocated like the donwlink MACs it can't happen
anymore that these MACs clash, for instance due to nested routers. Thus,
the range of the MAC allocators of nested routers must not be exclusive
anymore which deprecates the 'mac_first' configuration attribute.
Issue #2795
Allocate a virtual MAC address at runtime that is used as router
Ethernet-identity for all downlink domains. This makes the downlink
domains independent from the uplink session.
Issue #2795
The old MAC allocator had several drawbacks:
* the address base was a public static that could and must have been written
directly from outside the class
* the in-use-flag array was based on unsigned values consuming 4 bytes each
for only one bit of information
* it was a public header that we actually don't want to expose to all
components but only to the few networking components
* it used the not-so-safe bit notation for integer members of GCC
The new version fixes all these drawbacks.
Issue #2795
Instead of handing over the maximum available size to the packet data
accessors, hand over a size guard that keeps track of the packets
boundaries.
This commit also moves the size-guard utilitiy header of Ping and NIC
Router to the include/net directory making it a part of the net library.
It applies the new approach to all net-lib users in the basic repositories.
Ping looses its configurability regarding the ICMP data size as this would
require an additional method in the size guard which would be used only by
Ping.
The size guard was also re-worked to fit the fact that a packet can
bring a tail as well as a header (Ethernet).
Issue #2788
