Enforce the quota on these two tmpfs at the same place where we mount
the per-user $XDG_RUNTIME_DIR. Conceptually these are very similar
concepts, and it makes sure to enforce the limits at the same place with
the same lifecycle.
As requested, a list of kernel version to feature mapping
for kernels older than minimum baseline is also included,
in order to ease potential backport work.
- Make fd_is_namespace() take NamespaceType
- Drop support for kernel without NS_GET_NSTYPE (< 4.11)
- Port is_our_namespace() to namespace_open_by_type()
(preparation for later commits, where the latter
would go by pidfd if available, avoiding procfs)
Plus, linux/random.h never defined getrandom(), hence remove
the custom machinery for sys/random.h vs linux/random.h
in favor of single HAVE_GETRANDOM.
The current fallback path is actually unreliable, given
the kernel *supports* setting the resume offset through
cmdline after all, but just not exposed under /sys/.
For v258 let's drop it hence.
I didn't bump the baseline to 4.17, but merely documented
new requirement in README, because there's certainly more
compat stuff to drop between 4.3 and 4.17, and README is
a useful list for things to kill. We'll get to 5.4 eventually.
Let's bump the kernel baseline a bit to 4.3 and thus require ambient
caps.
This allows us to remove support for a variety of special casing, most
importantly the ExecStart=!! hack.
In 2014, systemd started choosing fq_codel as the default_qdisc in order to fight internet bufferbloat.
e6c253e363fa98c99ea7
While the subsequent change made this change no longer trigger warnings if fq_codel wasn't present, it is still recommended to have this enabled. Add the necessary kernel configuration to the documentation.
We already use __VA_OPT__ in multiple places, which was introduced in
gcc 8 [0], so let's bump the baseline to reflect that. I chose gcc 8.4,
as that was the lowest 8.x version I could easily get my hands on when I
verified this (on Ubuntu Focal with the gcc-8 package).
Closes: #31191
[0] https://gcc.gnu.org/gcc-8/changes.html
Let's replace the "compat" module in our proposed nsswitch.conf
configuration with "files", since it is not 1995 anymore.
Fedora and other distros have deprecated and removed NIS support a while
back. While others still retain some support I am not sure we should
advertise it in our examples. Downstream can of course still use
"compat" instead of "files" if they want to, but let's not confuse
people who don't care about NIS anymore with this.
Also, bring the nsswitch.conf snippet in README in line with what our
man pages say.
Also see: https://fedoraproject.org/wiki/Changes/retire_NIS_user_space_utils
static versions of libsystems.so are not really supportable, and
encourages mix&match which we cannot really support. Make the wording
about this stronger in the README, since people apparently don'd read to
the last paragraph.
libpython was added in 2cc86f094a, it seems
because of python-systemd module that we built. But libpython by itself
is not enough for actual python programs, and now we also list python itself,
so let's drop libpython from the list.
meson requires >= 3.7. We have CI that runs on CentOS8 with Python 3.6, but
let's not provide official support for an EOL Python version. Individual
distributions can provide backports, but we don't need to mention that in
the user-facing docs. According to [1], 3.7 is on life support and 3.6 is EOL.
[1] https://devguide.python.org/versions/
This adds back sd-boot builds by using meson compile targets directly.
We can do this now, because userspace binaries use the special
dependency that allows us to easily separate flags, so that we don't
pass anything to EFI builds that shouldn't be passed.
Additionally, we pass a bunch of flags to hopefully disable/override any
distro provided flags that should not be used for EFI binaries.
Fixes: #12275
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we
would enable if the valgrind headers were found. The operations then we be
conditionalized on RUNNING_UNDER_VALGRIND.
But in a few places we had code which was conditionalized on VALGRIND, i.e. the
config option. I noticed because I compiled with -Dvalgrind=true on a machine
that didn't have valgrind.h, and the build failed because
RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that
the header is present if the option is set, but it seems better to just remove
the option. The code to support valgrind is trivial, and if we're
!RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under
valgrind is always some special testing/debugging mode, so we should just do
those extra steps to make valgrind output cleaner. Removing the option makes
things simpler and we don't have to think if something should be covered by the
one or the other configuration bit.
I had a vague recollection that in some places we used -Dvalgrind=true not
for valgrind support, but to enable additional cleanup under other sanitizers.
But that code would fail to build without the valgrind headers anyway, so
I'm not sure if that was still used. If there are uses like that, we can
extend the condition for cleanup_pools().
We already depend on the skeleton APIs introduced in libbpf 0.7 so
let's bump our minimum version to reflect that.
We don't enforce bpf compilation on mkosi anymore since not all
distros have sufficiently up-to-date libbpf available.
We had a description in README, and an outdated list in the man page.
I think we should keep a reference-style list in the man page. The description
in README is more free-form.
* Avoid traling slash as most links are defined without.
* Always use https:// protocol and www. subdomain
Allows for easier tree-wide linkvalidation
for our migration to systemd.io.
