Draft: Add script for final config generation from debian and GL

[SujanaSubr]

What this PR does / why we need it:
Includes scripts

1. Generate final config from debian and GL taking version from prepare_source as input
2. Compare script which renders difference in 2 input config files
   Which issue(s) this PR fixes:
   Fixes #

Special notes for your reviewer:

Release note:

[SujanaSubr]

1. get_config.sh Script uses same logic as github workflow in package-build / package-linux so it will be easier to integrate in github workflow easily in future if required to maintain config files for older versions
2. To compare config files, there is already a diffconfig script available in torvalds linux repo. We can use either diffconfig from torvalds repo or custom config.

Example output from custom script

REMOVED:
CONFIG_ACPI_EC_DEBUGFS=y
CONFIG_ACPI_VIOT=y
CONFIG_BCACHEFS_FS=m
CONFIG_BCACHEFS_POSIX_ACL=y
CONFIG_BCACHEFS_QUOTA=y
CONFIG_BCACHEFS_SIX_OPTIMISTIC_SPIN=y
CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y

ADDED:
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_EFI_COCO_SECRET=y
CONFIG_EFI_SECRET=m
CONFIG_KERNEL_LZ4=y
CONFIG_MD_LINEAR=m
CONFIG_SCSI_DH=y

CHANGED:
CONFIG_LSM: landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf,ipe -> landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf
CONFIG_VIRTIO_CONSOLE: y -> m
CONFIG_ZRAM_DEF_COMP: lz4 -> zstd

Example output from torvalds repo

-ACPI_VIOT y
-BCACHEFS_DEBUG n
-BCACHEFS_ERASURE_CODING n
-BCACHEFS_LOCK_TIME_STATS n
-BCACHEFS_NO_LATENCY_ACCT n
-BCACHEFS_PATH_TRACEPOINTS n
-BCACHEFS_POSIX_ACL y
-BCACHEFS_QUOTA y
 ACPI_EC_DEBUGFS y -> n
 BCACHEFS_FS m -> n
 CPU_FREQ_DEFAULT_GOV_PERFORMANCE n -> y
 CPU_FREQ_DEFAULT_GOV_SCHEDUTIL y -> n
 CRYPTO_DH_RFC7919_GROUPS y -> n
 DAMON y -> n
 DMABUF_HEAPS y -> n
 DM_VDO m -> n
 EFI_COCO_SECRET n -> y
+SCSI_DH_ALUA m
+SCSI_DH_EMC m
+SCSI_DH_HP_SW m
+SCSI_DH_RDAC m
+VBOXSF_FS m
+ZRAM_DEF_COMP_LZO n
+ZRAM_DEF_COMP_LZORLE n

[fwilhe]

at least on mac with podman I need to provide the full path for package-linux

using $PWD/package-linux works when I'm in the parent dir of package-linux

[fwilhe]

Very nice!

Just thinking out loud: Could we package the script in a container based on the debian-snapshot container to make it easier to use?

It would be nice if usage was as simple as podman run kernel-config-diff with some arguments.

[fwilhe]

what does 'none' mean in this context?

I think it would be good to have more speaking file names

kernel_config_debian_(architecture)_(variant)
and
kernel_config_gardenlinux_(architecture)_(variant)

or something similar.

Also, please add the kernel version and the debian ref to the filename to clearly indicate that, very useful for comparing over time.

[SujanaSubr]

Very nice!

Just thinking out loud: Could we package the script in a container based on the debian-snapshot container to make it easier to use?

It would be nice if usage was as simple as podman run kernel-config-diff with some arguments.

Yes agree, I was thinking to add that in the script itself (podman start inside the script). We will discuss and confirm this

[fwilhe]

Yes agree, I was thinking to add that in the script itself (podman start inside the script). We will discuss and confirm this

Not a super important requirement, but just thinking about making this nicer and easier to use:

Could we write it in a way that we don't need to run this from a local checkout of the package-linux repo? We could either clone the repo as part of the script, or bake it into the image directly. I think it would be nice if I could 'just' run the container with one volume mounted for the output files and with no other pre-conditions.

We can keep a 'developer' option to run it from inside the repo with more flexibility if that makes sense.

[fwilhe]

is it required to use the architecture specific tag? just using latest should work too, right? it should select the right architecture based on the host machine.

[SujanaSubr]

Yes, if we build for the same architecture then yes we do not need arch here. If we will have to build for arm64 in x86 machine then we need this specifically. Anyways I will wrap the container call to make it simple once we finalize the way we proceed. Then I will have arch as an argument and podman will start automatically

[fwilhe]

this repo is large and a full clone is not needed here. this can be way faster if we take only the latest commit of our desired tag/branch using

git clone --depth=1 --branch=debian/6.12.43-1 https://salsa.debian.org/kernel-team/linux.git

[fwilhe]

compare the sizes of the cloned directories. Also it is now just a matter of seconds instead of taking almost two minutes.

$ du -sch linux
1.3G	linux
1.3G	total
$ du -sch linux-small
 12M	linux-small
 12M	total

[fwilhe]

I think we can get around all this makefiles by directly using the kconfig.py script

example usage:

debian/bin/kconfig.py output ~/SAPDevelop/github.com/gardenlinux/package-linux/config/config.cloud ~/SAPDevelop/github.com/gardenlinux/package-linux/config/config.gardenlinux

We might have to maintain the list of arguments for different architectures/flavours, but we could get rid of quite some complexity in the script, I think. @SujanaSubr can you confirm that this works?

the nice thing is that this script even works on my mac, no dependency on debian at all.

[SujanaSubr]

I think we can get around all this makefiles by directly using the kconfig.py script

example usage:

debian/bin/kconfig.py output ~/SAPDevelop/github.com/gardenlinux/package-linux/config/config.cloud ~/SAPDevelop/github.com/gardenlinux/package-linux/config/config.gardenlinux

We might have to maintain the list of arguments for different architectures/flavours, but we could get rid of quite some complexity in the script, I think. @SujanaSubr can you confirm that this works?

the nice thing is that this script even works on my mac, no dependency on debian at all.

"debian/build/config.amd64_none_cloud-amd64" from "rules.gen" use kconfig.py , This way we do not have to consolidate the config file ourselves (which makes it less error prone) But I tried this already as discussed earlier, and the output config has difference (not only the build dependency) when compared to config from debian built image. I hope @5kt can confirm what I miss here. If we could do this then we do not need src files from linux kernel repo and the script will be minimal.