Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
Kernel API file systems typically use either "raw" or "seq_file" to
implement their various interface files. The former are really simple
(to point I'd call them broken), in that they have no understanding of
file offsets, and return their contents again and again on every read(),
and thus EOF is indicated by a short read, not by a zero read. The
latter otoh works like a typical file: you read until you get a
zero-sized read back.
We have read_virtual_file() to read the "raw" files, and can use regular
read_full_file() to read the "seq_file" ones.
Apparently all files in the top-level /proc/ directory use 'seq_file'.
but we accidentally used read_virtual_file() for them. Fix that.
Also clarify in a comment what the rules are.
Fixes: #36131
In one of the next commits we'd like to introduce a concept of
optionally hashing the hostname from the machine ID. For that we we need
to optionally back gethostname_full() by code involving sd-id128, hence
let's move it from src/basic/ to src/shared/, since only there we are
allowed to use our public APIs.
The capsule instances are related to user instances, so treat them
equally to user@.service when handling cgroup paths. This also saves us
from polluting public libsystemd API with variant for capsules too.
Fix: https://github.com/systemd/systemd/issues/36098
The capsule instances are related to user instances, so treat them
equally to user@.service when handling cgroup paths. This also saves us
from polluting public libsystemd API with variant for capsules too.
Fix: #36098
So apparently "linux,dummy-virt" is a devicetree in popular use by
various hypervisors, including crosvm:
e5d7a64d37/aarch64/src/fdt.rs (L692)
and qemu:
98c7362b1e/hw/arm/virt.c (L283)
and that's because the kernel ships support for that natively:
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/linux%2Cdummy-virt.yaml
It's explicitly for using in virtualization. Hence it's suitable for
detecting it as generic fallback.
This hence adds the check, similar to how we already look for one other
qemu-specific devicetree.
I ran into this while playing around with the new Pixel "Linux Terminal"
app from google which runs a Debian in a crosvm apparently. So far
systemd didn't recognize execution in it at all. Let's at least
recognize it as VM at all, even if this doesn't recognize it as
crosvm.
tianocore does some weird shit with its terminal emulation and regular
fills half the terminal with grey background and then invokes us with
this not cleared up. Hence let us clear this up for it: as part of the
ansi sequence based reset let's position the cursor explicitly at the
beginning of the current line, and erase everything till the end of the
screen. This makes boot output in tianocore vms much much cleaner.
Note that this does *not* erase any terminal output *before* the cursor
position where we take over, because that typically contains valuable
information still we should not erase.
This used to be relevant since in old versions of glibc an internal
cache is maintained, while we might sidestep their invalidation
with raw_clone(). After glibc 2.25 getpid() is a trivial wrapper
for the syscall, and hence there's no need to have a separate
raw_getpid().
We always validate that the target value is below _LOG_TARGET_SINGLE_MAX
before acessing it, but we don't actually size the array like that.
let's fix that.
This doesn#t effectively change anything, but it makes things more
explicit what the limit here is.
glibc exports getdents64 syscall as is, but musl exports it as
posix_getdents(). Let's introduce a simple wrapper of posix_getdents().
Note, our baseline for glibc is 2.31. Hence, we can assume getdents64()
always defined when building with glibc.
To resolve conflict with sys/mount.h and linux/mount.h or linux/fs.h.
The conflict between sys/mount.h and linux/mount.h is resolved in
glibc-2.37 (774058d72942249f71d74e7f2b639f77184160a6), but our baseline
is still glibc-2.31. Also, even with the version or newer, still
sys/mount.h conflicts with linux/fs.h, which is included by
linux/btrfs.h.
This introduces our own implementation of sys/mount.h, that can be
simultaneously included with linux/mount.h and linux/fs.h. This also
imports linux/fs.h, linux/mount.h, and several other dependent headers.
The introduced sys/mount.h header itself may not be enough simple, but
by using the header, we can drop most of workarounds in other source files.
Nowadays, we define syscall numbers for newer syscalls.
Hence the conditions are not necessary.
This also adds several comments about when syscalls are introduced.
