* add a new EFI tool "sd-fetch" or so. It looks in a PE section ".url" for an
URL, then downloads the file from it using UEFI HTTP APIs, and executes it.
- Usecase: provide a minimal ESP with sd-boot and a couple of these sd-fetch
+ Use case: provide a minimal ESP with sd-boot and a couple of these sd-fetch
binaries in place of UKIs, and download them on-the-fly.
* maybe: systemd-loop-generator that sets up loopback devices if requested via kernel
- cmdline. usecase: include encrypted/verity root fs in UKI.
+ cmdline. use case: include encrypted/verity root fs in UKI.
* systemd-gpt-auto-generator: add kernel cmdline option to override block
device to dissect. also support dissecting a regular file. useccase: include
subsequent boots?
* provide an API (probably IPC) to apps to encrypt/decrypt
- credentials. usecase: allow bluez bluetooth daemon to pass pairings to initrd
+ credentials. use case: allow bluez bluetooth daemon to pass pairings to initrd
that way, without shelling out to our tools.
* revisit default PCR bindings in cryptenroll and systemd-creds. Currently they
* systemd-repart: in addition to the existing "factory reset" mode (which
simply empties existing partitions marked for that). add a mode where
- partitions marked for it are entirely removed. Usecase: remove secondary OS
+ partitions marked for it are entirely removed. Use case: remove secondary OS
copy, and redundant partitions entirely, and recreate them anew.
* systemd-boot: maybe add support for collapsing menu entries of the same OS
* add support for asymmetric LUKS2 TPM based encryption. i.e. allow preparing
an encrypted image on some host given a public key belonging to a specific
other host, so that only hosts possessing the private key in the TPM2 chip
- can decrypt the volume key and activate the volume. Usecase: systemd-confext
+ can decrypt the volume key and activate the volume. Use case: systemd-confext
for a central orchestrator to generate confext images securely that can only
be activated on one specific host (which can be used for installing a bunch
of creds in /etc/credstore/ for example). Extending on this: allow binding
current system state, i.e. a combination of PCR information, local system
time and TPM clock, running services, recent high-priority log
messages/coredumps, system load/PSI, signed by the local TPM chip, to form an
- enhanced remote attestation quote. Usecase: a simple orchestrator could use
+ enhanced remote attestation quote. Use case: a simple orchestrator could use
this: have the report tool upload these reports every 3min somewhere. Then
have the orchestrator collect these reports centrally over a 3min time
window, and use them to determine what which node should now start/stop what,
* Add "purpose" flag to partition flags in discoverable partition spec that
indicate if partition is intended for sysext, for portable service, for
booting and so on. Then, when dissecting DDI allow specifying a purpose to
- use as additional search condition. Usecase: images that combined a sysext
+ use as additional search condition. Use case: images that combined a sysext
partition with a portable service partition in one.
* On boot, auto-generate an asymmetric key pair from the TPM,
usr=
• systemd-homed: when initializing, look for a credential
systemd.homed.register or so with JSON user records to automatically
- register if not registered yet. Usecase: deploy a system, and add an
+ register if not registered yet. Use case: deploy a system, and add an
account one can directly log into.
• in gpt-auto-generator: check partition uuids against such uuids supplied via
sd-stub credentials. That way, we can support parallel OS installations with
* sd-boot: instead of unconditionally deriving the ESP to search boot loader
spec entries in from the paths of sd-boot binary, let's optionally allow it
- to be configured on sd-boot cmdline + efi var. Usecase: embed sd-boot in the
+ to be configured on sd-boot cmdline + efi var. Use case: embed sd-boot in the
UEFI firmware (for example, ovmf supports that via qemu cmdline option), and
use it to load stuff from the ESP.
* homed/userdb: maybe define a "companion" dir for home directories where apps
can safely put privileged stuff in. Would not be writable by the user, but
still conceptually belong to the user. Would be included in user's quota if
- possible, even if files are not owned by UID of user. Usecase: container
+ possible, even if files are not owned by UID of user. Use case: container
images that owned by arbitrary UIDs, and are owned/managed by the users, but
are not directly belonging to the user's UID. Goal: we shouldn't place more
privileged dirs inside of unprivileged dirs, and thus containers really
look for right in the sd-boot binary. i.e. take inspiration from sd-stub
logic: allow combining sd-boot via ukify with kernels to enumerate, .conf
files, drivers, keys to enroll and so on. Then, add whatever we find that way
- to the menu. Usecase: allow building a single PE image you can boot into via
+ to the menu. Use case: allow building a single PE image you can boot into via
UEFI HTTP boot.
* maybe add a new UEFI stub binary "sd-http". It works similar to sd-stub, but
* maybe add a generator that reads /proc/cmdline, looks for
systemd.pull-raw-portable=, systemd-pull-raw-sysext= and similar switches
that take a URL as parameter. It then generates service units for
- systemd-pull calls that download these URLs if not installed yet. usecase:
+ systemd-pull calls that download these URLs if not installed yet. Use case:
invoke a VM or nspawn container in a way it automatically deploys/runs these
images as OS payloads. i.e. have a generic OS image you can point to any
payload you like, which is then downloaded, securely verified and run.
* add tiny service that decrypts encrypted user records passed via initrd
credential logic and drops them into /run where nss-systemd can pick them up,
- similar to /run/host/userdb/. Usecase: drop a root user JSON record there,
+ similar to /run/host/userdb/. Use case: drop a root user JSON record there,
and use it in the initrd to log in as root with locally selected password,
- for debugging purposes. Other usecase: boot into qemu with regular user
+ for debugging purposes. Other use case: boot into qemu with regular user
mounted from host. maybe put this in systemd-user-sessions.service?
* drop dependency on libcap, replace by direct syscalls based on
the resulting fd to the service program via socket activation proto.
* Add a concept of ListenStream=anonymous to socket units: listen on a socket
- that is deleted in the fs. Usecase would be with ConnectSocket= above.
+ that is deleted in the fs. Use case would be with ConnectSocket= above.
* importd: support image signature verification with PKCS#7 + OpenBSD signify
logic, as alternative to crummy gpg
else. Similar, ManagerSlice= should exist so that PID1's own scope unit could
be moved somewhere else too. Finally machined and logind should get similar
options so that it is possible to move user session scopes and machines to a
- different slice too by default. Usecase: people who want to put resources on
+ different slice too by default. Use case: people who want to put resources on
the entire system, with the exception of one specific service. See:
https://lists.freedesktop.org/archives/systemd-devel/2018-February/040369.html
- generate better errors when people try to set transient properties
that are not supported...
https://lists.freedesktop.org/archives/systemd-devel/2015-February/028076.html
- - maybe introduce WantsMountsFor=? Usecase:
+ - maybe introduce WantsMountsFor=? Use case:
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
- recreate systemd's D-Bus private socket file on SIGUSR2
- move PAM code into its own binary
* BootLoaderSpec: Define a way how an installer can figure out whether a BLS
compliant boot loader is installed.
-* think about requeuing jobs when daemon-reload is issued? usecase:
+* think about requeuing jobs when daemon-reload is issued? use case:
the initrd issues a reload after fstab from the host is accessible
and we might want to requeue the mounts local-fs acquired through
that automatically.
also in possession of the service itself, and it may (and is expected to)
invoke any operations on it that it likes.
-The primary usecase of this logic is to permit services to restart seamlessly
+The primary use case of this logic is to permit services to restart seamlessly
(for example to update them to a newer version), without losing execution
context, dropping pinned resources, terminating established connections or even
just momentarily losing connectivity. In fact, as the file descriptors can be
A system service that provides a client-facing interface that shall be able to
seamlessly restart can make use of this in a scheme like the following:
whenever a new connection comes in it uploads its fd immediately into its
-fdstore. At approporate times it also serializes its state into a memfd it
+fdstore. At appropriate times it also serializes its state into a memfd it
uploads to the service manager — either whenever the state changed
sufficiently, or simply right before it terminates. (The latter of course means
that state only survives on *clean* restarts and abnormal termination implies the
parts of the service managers state tracking, resource management (as resource
counters cannot start at zero during service activation anymore, since the old
processes remaining skew them), security policies (as processes with possibly
-out-of-date security policies – selinux, AppArmor, any LSM, seccomp, BPF — in
+out-of-date security policies – SElinux, AppArmor, any LSM, seccomp, BPF — in
effect remain), and similar.
# File Descriptor Store Lifecycle
the very end (i.e. by setting `DefaultDependencies=no` so that it keeps running
for the whole system lifetime without being regularly deactivated at shutdown)
or by setting `FileDescriptorStorePresever=yes` (and referencing the unit
-continously).
+continuously).
# Debugging
together the former is applied first. If a directory listed already exists no operation is executed
(in particular, the ownership/access mode of the directories is left as is).</para>
- <para>The primary usecase for this option is to create a minimal set of directories that may be
+ <para>The primary use case for this option is to create a minimal set of directories that may be
mounted over by other partitions contained in the same disk image. For example, a disk image where
the root file system is formatted at first boot might want to automatically pre-create
<filename>/usr/</filename> in it this way, so that the <literal>usr</literal> partition may
for details. For file descriptors pushed into the file descriptor
store (see above), the name is set via the
<varname>FDNAME=</varname> field transmitted via
- <function>sd_pid_notify_with_fds()</function>. The primary usecase
+ <function>sd_pid_notify_with_fds()</function>. The primary use case
for these names are services which accept a variety of file
descriptors which are not recognizable with functions like
<function>sd_is_socket()</function> alone, and thus require
not applied to any sockets passed into the service via socket activation. Thus, it is usually a
good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless,
it may make sense to maintain one list more open and the other one more restricted, depending on
- the usecase.</para>
+ the use case.</para>
<para>If these settings are used multiple times in the same unit the specified lists are combined. If an
empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para>
for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into
the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both
the socket and the service unit, however it often makes sense to maintain one configuration more open and the other
- one more restricted, depending on the usecase.</para>
+ one more restricted, depending on the use case.</para>
<para>Note that these settings might not be supported on some systems (for example if eBPF control group
support is not enabled in the underlying kernel or container manager). These settings will fail the service in
/* Note: on GCC "no_sanitize_address" is a function attribute only, on llvm it may also be applied to global
* variables. We define a specific macro which knows this. Note that on GCC we don't need this decorator so much, since
- * our primary usecase for this attribute is registration structures placed in named ELF sections which shall not be
+ * our primary use case for this attribute is registration structures placed in named ELF sections which shall not be
* padded, but GCC doesn't pad those anyway if AddressSanitizer is enabled. */
#if HAS_FEATURE_ADDRESS_SANITIZER && defined(__clang__)
#define _variable_no_sanitize_address_ __attribute__((__no_sanitize_address__))
#include "macro.h"
-/* An embeddable structure carrying a reference to a process. Supposed to be used when tracking processes continously. */
+/* An embeddable structure carrying a reference to a process. Supposed to be used when tracking processes continuously. */
typedef struct PidRef {
pid_t pid; /* always valid */
int fd; /* only valid if pidfd are available in the kernel, and we manage to get an fd */
* Rules regarding adding further high level targets like the above:
*
* - Be conservative, only add more of these when we really need
- * them. We need strong usecases for further additions.
+ * them. We need strong use cases for further additions.
*
* - When there can be multiple implementations running side-by-side,
* it needs to be a .target unit which can pull in all
assert_cc(offsetof(BaseBlock, root_cell_offset) == 36);
/* All offsets are relative to the base block and technically point to a hive
- * cell struct. But for our usecase we don't need to bother about that one,
+ * cell struct. But for our use case we don't need to bother about that one,
* so skip over the cell_size uint32_t. */
#define HIVE_CELL_OFFSET (sizeof(BaseBlock) + 4)
*
* Note that checking for a container environment is kinda ugly, since in theory people could use cgtop from
* inside a container where cgroup namespacing is turned off to watch the host system. However, that's mostly a
- * theoretic usecase, and if people actually try all they'll lose is accounting for the top-level cgroup. Which
+ * theoretic use case, and if people actually try all they'll lose is accounting for the top-level cgroup. Which
* isn't too bad. */
if (detect_container() > 0)
* and we should not "lose precision" in our types on the way. That said, I am pretty sure
* actually encoding binary data as unit metadata is not a good idea. Hence we actually refuse
* any actual binary data, and only accept UTF-8. This allows us to eventually lift this
- * limitation, should a good, valid usecase arise. */
+ * limitation, should a good, valid use case arise. */
r = sd_bus_message_read_array(message, 'y', &p, &sz);
if (r < 0)
if (streq(optarg, "-"))
/* An undocumented feature: we can read journal files from STDIN. We don't document
* this though, since after all we only support this for mmap-able, seekable files, and
- * not for example pipes which are probably the primary usecase for reading things from
+ * not for example pipes which are probably the primary use case for reading things from
* STDIN. To avoid confusion we hence don't document this feature. */
arg_file_stdin = true;
else {
_cleanup_close_ int fd = -EBADF;
/* The input path maybe a symlink located outside of /sys. Let's try to chase the symlink at first.
- * The primary usecase is that e.g. /proc/device-tree is a symlink to /sys/firmware/devicetree/base.
+ * The primary use case is that e.g. /proc/device-tree is a symlink to /sys/firmware/devicetree/base.
* By chasing symlinks in the path at first, we can call sd_device_new_from_path() with such path. */
r = chase(_syspath, NULL, 0, &syspath, &fd);
if (r == -ENOENT)
t->answer_rcode,
t->answer,
DNS_PACKET_CD(t->received) ? t->received : NULL, /* only cache full packets with CD on,
- * since our usecase for caching them
+ * since our use case for caching them
* is "bypass" mode which is only
* enabled for CD packets. */
t->answer_query_flags,
* anymore (since in some cases the kernel implementations will refuse mounting when corrupted,
* read-only and "norecovery" is specified). But I think for the case of automatically determined
* mount options for loopback devices this is the right choice, since otherwise using the same
- * loopback file twice even in read-only mode, is going to fail badly sooner or later. The usecase of
+ * loopback file twice even in read-only mode, is going to fail badly sooner or later. The use case of
* making reuse of the immutable images "just work" is more relevant to us than having read-only
* access that actually modifies stuff work on such image files. Or to say this differently: if
* people want their file systems to be fixed up they should just open them in writable mode, where
PartitionPolicy policies[]; /* sorted by designator, hence suitable for binary search */
};
-/* Default policies for various usecases */
+/* Default policies for various use cases */
extern const ImagePolicy image_policy_allow;
extern const ImagePolicy image_policy_deny;
extern const ImagePolicy image_policy_ignore;
assert(fd >= 0);
- /* Tries to make the specified fd "comprehensively" read-only. Primary usecase for this is OS images,
+ /* Tries to make the specified fd "comprehensively" read-only. Primary use case for this is OS images,
* i.e. either loopback files or larger directory hierarchies. Depending on the inode type and
* backing file system this means something different:
*
* might create the paths that are intermediary to the listed paths. We can't really cover the generic case,
* but the least we can do is cover the specific case of /var/run vs. /run, as /var/run is a legacy name for
* /run only, and we explicitly document that and require that on systemd systems the former is a symlink to
- * the latter. Moreover files below this path are by far the primary usecase for tmpfiles.d/. */
+ * the latter. Moreover files below this path are by far the primary use case for tmpfiles.d/. */
k = path_startswith(*path, "/var/run/");
if (isempty(k)) /* Don't complain about other paths than /var/run, and not about /var/run itself either. */
Documentation=man:systemd-time-wait-sync.service(8)
# Note that this tool doesn't need CAP_SYS_TIME itself, but its primary
-# usecase is to run in conjunction with a local NTP service such as
+# use case is to run in conjunction with a local NTP service such as
# systemd-timesyncd.service, which is conditioned this way. There might be
-# niche usecases where running this service independently is desired, but let's
+# niche use cases where running this service independently is desired, but let's
# make this all "just work" for the general case, and leave it to local
# modifications to make it work in the remaining cases.
projects / thirdparty / systemd.git / commitdiff
