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.