| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The source (usually DMI/SMBIOS) only has 24h granularity, hence don't
show time as well, it's useless.
|
|
|
|
|
|
| |
Offer the firmware date as an epoch instead of the literal DMI string.
Closes #25679
|
|
|
|
| |
Expose /sys/class/dmi/id/bios_date as dbus property in hostnamed.
|
|
|
|
| |
Expose /sys/class/dmi/id/bios_vendor as dbus property in hostnamed.
|
| |
|
|
|
|
|
|
| |
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
|
|
|
|
|
| |
util.h is now about logarithms only, so we can rename it. Many files included
util.h for no apparent reason… Those includes are dropped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.
This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).
Follow-up for: b66a6e1a5838b874b789820c090dd6850cf10513
|
|
|
|
|
|
|
|
|
|
|
|
| |
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
|
|
|
|
|
| |
"n/a" is more ambiguous: not available or not set or maybe we didn't check it.
Let's just say directly that the field is not set.
|
| |
|
|
|
|
|
|
| |
Fixes a bug introduced by 8c8b1800e90d4307397300ef32b0f6d95efad057.
Fixes #24384.
|
|
|
|
| |
grep -l -r http:// | xargs sed -E -i s'#http://(.*).freedesktop.org#https://\1.freedesktop.org#'
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
These days we have a mechanism for safely returning errnos in enum
types, via definining -ERRNO_MAX as one special enu value. Let's use
that for Virtualization.
No change in behaviour, just some typesafety improvement.
|
| |
|
|
|
|
| |
Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's be more precise here. Otherwise people might think this describes
the software system or so. We already expose this via hostnamed as
HardwareVendor/HardwareModel hence use the exact same wording.
(Note that the relevant props on the dmi device are just VENDOR/MODEL,
but that's OK given that DMI really is about hardware anyway,
unconditionally, hence no chance of confusion there.)
Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915e47a4797b05003cb1970fe2b01e530
|
|
|
|
| |
Closes #22119.
|
|
|
|
|
|
|
|
|
|
| |
Sometimes hardware vendor does not set DMI info correctly.
Already there is a way that the dbus properties can be overriden by
using hwdb. But that is not user friendly.
This adds two new fields in /etc/machine-info.
Closes #22207.
|
|
|
|
| |
Follow-up for 4b35eb2579b226785f0d94129a7652450f9723fd.
|
|
|
|
| |
Closes: #7390
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is to be able to distinguish whether we're in a VM/container or something
more substantial at a glance.
Chassis: laptop 💻
Chassis: tablet 具
Chassis: vm 🖴
Chassis: server 🖳
Chassis: handset 🕻
Chassis: watch ⌚
Chassis: desktop 🖥
Chassis: container ☐
|
|
|
| |
Some typos are also fixed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
From https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw
---
Userspace must not use the /sys/firmware/devicetree/base
path directly, but instead should follow /proc/device-tree
symlink. It is possible that the absolute path will change
in the future, but the symlink is the stable ABI.
---
Addresses the comment https://github.com/systemd/systemd/pull/20731#discussion_r744095262.
|
|
|
|
|
|
|
|
| |
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Device-tree based devices can't get the chassis type from DMI or ACPI,
and so far need a custom `/etc/machine-info` to set this property right.
A new 'chassis-type' toplevel device tree property has recently been
approved into the DT specification, making it possible to automate
chassis type detection on such devices.
This patch therefore falls back to reading this device-tree property if
nothing is available through both DMI and ACPI.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
|
|
|
|
| |
variants
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
|
|
|
|
|
| |
fixes assertion failure on arm:
systemd-hostnamed[642]: Assertion '(_error) != 0' failed at src/hostname/hostnamed.c:207, function fallback_chassis(). Aborting.
|
|
|
|
|
|
|
|
|
| |
This fixes a bug introduced by 822be62fb23ed0ec1062ffd18057e53f6c2f8c01.
Before this, if terminal width is not enough, the all subsequent lines
are included in the hyperlink.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1955475.
|
|
|
|
| |
in commands
|
|
|
|
| |
This wraps the new Describe() bus call of hostnamed.
|
| |
|
| |
|
|
|
|
|
| |
No changes in code, just some splitting out of code we want to use
elsewhere soon.
|
| |
|