Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
This new helper takes both a PID and and a pidfd ID, and initializes a
PidRef from it. It ensures they actually belong together and returns an
error if not.
Instead of unconditionally including sys/param.h in
macro-fundamental.h which itself includes a bunch of other unnecessary
headers, let's override it with an empty file to avoid it from overriding
our MAX() macro. We can't make including it an error as it's included (
for seemingly no good reason) by <resolv.h>.
Note that this drops a lot of "const" qualifiers on PidRef arguments.
That's because pidref_is_self() suddenly might end changing the PidRef
because it acquires the pidfd ID.
We had this previously already with pidfd_equal(), but this amplifies
the problem.
I guess we C's "const" doesn't really work for stuff that contains
caches, that is just conceptually constant, but not actually.
This PidRef just track some data, but cannot be used for any active
operation.
Background: for https://github.com/systemd/systemd/pull/34703 it makes
sense to track explicitly if some PidRef is not a local one, so that we
never attempt to for example "kill a remote process" and thus
acccidentally hit the wrong process (i.e. a local one by the same PID).
The PID_AUTOMATIC value is now properly recognized by the PidRef logic
too. This needed some massaging of header includes, to ensure pidref.h
can access process-util.h's definitions and vice versa.
Besides internal comparisons, the inode number of pidfds
might be interesting directly to users, too. In the future
this field should also be exposed, so that it can serve as
a unique identifier of a process (but only for display,
as there's no method to map this back to a pid or pidfd).
This simply checks if the specified PidRef refers to the process we are
running in.
(In case you wonder why this is not a static inline: to avoid cyclic
header inclusion problems between pidref.h + process-util.h)
This new helper can be used after reading process info from procfs, to
verify that the data that was just read actually matches the pidfd, and
does not belong to some new process that just reused the numeric PID of
the process we originally pinned.
Usually we want to embed PidRef in other structures, but sometimes it
makes sense to allocate it on the heap in case it should be used
standalone. Add helpers for that.
Primary usecase: use as key in Hashmap objects, that for example map
process to unit objects in PID 1.
This adds pidref_free()/pidref_freep() for freeing such an allocated
struct, as well as pidref_dup() (for duplicating an existing PidRef
on the heap 1:1), and pidref_new_pid() (for allocating a new PidRef from a
PID).
This helper truns a pid_t into a PidRef. It's different from
pidref_set_pid() in being "passive", i.e. it does not attempt to acquire
a pidfd for the pid.
This is useful when using the PidRef as a lookup key that shall also
work after a process is already dead, and hence no conversion to a pidfd
is possible anymore.
This compares two PidRef structures via the pid_t field. Ideally we'd do
a stricter comparison here, that is safe towards PID reuse, but so far
the pidfd API lacks suitable mechanisms for that, hence do the best we
can do.
Let's start with the conversion of PID 1 to pidfds. Let's add a simple
structure with just two fields that can be used to maintain a reference
to arbitrary processes via both pid_t and pidfd.
This is an embeddable struct, to keep it in line with where we
previously used a pid_t directly to track a process.
Of course, since this might contain an fd on systems where we have pidfd
this structure has a proper lifecycle.
(Note that this is quite different from sd_event_add_child() event
source objects as that one is only for child processes and collects
process results, while this infra is much simpler and more generic and
can be used to reference any process, anywhere in the tree.)
