The reallocation of memory and counter incrementation is moved from
the only caller to the function. This way the callers can remain oblivious
of the BootConfig internals.
We also shorten the logic by getting rid of the validate_node()
function. An extra check is added to verify we're dealing with
a device before calling sd_device_new_from_devname() since that
will return -EINVAL if anything other than a device is passed.
Instead of retrieving the new sysfs path in device_process_new(),
let's pass the syspath we retrieved earlier to device_process_new()
similar to how we do for other functions in core/device.c.
Previously, we manage DnsAnswerItem by an array and Set,
The array was used for the order of the items, and the set is used to
dedup items.
Let's use OrderedSet, then we can simplify the logic.
This fixes dns_answer_remove_by_key() and dns_answer_remove_by_rr()
which makes the set in a broken state.
In the documentation, using the term "managed" for both the RA flag and
the DHCPv6 mode is confusing because the mode is referred to as
"solicit" both in the official DHCPv6 documentation (see RFC 8415) and
in the WithoutRA option.
Furthermore, calling the other RA flag "other information" or "other
address configuration" is confusing because its official name is simply
"other configuration" (see RFC 4861 and RFC 5175) and it isn't used to
assign IP addresses.
Rewrite the documentation for DHCPv6Client and WithoutRA to make it
clear that getting the "managed" RA flag triggers the same kind of DHCP
request as WithoutRA=solicit, whereas getting the "other configuration"
RA flag triggers the same kind of DHCP request as
WithoutRA=information-request.
Plain strv_split() should not care if the strings contains backslashes
or quote characters. But extract_first_word() interprets backslashes
unless EXTRACT_RETAIN_ESCAPE is given.
I wonder how it's possible that nobody noticed this before. I think this
code was introduced in 0645b83a40.
Fixup for a5efbf468c: if $COLORTERM was set, we'd
unconditionally turn on colors, which is unexpected and wrong. It even breaks
our own tests when executed in gnome-terminal.
This reverts commit d6c9411072.
I still think this is something that needs to be done, but we're hitting some
unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920.
So let's revert this for now, so -rc2 can be released, with a plan to return
to this after a release.
Closes#22920.
With a recent change paths leaving the statically known lookup paths would be
treated differently then those that remained within those. That was done
(AFAIK) to consistently handle alias names. Unfortunately that means that on
some distributions, especially those where /etc/ consists mostly of symlinks,
would trigger that new detection for every single unit in /etc/systemd/system.
The reason for that is that the units directory itself is already a symlink.
Rebased-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Daan De Meyer
lucagoc
Jan Janssen
Alex Henrie
Khem Raj
Thomas Weißschuh
Jakob Lell
Andreas Rammhold