RFC 5227 specifies randomized intervals to avoid that a large number of
hosts powered up at the same time send their message simultaneously.
Performing the conflict detection takes a variable time between 4 and 7
seconds from the beginning to the first announcement, as shown by the
following diagram where P indicates a probe and A an announcement:
```
time(s) 0 1 2 3 4 5 6 7 8 9
+---+---+---+---+---+---+---+---+---+
SHORTEST P P P A A
LONGEST P P P A A
```
The host can't use the address until the first announcement is sent. 7
seconds is a very long time on modern computers especially considering
the fact that the round-trip time on current LAN technologies is at most
few milliseconds. Section 2.2 of the RFC addresses this matter and hints
that a future standard will adjust those timeouts; however that standard
doesn't exist yet.
Make the timeout configurable via a new
"IPv4DuplicateAddressDetectionTimeoutSec=" option. The intervals defined
in the RFC are then scaled proportionally so that the duration of the
conflict detection takes at most the given value. Interval happening
after the first announcement are not scaled, as recommended by the RFC.
Also reduce the default value from 7s to 200ms, which is a more suitable
value for today's technology.
The original timeout of 7 seconds is very long for today's networks. Reduce it
to 200ms. Note that this change also affects IPv4 link-local addressing.
RFC 5227 specifies randomized intervals to avoid that a large number of hosts
powered up at the same time send their message simultaneously. Performing the
conflict detection takes a variable time between 4 and 7 seconds from the
beginning to the first announcement, as shown by the following diagram where P
indicates a probe and A an announcement:
time(s) 0 1 2 3 4 5 6 7 8 9
+---+---+---+---+---+---+---+---+---+
SHORTEST P P P A A
LONGEST P P P A A
The host can't use the address until the first announcement is sent. 7 seconds
is a very long time on modern computers especially considering the fact that
the round-trip time on current LAN technologies is at most few milliseconds.
Section 2.2 of the RFC addresses this matter and hints that a future standard
will adjust those timeouts; however that standard doesn't exist yet.
Make the timeout configurable via a new IPv4DuplicateAddressDetectionTimeoutSec=
option. The intervals defined in the RFC are then scaled proportionally so that
the duration of the conflict detection takes at most the given value. Interval
happening after the first announcement are not scaled, as recommended by the
RFC.
This is needed for dnf5. But dnf-4 doesn't know about it. So also add a hint to
skip the option with dnf-4. We can drop this later when dnf5 is the default
everywhere.
Also, s/vim-minimal/nano/. Nano is the default editor in Fedora since
https://fedoraproject.org/wiki/Changes/UseNanoByDefault.
Map the FN key of TUXEDO InfinityFlex 14 Gen1 that wrongly produces the F23
scancode by default.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
We currently only disable selinux logging in mac_selinux_setup(),
but not in mac_init(). We don't want libraries we use to log unless
we tell them to, so disable selinux's logging in mac_init() as well.
In case of failures we don't want to leave an image with intermediate
test configuration, as images are reused across multiple tests
Follow-up for edca63a632
meson will send SIGTERM if the test gets stuck and hits the timeout,
in which case we still want to do log saving and analysis, so let's
add some signal handlers which allow us to do that.
This won't be very useful until https://github.com/mesonbuild/meson/pull/14513
lands, since we only get half a second from meson to handle SIGTERM
before it sends SIGKILL, but let's land this already so we immediately
start taking advantage of the meson fix once it lands.
meson's target has a few issues:
- Runs on all source files regardless if they're included in the
build or not
- Doesn't have any dependencies on generated sources which means we
have to do a full build first before we can run clang-tidy
- Doesn't allow us to pass any extra arguments
To work around these, let's define our own clang-tidy target instead
using llvm's run-clang-tidy script. Alongside the clang-tidy target,
let's start keeping track of all generated sources which we make the
clang-tidy target depend on. We also add a new target which will only
generate source files which is useful for setting up the source tree
for running code analysis against it.
This code seems to not be used anywhere at all, so let's drop it.
Follow up for ba8d00e859
Follow up for 85686b37b0
Follow up for aff853f8ea
Follow up for 36dad381a2
Previous code assumed that both family and address are read when
-EINVAL, hence the following read of port and name could succeed.
Let's drop the assumption, and skip reading remaining elements.
No functional change, just refactoring and preparation for later change.
Running within the build sandbox has a number of disadvantages:
- We have a separate clangd cache for each distribution/release combo
- It requires to build the full image before clangd can be used
- It breaks every time the image becomes out of date and requires a
rebuild
- We can't look at system headers as we don't have the knowledge to map
them from inside the build sandbox to the corresponding path on the host
Instead, let's have mkosi.clangd run clangd within the tools tree. We
already require building systemd for both the host and the target anyway,
and all the dependencies to build systemd are installed in the tools tree
already for that, as well as clangd since it's installed together with the
other clang tooling we install in the tools tree. Unlike the previous approach,
this approach only requires the mkosi tools tree to be built upfront, which has
a much higher chance of not invalidating its cache. We can also trivially map
system header lookups from within the sandbox to the path within mkosi.tools
on the host so that starts working as well.
Let's add a basic clang-tidy check to the linter workflow. This
gives us the following:
- A check so that we don't introduce any new cyclic header dependencies
- A check to make sure all of our header files are standalone, as clang-tidy
will fail to parse header files that don't include all their dependencies.
The clangd include checker is rather broken and is littered with false
positives in our codebase, so let's disable the feature until it improves
a bit.
We already have LOG_CONTEXT_PUSH_EXEC() which with two additions
does exactly the same as the custom logging macros, so let's get rid
of the custom logging macros and use LOG_CONTEXT_PUSH_EXEC() instead.
Additionally, using the log context makes sure the extra fields are
applied to all log messages generated while the context is in place,
rather than only log messages logged with log_unit_xxx() in timedated
itself.
It also means the unit name is prefixed to all log messages logged
within that context. While it's not clear whether we always want the
unit name to be attached to library log messages, we also don't want
the unit name to not be attached to any library log messages, so we opt
to add more rather than less information by adding the unit name everywhere
for now.
In the future we can look into some log.h helpers to enable/disable
adding the prefix to the following log messages or not.
Currently LogLevelMax= can only be used to decrease the maximum log level
for a unit but not to increase it. Let's make sure the latter works as
well, so LogLevelMax=debug can be used to enable debug logging for specific
units without enabling debug logging globally.
Mike Yuan
Yu Watanabe
Jesper Nilsson
Beniamino Galvani
joo es
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Werner Sembach
Michal Koutný
Luca Boccassi
Nick Labich