With this option set, module text and rodata memory areas will be made
read-only. Moreover, non-text memory will be made non-executable. This
provides protection against certain security exploits. Currently, this
option is implicitly enabled in Kconfig for most configurations where it
is possible to enable it. This commit enables the option by default
explictly for all supported targets (except marvell to keep it small)
When set, this generates crash dump after being started by kexec. Useful
for debugging purpose on ARM. As this is already enabled for other arch,
enable it for ARM, as well (except marvell to keep it small).
Nowadays, Raspberry Pi 2 and Rasberry Pi 3 works perfectly fine with
Debian (including the official kernel package or the userland). RPi 1
and RPi Zero have an SoC that contains an armv6-based CPU, this means
that it cannot work with an hardfloat ABI, that is armv7 based. So we
have to use the Debian armel userland for this reason. Both boards are
supported in the mainline linux kernel and not being supported in the
debian-kernel package is the only blocking point that prevent RPI 1 and
RPI Zero from being well supported in an official Debian distribution.
This commit add a new kernel flavour for enabling support for the both
platforms.
It is no longer possible to run the "setup" rules without a compiler,
because Kconfig symbols can depend on compiler properties. Add a way
to invoke just the first step of setup, which merges the kconfig files
and overrides together.
The lockdown code for arm64 currently fails to engage when in Secure Boot
mode. Seth Forshee noticed that this is because init_lockdown() checks
for efi_enabled(EFI_BOOT), but that bit doesn't get set until uefi_init()
is called.
These modules will end up in every installer build, one way or
another. Move them into kernel-image, which all other packages
depend on, so we can then split up the remaining PV drivers.
The previous version failed to build on alpha:
debian/virtio-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
debian/i2c-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
and sparc64:
debian/virtio-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
debian/nic-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
sparc64 was missing a i2c-modules package, but adding that just gets
it to the same state as alpha. On both architectures drm_kms_helper
is included in the virtio-modules package as a dependency of
virtio-gpu, and then i2c-core is included as a dependency of
drm_kms_helper.
I don't think it makes sense to make virtio-modules directly depend on
i2c-modules. (In fact I think virtio-modules was a mistake entirely.)
Instead, for all configurations that enable both DRM and virtio:
1. Add an fb-modules package if it doesn't already exist
2. Include drm and drm_kms_helper in it
The pata_macio and pata_mpc52xx drivers are built under drivers/ata so
don't need to be specifically included. (pata_macio is also currently
built-in for some reason.)
The bmac, ehea, ibmveth, ps3_gelic, spidernet, sungem, sungem_phy,
and sunhme drivers are built under drivers/net/ethernet so don't
need to be specifically included. pasemi_mac has been renamed to
pasemi_mac_driver, and is also under drivers/net/ethernet.
The ehea, ps3_gelic, and spidernet drivers then don't need to be
excluded on ppc64el.
Make the airport driver optional now, so that it doesn't need to be
excluded on ppc64el. I will move it to nic-wireless-modules next.
The a100u2w, ibmvscsi, mac53c94, mesh, and ps3rom drivers are built
under drivers/scsi so don't need to be specifically included.
The ps3rom driver then doesn't need to be excluded on ppc64el.
The ps3disk driver is a SATA driver not a SCSI driver, so add a
comment to explain why it's here.
The module lists for powerpc/powerpc64 are mostly the same as for
powerpc. Some of them are duplicates while some use #include.
Change the duplicates to use #include.
Enabling this symbol makes rmi4_core depend on the media/v4l2
subsystem which is not only weird but also results in duplicate
modules at kernel-wedge time.
These drivers depend on the corresponding net drivers, or at least
common modules built under drivers/net/ethernet, currently leading
to duplicate modules.
I don't want to resolve this by adding a dependency between
nic-modules and scsi-modules, as that would pull in both into
installer images that previously only needed one set of drivers. I
also don't want to add the common modules into kernel-image as that
would bloat all installer images. Instead, put the drivers in a new
package and we can work out which installer images should include it
later.
Build scsi-nic-modules for all architectures/flavours that build
scsi-modules using the common module list now.
Part of the section we move was moved upstream in 4.19.15 by commit
ae206a1a5e3a "kbuild: fix false positive warning/error about missing
libelf". Don't duplicate that section.
This will allow to get graphics support in VM instances right from
Debian installer phase.
(cherry picked from commit fb11c71e7c36b2e9abb7535e6c9c0ddbb8dc7c15)
While pycodestyle and pyflakes wrongly write error messages to stdout,
the unittest module has the opposite bug: it writes successful status
messages to stderr.
In order to access Azure's VMbus via /sys/vmbus, the corresponding
UIO module must be available.
Also enable VFIO for safe userspace device handling when the host
exposes a vIOMMU.
We use the default compiler provided by (cross-)build-essential for
userland, so the compiler build-dependencies are not needed when
the pkg.linux.nokernel profile is used.
Since commit f5f169ba99 "Split build rules for tools to allow
skipping them." these recursive makefiles are not used.
(debian/rules.d/Makefile can additionally install the top-level Kbuild
and Makefile, but that target hasn't been used since svn rev 18133
(version 3.1-1~experimental.1).)
Since commit f5f169ba99 "Split build rules for tools to allow
skipping them." debian/rules.d/Makefile is not used and the current
kernel's UAPI headers are not installed. This hasn't caused breakage
yet, probably because many tools have their own workaround using
include/uapi etc. directly, but could break backports builds at some
point.
Move the build of userland headers up into debian/rules.real and
make all tools build targets depend on it.
With the recent refactor, setting source: false in debian/config/defines
is no longer enough to disable the linux-source-$ver package build, as
dh_listpackages is used to determine what is built.
Do not add linux-source-$ver to d/control if it is disabled.
The REAL_VERSION and PACKAGE_NAME variables aren't defined at the
point where we use them to check whether the package is enabled.
Replace them with their intended expansions to avoid this problem.
Some new Loongson servers are using Aspeed BMC, which has an GPU.
Some other Loongson servers are using SM750 GPU instead of AMD's.
Since MIPS doesn't have a generic display driver like VESA, we need
to install sm750fb and (drm_)ast into Loongson's fb-moduels udeb package.
(cherry picked from commit 6fbe9f4e363b32a70adf391e6d74ae21c52f16b6)
The packages we should build are restricted by:
* Package configuration in debian/config (limits which binary packages are
included in debian/control)
* Architecture (specified per package in debian/templates/control.* and
then in debian/control)
* Build profile (specified per package in debian/templates/control.* and
then in debian/control)
The logic for these restrictions is currently repeated in
debian/rules.real, but sometimes it becomes inconsistent with
debian/control (as with my recent changes for libbpf).
dh_listpackages reads debian/control and filters it by the current
host architecture and build profiles, so that it reliably reports
which packages we should build.
Therefore:
* Replace the logic in debian/rules.real with checks for package names
in the output of dh_listpackages
* Remove the redundant flag variables passed by debian/rules and
debian/rules.gen
* Remove the special-casing of stage1 in debian/rules and
debian/rules.gen
Ben Hutchings
Vagrant Cascadian
Romain Perier
Salvatore Bonaccorso
Romain Perier
YunQiang Su
Marcin Juszkiewicz
dann frazier
Aurelien Jarno
Wookey
Hideki Yamane
Uwe Kleine-König
Luca Boccassi
Luigi Baldoni
Yves-Alexis Perez
YunQiang Su
Michal Simek