| /systemd-251/ |
| D | TODO | 78 semantics, like we do for device.c now
87 are not directly belonging to the user's UID. Goal: we shouldn't place more
102 this way we can implement disk encryption policies that bind to specific
104 the kernel includes the PCR signature blob we should be good, as disk
107 on the measured kernel/initrd of course, thus we cannot put the signature
109 Hence we have to find a separate place. A simple solution is a PE section
118 optionally sign them. for that we should extend our syntax for specifying pcr
190 descriptors, and clear this set piecemeal when we see the IN_IGNORED event
191 for it, or when read() returns EAGAIN or on IN_Q_OVERFLOW. Then, whenever we
194 case the same wd is reused multiple times before we start processing
[all …]
|
| D | .vimrc | 7 " Note that we set a line width of 109 for .c and XML files, but for everything
8 " else (such as journal catalog files, unit files, README files) we stick to a
|
| D | .packit.yml | 22 # Drop the "sources" file so rebase-helper doesn't think we're a dist-git
29 # cases (see [0]), we can't use -Dc_args=/-Dcpp_args= here because of the
|
| /systemd-251/docs/ |
| D | PORTABILITY_AND_STABILITY.md | 10 …y on. Starting with version 26 (the first version released with Fedora 15) we promise to keep a nu…
22 …we find bugs that mean that the existing interface was not useful, or when the implementation did …
26 …ily be kept stable for now, but we will eventually make a stability promise for these interfaces t…
40 …we will tell your mom, and she won't love you anymore. You are welcome to use the other interface…
42 …an interface we have listed above as stable, then we might take the liberty to do so, despite this…
51 …n a compatible fashion on those other operating systems. To make this easy we provide detailed int…
64 …e strongly encourage fixing bugs where they are, and if that's not systemd we rather not try to fi…
69 systemd's APIs are available everywhere where systemd is available. Some of the APIs we have define…
73 … are our invention (but most), we just adopted them in systemd to make them more prominently imple…
79 And now, here's the list of (hopefully) all APIs that we have introduced with systemd:
[all …]
|
| D | HACKING.md | 26 Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we
34 possible, however. In order to simplify testing for cases like this we provide
177 right in your editor of choice (with the right plugin installed). When using mkosi, we can run clan…
204 To be able to navigate to include files of systemd's dependencies, we need to make the /usr/include…
219 image, edit the 20-local.conf file we created earlier and add the following contents under the `[Pa…
230 Because mkosi needs to run as root, we also need to make sure we can enter the root password when t…
232 scripts, we use an askpass provider. This is a program that sudo will launch if it detects it's bei…
256 To simplify debugging systemd when testing changes using mkosi, we're going to show how to attach
260 To allow VSCode's debugger to attach to systemd running in a mkosi image, we have to make sure it c…
274 Now we need to configure VSCode. First, make sure the C/C++ extension is installed. If you're alrea…
[all …]
|
| D | CONTRIBUTING.md | 20 Following these guidelines makes it easier for us to process your issue, and ensures we won't close…
35 …Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
37 * Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we d…
44 …apologize in advance if we are not able to process and reply to your issue or PR right-away. We ha…
59 In case a new feature is added to both `systemd` and one of its dependencies, we expect the corresp…
68 reasons. When possible, we try to keep compatibility with the most recent LTS releases of each main…
|
| D | CODING_STYLE.md | 117 compatibility. Since we typically want to allow adding new enum values to an
124 - For our codebase we intend to use ISO C11 *with* GNU extensions (aka
125 "gnu11"). Public APIs (i.e. those we expose via `libsystemd.so`
128 from `<inttypes.h>`), so that we don't force consuming programs into C11
129 mode. (This discrepancy in particular means one thing: internally we use C99
143 in them. Instead of doing a lot of locking for that, we tend to prefer using
145 objects), or we disable caching for any thread that is not the main
192 cases we cache data in global variables. If you add more caches like this,
202 and Linux/GNU-specific APIs, we generally prefer the POSIX APIs. If there
203 aren't, we are happy to use GNU or Linux APIs, and expect non-GNU
[all …]
|
| D | ROOT_STORAGE_DAEMONS.md | 46 As a result, we hereby clarify that we do not support storage technology setups
51 What we do support instead is that these storage daemons are started from the
53 only after we returned control back to the initrd and by the initrd. As such,
84 initrd) we need to exclude these daemons from the shutdown/switch_root killing
106 suggested above is **NOT** for you. Sorry. Talk to us, we can probably help you
136 namespace (i.e. the initrd namespace). Other than that we just think that `@`
162 also be terminated when the OS shuts down (i.e. before we pass control back
|
| D | CODE_QUALITY.md | 29 [Coccinelle](http://coccinelle.lip6.fr/) semantic patch scripts we ship. The
34 of salt, in particular as we generally leave foreign header files we include in
|
| D | RANDOM_SEEDS.md | 302 the kernel's entropy pool to be initialized, which is the whole problem we
312 for the `uuidd.service` start we already need a UUID that the service is
343 it gets that from `getrandom()`, and thus we have to wait for random pool
349 it's not supported by glibc. And as long as that's the case we are not keen
350 on using it, as we'd have to maintain that on our own, and we don't want to
351 maintain our own cryptographic primitives if we don't have to. Since
354 call these functions. That said, if glibc learns these APIs one day, we'll
371 That's a good question. Ideally the kernel would do that on its own, and we
379 similar for them. Ideally, we'd have an official way to pass such a seed as
401 That said, we actually do implement this with the `systemd.random_seed=`
[all …]
|
| /systemd-251/test/test-path/ |
| D | basic.target | 10 # We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
11 # remote-fs.target by default, hence pull them in explicitly here. Note that we
13 # we support that unit being masked, and this should not be considered an error.
|
| /systemd-251/.lgtm/cpp-queries/ |
| D | UninitializedVariableWithCleanup.ql | 19 /** Auxiliary predicate: List cleanup functions we want to explicitly ignore
73 * is not a valid initialization, since we might return from the function
74 * _before_ the actual iniitialization (emphasis on _might_, since we
95 // If the uninitialized use we've found is in a macro expansion, it's
96 // typically something like va_start(), and we don't want to complain.
|
| /systemd-251/test/units/ |
| D | basic.target | 17 # We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
18 # remote-fs.target by default, hence pull them in explicitly here. Note that we
20 # we support that unit being masked, and this should not be considered an error.
|
| /systemd-251/units/ |
| D | basic.target | 17 # We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
18 # remote-fs.target by default, hence pull them in explicitly here. Note that we
20 # we support that unit being masked, and this should not be considered an error.
|
| D | systemd-sysupdate.timer | 14 # For containers we assume that the manager will handle updates. And we likely
22 # never booted up for long we have a chance to to do the update.
|
| D | system-update-cleanup.service | 21 # we need an alternate condition to cover the case of a dangling symlink.
26 # we guard against being diverted into system-update.target again, which
27 # works as a safety measure, but we will not step on the toes of the
|
| /systemd-251/test/fuzz/fuzz-udev-rules/ |
| D | 78-sound-card.rules | 8 # Ok, we probably need a little explanation here for what the two lines above
23 # As a workaround for this issue we have added the udev rule above which will
32 # or not for a card. To find that out we store the flag environment variable
53 # If we reach here, the device nor any of its parents are USB/PCI/firewire bus devices.
54 # If we now find a parent that is a platform device, assume that we're working with
|
| /systemd-251/rules.d/ |
| D | 78-sound-card.rules | 8 # Ok, we probably need a little explanation here for what the two lines above
23 # As a workaround for this issue we have added the udev rule above which will
32 # or not for a card. To find that out we store the flag environment variable
53 # If we reach here, the device nor any of its parents are USB/PCI/firewire bus devices.
54 # If we now find a parent that is a platform device, assume that we're working with
|
| D | 71-seat.rules.in | 52 # but it does carry good ID data in the graphics component, hence we
55 # rule is executed. To work around this we'll trigger the parent from
56 # the child if we notice that the parent wasn't recognized yet.
|
| /systemd-251/src/rfkill/ |
| D | rfkill.c | 169 struct rfkill_event we = { in load_state() local
177 ssize_t l = write(c->rfkill_fd, &we, sizeof we); in load_state()
183 l, sizeof we); in load_state()
184 log_debug("Writing struct rfkill_event successful (%zd of %zu bytes).", l, sizeof we); in load_state()
|
| /systemd-251/test/test-execute/ |
| D | exec-noexecpaths-simple.service | 7 # This should work, as we explicitly disable the effect of NoExecPaths=
9 # This should also work, as we do not disable the effect of NoExecPaths= but invert the exit code
|
| D | exec-readonlypaths-simple.service | 7 # This should work, as we explicitly disable the effect of ReadOnlyPaths=
9 # This should also work, as we do not disable the effect of ReadOnlyPaths= but invert the exit code
|
| /systemd-251/sysctl.d/ |
| D | 50-coredump.conf.in | 20 # processes are not reaped until we have finished collecting what we need. The
23 # higher setting the kernel will delay reaping until we are done, but only for
|
| /systemd-251/src/rpm/ |
| D | triggers.systemd.sh.in | 16 # so sometimes we will reload needlessly.
23 # On removal, we need to run daemon-reload after any units have been
25 # On upgrade, we need to run daemon-reload after any new unit files
|
| /systemd-251/src/core/bpf/ |
| D | meson.build | 17 # we're compiling for. By default we just map meson's cpu_family to __<cpu_family>__.
|