Use varlink to detect networkd's network namespace when executing
networkctl rather than the D-Bus interface.
Signed-off-by: Matt Layher <mdlayher@gmail.com>
When looking at configuration, often a user wants to suppress the comments and
just look at the parts that actually configure something, roughly equivalent to
systemd-analyze cat-config … | rg -v '^(#|;|$)
This switch implements this natively, skipping lines that start with a comment
character or only contain whitespace.
For formats that have section headers, section headers are skipped, if only
followed by stuff that would be skipped. (The last section header is printed
when we're about to print some actual output.)
Note that the caller doesn't know if the format has headers or not. We do format
type detection in pretty-print.c. So the caller only specifies tldr=true|false, and
conf_files_cat() figures out if the format has headers and whether those should
be handled specially.
The comments that show the file name are always printed, even if all of the file
is suppressed.
This is a partial answer to the discussions in
https://github.com/systemd/systemd/pull/28919,
https://github.com/systemd/systemd/pull/29248. If the default config is shown in
config files, the user can conveniently use '--tldr' to show the relevant parts.
This fixes regression introduced in 5a0c810462 with which all requests
for link properties ended up with EINVAL as we kept hitting
the signature_is_single() assert in sd_bus_get_property().
This adds two verbs, edit and cat, to networkctl for
operating on network configs (namely .network, .netdev
and .link files). Specially, if the config name is
prefixed by @, it will be treated as network interface
name, and operations will be performed on config files
associated with the link.
Closes#26906
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
We have RxBufferSize= and TxBufferSize= in .link files. Let's use the same
abbreviation here. OTOH, "inc" could be short for "increment" or "increase",
let's avoid that.
Commit 0307afc681 ("networkctl: add support to display Transmit/Recieve queue
length (#12633)") added the display of the number of RX and TX Queues to the
output of `networkctl status $DEV`. However the row description says "Queue
Length".
This patch fixes the output by replacing "Queue Length" by "Number of Queues".
Fixes: 0307afc681 ("networkctl: add support to display Transmit/Recieve queue length (#12633)")
IN6_ADDR_TO_STRING(…) always returns something, so we can simplify the code a
lot. Also, let's not do step-wise concatenation, but instead handle everything
with one str_extendf() call.
We'd connect to the bus twice: the first time to check networkd namespace,
and then the second time to do the deed we were asked to do. It's nicer
to open the bus just once, for efficience and also to avoid the open call
in all functions.
An ASSERT_PTR helper is added:
- sd_bus *bus = userdata;
...
- assert(bus);
+ sd_bus *bus = ASSERT_PTR(userdata);
...
It can be used in other place too, but I'm leaving that for a later
refactoring.
We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.