Let's define a set of macros for making output of permyriad values easy.
They are printed in pure ASCII, i.e. without the permille/permyriad
suffix, using just percent and two places after the dot.
At various places we accept values scaled to the range 0…2^32-1 which
are exposed to the user as percentages/permille/permyriad. Let's add
some helper macros (actually: typesafe macro-like functions) that help
with converting our internal encoding to the external encodings.
benefits: some of the previous code rounded up, some down. let's always
round to nearest, to ensure that our conversions are reversible. Also,
check for overflows correctly.
This also adds a test that makes sure that for the full
percent/permille/permyriad ranges we can convert forth and back without
loss of accuracy.
Previously, when parsing myriads, we'd support:
x% → percent, no places after the dot
x.yz% → percent, two places after the dot
x‰ → permille, no places after the dot
x.y‰ → permille, one place after the dot
x‱ → permyriad, no places after the dot
What's missing is:
x.y% → percent, one place after the dot
Let's add it in.
A good chunk of parse-util.[ch] has been about parsing parts per
hundred/thousand/ten-thousand. Let's split that out into its own file.
No code changes, just some shuffling around.
Taking a stab at implementing #14479.
Add {Condition,Assert}CPUFeature to `systemd-analyze` & friends. Implement it
by executing the CPUID instruction. Add tables for common x86/i386
features.
Tested via unit tests + checked that commands such as:
```bash
systemd-analyze condition 'AssertCPUFeature = rdrand'
```
Succeed as expected and that commands such as
```bash
systemd-analyze condition 'AssertCPUFeature = foobar'
```
Fail as expected. Finally, I have amended the `systemd.unit` manual page
with the new condition and the list of all currently supported flags.
Use the right FD, and do a fd_reopen instead of a dup, since the
latter will still share the internal pointer which then gets
moved by FOREACH_DIRENT, affecting the caller's FD.
If the cleanup function returns the appropriate type, use that to reset the
variable. For other functions (usually the foreign ones which return void), add
an explicit value to reset to.
This causes a bit of code churn, but I think it might be worth it. In a
following patch static destructors will be called from a fuzzer, and this
change allows them to be called multiple times. But I think such a change might
help with detecting unitialized code reuse too. We hit various bugs like this,
and things are more obvious when a pointer has been set to NULL.
I was worried whether this change increases text size, but it doesn't seem to:
-Dbuildtype=debug:
before "tree-wide: return NULL from freeing functions":
-rwxrwxr-x 1 zbyszek zbyszek 4117672 Feb 16 14:36 build/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 4494520 Feb 16 15:06 build/systemd*
after "tree-wide: return NULL from freeing functions":
-rwxrwxr-x 1 zbyszek zbyszek 4117672 Feb 16 14:36 build/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 4494576 Feb 16 15:10 build/systemd*
now:
-rwxrwxr-x 1 zbyszek zbyszek 4117672 Feb 16 14:36 build/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 4494640 Feb 16 15:15 build/systemd*
-Dbuildtype=release:
before "tree-wide: return NULL from freeing functions":
-rwxrwxr-x 1 zbyszek zbyszek 5252256 Feb 14 14:47 build-rawhide/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 1834184 Feb 16 15:09 build-rawhide/systemd*
after "tree-wide: return NULL from freeing functions":
-rwxrwxr-x 1 zbyszek zbyszek 5252256 Feb 14 14:47 build-rawhide/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 1834184 Feb 16 15:10 build-rawhide/systemd*
now:
-rwxrwxr-x 1 zbyszek zbyszek 5252256 Feb 14 14:47 build-rawhide/libsystemd.so.0.30.0*
-rwxrwxr-x 1 zbyszek zbyszek 1834184 Feb 16 15:16 build-rawhide/systemd*
I would expect that the compiler would be able to elide the setting of a
variable if the variable is never used again. And this seems to be the case:
in optimized builds there is no change in size whatsoever. And the change in
size in unoptimized build is negligible.
Something strange is happening with size of libsystemd: it's bigger in
optimized builds. Something to figure out, but unrelated to this patch.
I started working on this because I wanted to change how
DEFINE_TRIVIAL_CLEANUP_FUNC is defined. Even independently of that change, it's
nice to make make things more consistent and predictable.
All callers of strv_env_replace() would free the argument on error.
So let's follow the same pattern as with strv_consume (and similar
naming) and unconditionally "use up" the argument.
Numeric ifnames should be acceptable only if that's enabled by flag, and
refused otherwise. Hence, let's parse as ifindex first, and if that
works decide. Finally, let's refuse any numeric ifnames that are not
valid ifindexs, but look like them.
The property is never set by systemd, only reset after a stop or restart or
reload. It may externally be set to mark the unit for a later restart/reload.
I wasn't sure whether to configure the property only for the types where this
makes sense (Service, Swap, etc). But Restart() method is defined on the unit,
and also having this always under the same property name is more convenient.
The general idea is that when a unit file is "linked" (i.e. installed by
symlinking from outside of the search paths), the *destination* name is
irrelevant. It doesn't even have to be a valid unit name, or to match the type
or instance value. The obvious collorary is that we shouldn't look at the
symlink destination name to derive the unit name, instance value, or anything
else at all.
When building the name map, when we find a linked unit (possibly at the end
of a series of alias redirects), store the *source* of the final symlink as the
fragment path. This has two effects:
- we stop looking at the *target* file name to derive unit info, i.e. actually
implement the stuff described in the first paragraph.
- we load the unit fragment through the symlink. If someone were to remove the
symlink, we'll not load the unit. This seems like the right thing.
Fixes#18058.
Before this change, we were generally quite confused about unit alises for
linked units. Fortunately most poeple use the same symlink source and target,
so in practice we wouldn't hit this too often.
In unit_load_fragment() a comment is added to explain what we're doing there.
