Detect loops by walking hard-links at two different speeds and checking
for lapping. Tar link walking is no longer a recursive procedure.
Caught a loop created by GNU tar 1.29.
Fix#2611
This patch changes the depot layout such that each archive is
represented as a directory that contains the versions of the archive as
subdirectories.
Issue #2610
If a client decides to spontaneously send a DHCP DISCOVER again, even though
he has received a still valid IP config from the router, we don't want to
discard the DISCOVER like it was done before but discard the IP config
assignment and offer a new one.
Issue #2534
When this flag is set in the config tag, the NIC router will print a
short information to the log for each general state change of a domain.
This includes currently the IP-configuration state and the number of
connected NIC sessions. This a useful addition as the normal verbose
flag's purpose is a very deep insight into almost every activity in the
router, which is cool for debugging sophisticated problems but normally
floods the log and therefore discards this option for, e.g., desktop
systems. In such systems, the new verbosity is pretty discreet but
already gives a good hint on why packets may get dropped by the router
although the routing rules are correct.
Issue #2534
The run tool now by default checks configurations with target-specific
XML schemata. Each component may define a config schema file in its
target.mk via the CONFIG_XSD variable. When the run tool has checked an
configuration of an init instance, it additionally goes through the
start nodes of the config. For each start node it checks whether there
is an XSD file that matches. If so, the run tool also checks the config
of the start node (if existant). This is done recursively. I.e., also
the child configs of a sub-init of a sub-init of the top-level init
receive a config check.
Issue #2600
Channels, and therefore contexts, may be shared between children
causing corruption when a child is destroyed while another child still
uses the old context within the channel.
related to #2601
In the past, we had the lock of the context we found for the rest of the scope
of pending_signal. Now we use for_each_locked to find the context and the
lock is released as soon as we return from for_each_locked. Thus, we need to
lock the context again before returning it to avoid that the copy constructor
during the return reads values that are currently changing.
Fixes#2532
