CodeQL was complaining that the local variable obscurs the global
one. It is indeed a bit confusing when reading this… Let's rename
the variable to avoid confusing the reader.
Confer https://github.com/systemd/systemd/pull/19006#issuecomment-800234022:
On some systems it's the admin's explicit choice not to to have the
machine ID leak into the ESP
On some systems the machine ID is transient, generated at every boot,
and hence should not be written to the ESP
Follow-up for pull request #21170.
I hoped that we would drop libgcrypt fully and drop all references to the
library in meson, but this doesn't seem feasible (because of the use in
sd-journal). But let's remove it here, all the resolved code has been switched
to work either of the two libraries.
Previously the MMapCache* was optionally NULL, which open would
handle by creating a new MMapCache* for the occasion.
This produced some slightly circuitous refcount-handling code in
the function, as well as arguably creating opportunities for
weirdness where an MMapCache* was intended to be supplied but
happened to be NULL, which this magic would then paper over.
In any case, this was basically only being utilized by tests,
apparently just to avoid having to create an MMapCache. So
update the relevant tests to supply an MMapCache and make
journal_file_open() treat a NULL MMapCache* as fatal w/assert.
This gets rid of the manual MMapCache ref/unref goop in
journal_file_{open,close}(), in favor of just letting the
JournalFile.cache_fd MMapFileDescriptor carry the baton.
Preparatory commit; before JournalFile can stop hanging onto its
copy of MMapCache, all these users need to find another way.
Most of the time these callers already have the MMapCache onhand,
so it's no big deal for them to just supply it.
journal_file_rotate() in particular needed to change, and it
seemed wise to not use the mmap_cache_fd_cache() accessor on
f->cache_fd, instead requiring the caller supply the cache to
use. This was done with an eye towards a potential future where
the journal_file_archive() isolates the cache_fd to a private
cache, which the newly rotated-to file wouldn't be allowed to
use. It's no biggie for the existing callers to just provide the
appropriate surviving cache.
Basically the mmap_cache_fd_cache() accessor was added just for
journal-verify.c's (ab)use of the mmap-cache. Which, if the
ugly singleton MMapCache assumption ever goes away, can be
cleaned up to simply use a separate MMapCache for those search
arrays.
Preparatory commit; callers manually ref/unref MMapCaches
alongside MMapFileDescriptor add/frees, when the latter should be
sufficient.
A subsequent commit will drop some of those manual MMapCache
reference hoop-jumping, leaving the lifecycle bound to
MMapFileDescriptors.
