No functional change. In config_parse_address_generation_type() we would set
the output parameter and then say it's ignored, so it _looked_ like an error in
the code, but the variable was always initialized to SD_ID128_NULL anyway, so
the code was actually fine.
I always found it confusing that most of our TPM related definitions are
in tpm2-util.h, but the PCR names in tpm-pcr.h, without the "2". Let's
fix that and make this systematic, in particular as the definitions in
the file all start with TPM2_ already.
No code flow changes, just some renaming.
We so far maintained two places for symboic names for PCRs. One in
tpm2-util.h and one in tpm-pcr.h.
Let's unify this into one, i.e. move the full list from tpm2-util.h into
tpm-pcr.h, replacing the short list placed so far there.
Systematically prefix the definitions with TPM2_ or tpm2_, to follow how
we do this for all other defines in this context.
No change in behaviour, just unification of tables.
Let's a "b" helper for json_variant_set_field() that combines
json_build() with json_variant_set_field(), similar to the
json_variant_merge_objectb(), json_variant_append_arrayb().
json_append() is a useful wrapper around json_variant_merge(). However,
I think the naming sould be cleaned up a bit of both functions.
I thinker "merge" is the better word than "append", since it does
decidedly more than just append: it replaces existing fields of the same
name, hence "merge" sounds more appropriate. This is as opposed to the
similar operations for arrays, where no such override logic is applied
and we really just append, hence those functions are called "append"
already.
To make clearer that "merge" is about objects, and "append" about
arrays, also include "object" in the name.
Also, include "json_variant" in the name, like we do for almost all
other functions in the JSON API that take a JSON object as primary
input, and hence are kinda object methods.
Finally, let's follow the logic that helpers that combine json_build()
with some other operation get suffixed with "b" like we already have in
some cases.
Hence:
json_variant_merge() → json_variant_merge_object()
json_append() → json_variant_merge_objectb()
This mirrors nicely the existing:
json_variant_append_array()
json_vairant_append_arrayb()
This also drops the variant of json_append() that takes a va_arg
parameter (i.e. json_appendv()). We have no user of that so far, and
given the nature as a helper function only I don#t see that happening,
and if it happens after all it's trivial to bring back.
Let's make utf8_to_utf16() and utf16_to_utf8() a bit nicer to use by
adding shortcuts for common cases.
This is particularly relevant for utf16_to_utf8() since the
multiplication with 2 is easy to forget.
By making this a disabler dependency, we can slightly simplify the code
and it als fixes the build for -Dfdisk=disabled as we failed to create a
fallback empty libshared_fdisk variable.
I have been mistyping commands too often myself, and I think the tools
could simply be more helpful, by suggesting to me what I probably wanted
to write. Copy/Paste FTW, after all!
"static inline" makes sense in .h files. But in .c files it's useless
decoration, the compiler should just make its own decisions there, and
it can do that.
hence, replace all remaining uses of "static line" by a simple" static"
in all .c files (but keep them in .h files, where they make sense)
seccomp-util.h doesn't need ifdeffing, hence don't. It has worked since
quite a while with HAVE_SECCOMP is off, hence use it everywhere.
Also drop explicit seccomp.h inclusion everywhere (which needs
HAVE_SECCOMP ifdeffery everywhere). seccomp-util.h includes it anyway,
automatically, which we can just rely on, and it deals with HAVE_SECCOMP
at one central place.
Let's remove some HAVE_SECCOMP ifdeffery by simply defining the funcion
in question (seccomp_parse_errno_or_action() + related calls) into
common code that is also compiled if HAVE_SECCOMP is off.
This is generally the better approach anyway, since we want as much as
possible and easily feasible parsers work even if the code implementing
them is disabled. THis is easy to achieve here, hence do.
The specs call this TCG PC Client Platform Firmware Profile
Specification says this PCR is owned by the Host Platform Manufacturer,
at various places. Hence let's give it that name.
An error reply from polkit is a valid case and should not be propagated
as failure of async_polkit_callback(). It should only be saved here.
It'll be returned by bus_verify_polkit_async() later, when it's called
for the same method again.
Follow-up for #26365.