Introduces system_dlkm_fs_types list attribute for the
kernel_images rule to build the system_dlkm partition
images for all filesystem provided in the list.

Deprecates the system_dlkm_fs_type but gives it priority
for backward compitability resons.

Behavior based on values of system_dlkm_fs_type &
system_dlkm_fs_types:

    Both specified: Fail with deprecation message
    Both not specified: system_dlkm.img with ext4
	This is same as current default behavior when
	system_dlkm_fs_type is not specified.
    system_dlkm_fs_type="fs": system_dlkm.img with given fs
	This is same as current behavior.
    system_dlkm_fs_types=[list_of_filesystems]: system_dlkm.fs.img
	for each file system type in list_of_filesystems

Bug: 297407875
Test: TH, Manual with all permutations & combinations
Change-Id: Ie8ee880dbbc41576603a1ab1b56f0307a6ab2e90
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>

This ensures that these extensions, which are implementation
details of Kleaf, doesn't get loaded outside of kleaf.

The public symbols are re-exported in kernel.bzl.

If this breaks a build, one may use
--nocheck_bzl_visibility to temporarily disable
the check.

Also fix buildifier warnings.

gki_artifacts.bzl are not included in this change due to an internal usage.

Test: TH
Bug: 283857454
Change-Id: If8139982e0e55a72729fbc058ec99965d069195e

William McVicker authored 1 year ago and William McVicker committed 1 year ago

If `vendor_dlkm_archive = True` is set, then the tarball
`vendor_dlkm_staging_archive.tar.gz` is created. This can be used to
easily get the vendor_dlkm modules without have to mount the vendor_dlkm
ext4 image.

Bug: 281621377
Change-Id: I28023de9c42243f3859078f9e424c84cf7400769

After this change, if dedup_dlkm_modules is set:

- When building vendor_dlkm, the staging directory from
  system_dlkm is extracted to MODULES_STAGING_DIR beforehand,
  so that depmod can find them. This allows modules from
  vendor_dlkm to link to modules from system_dlkm.
- system_dlkm.modules.load is concatenated to $DIST_DIR/modules.load
  (after modules.load from vendor_boot) so that the list of modules
  from system_dlkm are excluded from vendor_dlkm.modules.load list.

This means that after this change, if dedup_dlkm_modules is set
for a build, a device effectively enables the feature that allows
vendor_dlkm modules to depend on system_dlkm modules.

If dedup_dlkm_modules is set, additional changes are required
on the device so that userspace loads system_dlkm modules before
loading vendor_dlkm modules.

Note that even with this change, vendor_boot modules and
system_dlkm modules themselves (the *.ko files) aren't excluded
from vendor_dlkm.img built from the kernel source tree if
vendor_dlkm_modules_list specifies .* (all modules). They are only
excluded from modules.load. However, the images from the kernel
source tree are for development purposes. It is expected that
the system_dlkm / vendor_dlkm images are built from the platform
source tree, excluding modules not in the corresponding modules.load
file.

A subsequent optimization would be to exclude vendor_boot / system_dlkm
modules from this "debug" vendor_dlkm image built from the kernel
source tree. This optimization is not covered by this change.

Bug: 272523944
Bug: 272525097

Change-Id: I86197ed03bc32563399f69e8f93eaefc585a9464

Enable users to pass in etc files that need to be installed to
vendor_dlkm.img /etc folder.

Bug: 270603150
Bug: 271443724
Test: build kernel and check vendor_dlkm.img and dist folder

Change-Id: I63a2f348ced7681180e26647bfdb3d4c09de735b

system_dlkm and vendor_dlkm can be ext4 or erofs images
as these are supported read only filesystem in platform
builds.

Add an option to choose between ext4/erofs for these
partitions for the kernel's development only images to
match patform choices with ext4 as the default if choice
is not provided.

Choice will be passed as environemental variables to build_utils.sh:
SYSTEM_DLKM_FS_TYPE=["ext4" | "erofs"] for build_system_dlkm_image
VENDOR_DLKM_FS_TYPE=["ext4" | "erofs"] for build_vendor_dlkm_image

Bug: 261617174
Bug: 232430739
Test: TH
Change-Id: I4a37e9d0116bb4b2f38fc119011a441d7c73e9f7
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>

* This is in favor of declaring the setup using Kleaf.
* This should have a lower impact as in both cases the
 default is always `//tools/mkbootimg:mkbootimg.py`

Bug: 260776236
Change-Id: I462894827e8b3fef8bbb1f9a23b35eb43e475cdf
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>

Building the boot image does not necessary require
the existence of initramfs.

Test: TH
Bug: 260031024
Change-Id: I06f3cab03066009c5d4ccad30392e5b2dfb8d858

Bug: 260012551
Change-Id: Ie6ebe4f3c239eb43b8565973979d07c43e1a647a
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Alistair Delva <adelva@google.com>

* For backwards compatibility, options provided trough
  `kernel_image` rule will take precedence over the
  ones specified in build.config.

Bug: 236012223
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
Change-Id: I6f26ee12ffd1e9198fdeef4f794780de2188cc64

* This is so kleaf support natively the following configs:
  * LZ4_RAMDISK
  * LZ4_RAMDISK_COMPRESS_ARGS

* The options are still falling back to the config values.

Bug: 236012223
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
Change-Id: Iac60252b368da1f06ef3b49b3fb372dd729e9aea

* Buildifier provides linter recommendations when
 `--lint=warn` is used, so adding the ones for
 these  files before working with them so the
 cleanup changes are separated from the actual
 changes.

Bug: 236012223
Bug: 252888476
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
Change-Id: I5d1c5a8bfd99d2efbe8f32420225507ac8296d31

This passes things like visibility and tags to internal targets.

Test: TH
Bug: 244786402

Change-Id: I28a33f7d1351d031fdc04336f6077a9bf3023529

vendor_kernel_boot.img would leave empty in the field of bootconfig.
Only copy vendor-bootconfig.img when building vendor_boot.img to avoid
building error.

Bug: 236355852
Signed-off-by: Lucas Wei <lucaswei@google.com>
Change-Id: I3569568801e953d52285640109a18e61714faaaa

system_dlkm_image produces staging_archive and modules.load
files. Also download them and put them as part of distribution
when building against downloaded prebuilts.

With system_dlkm_staging_archive.tar.gz from GKI
piped to the device's system_dlkm rule, instead
of creating the staging directory, unarchive the archive
and build system_dlkm from there.

As part of this change, kernel_images now also
accept these arguments:
- system_dlkm_modules_list
- system_dlkm_modules_blocklist
- system_dlkm_props

... which corresponds to the upper-case version of the build configs,
respectively. Their semantics are the same as the build configs.
Unlike vendor_dlkm_*:
- system_dlkm_modules_list falls back to modules_list if not set
- system_dlkm_modules_blocklist falls back to modules_blocklist if not set

Test: build slider_images_system_dlkm_image with build_system_dlkm=True
Bug: 233401974
Bug: 238786592

Change-Id: Ie9a2073d571b23eee58764ef9ced0976e5fa9622
Signed-off-by: Yifan Hong <elsk@google.com>

Unlike MODULES_OPTIONS in build.sh, modules_options in
Kleaf points to a file that contains the lines.

Fix comments and build rules that previously assume
it contains strings.

Test: bazel test //common:kernel_aarch64_tests
Fixes: 241162984
Change-Id: Ie3ab2544f91cbcec55e5af390fc06eba400add14

The filesystem format is an implementation detail.

Test: none
Change-Id: I241b038760b6d5bdb9104f0282cadb601a500110

After we supporting build vendor_kernel_boot image for kernel
artifacts, we should also update file name of *.modules.load
with its related image name.

Bug: 234554094
Test: TH
Change-Id: Ia78f318bfe7a203046ca479c92d4f26947b09402
Signed-off-by: Yifan Hong <elsk@google.com>

This makes kernel.bzl smaller.

Test: TH
Test: bazel build //common:kernel_aarch64_dist //gs/google-modules/soc-modules:slider_dist --nobuild
Test: bazel build //build/kernel/kleaf:docs
Bug: 233156052
Change-Id: I28ba7ca430070b57267079e24ebe0e1477f0d9fc
Signed-off-by: Yifan Hong <elsk@google.com>