Generated by GitHub Copilot.
would go to a subdirectory specific to that component if it is only used there.
If the code is to be shared between components, it'd go to `src/shared/`.
Shared code that is used by multiple components that do not link to `libsystemd-shared-<nnn>.so` may live either in `src/libsystemd/`, `src/basic/`, or `src/fundamental/`.
-Any code that is used only for EFI goes under `src/boot/efi/`, and `src/fundamental/` if is shared with non-EFI components.
+Any code that is used only for EFI goes under `src/boot/efi/`, and in `src/fundamental/` if it is shared with non-EFI components.
To summarize:
Fuzzers are invoked primarily in three ways:
firstly, each fuzzer is compiled as a normal executable and executed for each of the input samples under `test/fuzz/` as part of the test suite.
Secondly, fuzzers may be instrumented with sanitizers and invoked as part of the test suite (if `-Dfuzz-tests=true` is configured).
-Thirdly, fuzzers are executed through fuzzing engines that tryto find new "interesting" inputs through coverage feedback and massive parallelization; see the links for oss-fuzz in [Code quality](/CODE_QUALITY).
+Thirdly, fuzzers are executed through fuzzing engines that try to find new "interesting" inputs through coverage feedback and massive parallelization; see the links for oss-fuzz in [Code quality](/CODE_QUALITY).
For testing and debugging, fuzzers can be executed as any other program, including under `valgrind` or `gdb`.
## Integration Tests
## Boot Loader Entry Identifiers
While boot loader entries may be named relatively freely,
-it's highly recommended to follow the following rules when picking identifiers for the entries,
+it's highly recommended to follow these rules when picking identifiers for the entries,
so that programs (and users) can derive basic context and meaning from the identifiers
as passed in `LoaderEntries`, `LoaderEntryDefault`, `LoaderEntryOneShot`, `LoaderEntrySelected`,
and possibly show nicely localized names for them in UIs.
Note that the message catalog is only available for messages generated with the MESSAGE\_ID= journal meta data field, as this is need to find the right entry for a message.
For more information on the MESSAGE\_ID= journal entry field see [systemd.journal-fields(7)](http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html).
-To add message catalog entries for log messages your application generates, please follow the following guidelines:
+To add message catalog entries for log messages your application generates, please follow these guidelines:
* Use the [native Journal logging APIs](http://0pointer.de/blog/projects/journal-submit.html)
to generate your messages, and define message IDs for all messages you want to add catalog entries for.
# Contributing
-We welcome contributions from everyone. However, please follow the following guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:
+We welcome contributions from everyone. However, please follow these guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:
## Filing Issues
Service and slice units may be configured via unit files on disk, or alternatively be created dynamically at runtime via API calls to PID 1. Scope units may only be created at runtime via API calls to PID 1, but not from unit files on disk. Units that are created dynamically at runtime via API calls are called _transient_ units. Transient units exist only during runtime and are released automatically as soon as they finished/got deactivated or the system is rebooted.
-If a service/slice is configured via unit files on disk the resource controls may be configured with the settings documented in [systemd.resource-control(5)](http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html). While the unit are started they may be reconfigured for services/slices/scopes (with changes applying instantly) with the a command line such as:
+If a service/slice is configured via unit files on disk the resource controls may be configured with the settings documented in [systemd.resource-control(5)](http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html). While the unit is started it may be reconfigured for services/slices/scopes (with changes applying instantly) with a command line such as:
```
# systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M
closed). Generally it's a good idea to send such messages to the service
manager during initialization of the service whenever an unrecognized fd is
received, to make the service robust for code updates: if an old version
-uploaded an fd that the new version doesn't recognize anymore it's good idea to
+uploaded an fd that the new version doesn't recognize anymore it's a good idea to
close it both in the service and in the fdstore.
Note that storing a duplicate of an fd in the fdstore means the resource pinned
from Java's Hashtable for example: > 75%), the writer should rotate the file
and create a new one.
-The DATA_HASH_TABLE should be sized taking into account to the maximum size the
+The DATA_HASH_TABLE should be sized taking into account the maximum size the
file is expected to grow, as configured by the administrator or disk space
considerations. The FIELD_HASH_TABLE should be sized to a fixed size; the
number of fields should be pretty static as it depends only on developers'
service's cgroup. In order to make debugging easier, and allow later
extension it is recommended for applications to also allow this path to refer
to an `AF_UNIX` stream socket in the file system or a FIFO inode in the file
- system. Regardless which of the three types of inodes this absolute path
+ system. Regardless of which of the three types of inodes this absolute path
refers to, all three are `poll()`-able for memory pressure events. The
variable can also be set to the literal string `/dev/null`. If so the service
code should take this as indication that memory pressure monitoring is not
* And so on and so on.
All these are valid approaches to the question "When is the network up?", but
-none of them would be useful to be good as generic default.
+none of them would be good as a generic default.
Modern networking tends to be highly dynamic: machines are moved between
networks, network configuration changes, hardware is added and removed, virtual
Ignore EEXIST on mkdir.
- Avoid renaming cgroups or similar fancier file operations.
- Expect that other programs might readjust the attributes on your cgroups dynamically during runtime.
-- When creating a cgroup pick a nice a descriptive name that is guessable and no surprise to the admin.
+- When creating a cgroup pick a descriptive name that is guessable and no surprise to the admin.
The admin will thank you for this if he has to read the output of "ps -eo pid,args,cgroups"
- /sys/fs/cgroup is a tmpfs. If you create your own private named hierarchy then you are welcome to mount it into a subdirectory of this directory.
This minimizes surprises for the user.
Note that the images need to stay around (and in the same location) as long as the
portable service is attached.
-If an image is moved, the `RootImage=` line written to the unit drop-in would point to an non-existent path, and break access to the image.
+If an image is moved, the `RootImage=` line written to the unit drop-in would point to a non-existent path, and break access to the image.
The `portablectl detach` command executes the reverse operation:
it looks for the drop-ins and the unit files associated with the image, and removes them.
> [!NOTE]
> Depending on the execution environment the first component (the boot loader)
> might be dispensable. Specifically, on disk images intended solely for use in
-> VMs, it might be make sense to tell the firmware to directly boot a UKI,
+> VMs, it might make sense to tell the firmware to directly boot a UKI,
> letting the VMM's image selection functionality play the role of the boot loader.
> [!NOTE]
Special care is taken to avoid recursion between these two compatibility mechanisms.
Subsystems that shall provide user/group records to the system may choose
-between offering them via an NSS module or via a this Varlink API, either way
+between offering them via an NSS module or via this Varlink API, either way
all records are accessible via both APIs, due to the bidirectional forwarding.
It is also possible to provide the same records via both APIs
directly, but in that case the compatibility logic must be turned off.
projects / thirdparty / systemd.git / commitdiff
