This commit adds the pcimem tool.
pcimem is a simple method of reading and writing to memory registers on a PCI card.
Compared to pkgs.devmem2, it does not work on the total memory space
of the machine but restricts access to just one PCI resource.
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
This ensures that all the features that are implemented via dlopen(3)
are available (or explicitly deactivated) by pointing dlopen to the
absolute store path instead of relying on the linkers runtime lookup
code.
All of the dlopen calls have to be handled. When new ones are introduced
by upstream (or one of our patches) those must be explicitly declared,
otherwise the build will fail.
As of systemd version 247 we've seen a few errors like `libpcre2.… not
found` when using e.g. --grep with journalctl. Those errors should
become less unexpected now.
There are generally two classes of dlopen calls. Those that we want to
support and those that should be deactivated / unsupported. This change
enforces that we handle all dlopen calls explicitly. Meaning: There is
not a single dlopen call in the code source tree that we did not
explicitly handle.
In order to do this I introduced a list of attributes that maps from
shared object name to the package that contains them. The package can be
null meaning the reference should be nuked and the shared object will
never be loadable during runtime (because it points at an invalid store
path location).
libjack2 doesn't cross-compile, see
https://github.com/NixOS/nixpkgs/issues/96548.
The pulseaudio NixOS module uses pkgs.alsaPlugins to create its
asound.conf, so let's make sure that one can be built when
cross-compiling.
As per the in-line comment, this is where distros should configure it.
Not via kernel command line parameters.
As found by looking at the implementation, while exploring the cause of
a bug on the Raspberry Pi 4, it was found that `cma=` on the command
line parameters will overwrite the values a device tree will have
configured for a given platform.
With this, the more recent 5.4 vendor kernel boots just fine on the
Raspberry Pi 4 using our common configuration.
