Add more detailed maintainer notes under README.md (oldconfig->defconfig->oldconfig)
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 1.6k
- Forks
- 211
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 6
Description
Discussed off channel (again) :
As of today, both linux and coreboot configs under config/* are kept as oldconfigs.
Helpers were added under both modules/linux and modules/coreboot to switch from oldconfig<->defconfig.
Those helpers can be used through:
- `make BOARD=BOARD (coreboot/linux).save_in_defconfig_format_in_place`
- `make BOARD=BOARD (coreboot/linux).modify_and_save_oldconfig_in_place`
Why we currently keep configs as oldconfig:
- switching from oldconfig (in tree) to defconfig is currently helpful to spot the deviations against upstream used fork defconfig (the upstream default)
- doing a version bump and then using modify_and_save_oldconfig_in_place helper will show all configs changes through `git diff`
----
Real life example to show importance #1723 showed:
- Switching back to defconfig for nv41 currently used coreboot fork shows:
```
user@localhost:~/heads$ cat config/coreboot-nitropad-nv41.config
CONFIG_USE_OPTION_TABLE=y
CONFIG_BOOTSPLASH_IMAGE=y
CONFIG_BOOTSPLASH_FILE="@BRAND_DIR@/bootsplash.jpg"
CONFIG_BOOTSPLASH_CONVERT=y
CONFIG_BOOTSPLASH_CONVERT_QUALITY=90
CONFIG_VENDOR_NOVACUSTOM=y
CONFIG_MAINBOARD_VERSION="v2.1"
CONFIG_CBFS_SIZE=0x1000000
# CONFIG_CONSOLE_SERIAL is not set
# CONFIG_POST_IO is not set
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Nitrokey"
CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="Nitropad NV41"
CONFIG_IFD_BIN_PATH="3rdparty/dasharo-blobs/novacustom/nv4x_adl/descriptor.bin"
CONFIG_ME_BIN_PATH="3rdparty/dasharo-blobs/novacustom/nv4x_adl/me.bin"
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_HAVE_IFD_BIN=y
CONFIG_BOARD_NOVACUSTOM_NV4X_ADLP=y
CONFIG_TPM_MEASURED_BOOT=y
CONFIG_LINUX_COMMAND_LINE="quiet loglevel=2"
CONFIG_POWER_STATE_OFF_AFTER_FAILURE=y
CONFIG_IFDTOOL_DISABLE_ME=y
CONFIG_HAVE_ME_BIN=y
CONFIG_INTEL_ME_DISABLED_HAP=y
CONFIG_BOOTSPLASH=y
CONFIG_PCIEXP_HOTPLUG_PREFETCH_MEM_BELOW_4G=y
CONFIG_PCIEXP_HOTPLUG_IO=0x2000
# CONFIG_RESOURCE_ALLOCATION_TOP_DOWN is not set
CONFIG_PAYLOAD_LINUX=y
CONFIG_PAYLOAD_FILE="@BOARD_BUILD_DIR@/bzImage"
CONFIG_LINUX_INITRD="@BOARD_BUILD_DIR@/initrd.cpio.xz"
```
- As per #1723 unification attempt, it was thought that `# CONFIG_RESOURCE_ALLOCATION_TOP_DOWN is not set` should be enabled instead.
- Enabling with https://github.com/linuxboot/heads/pull/1723/commits/49e37e11783a0f16028248bdfab30ce211179322 cause my nv41 to brick.
- https://github.com/linuxboot/heads/pull/1723/commits/49e37e11783a0f16028248bdfab30ce211179322 reverted changes back to master.
This shows that coreboot changes in defconfigs
- should be thorrougly tested by coreboot/heads forks maintainers (not Heads job)
- changes in oldconfig from version bumps also need to be reviewed and thoroughly tested
- unification of changes as per #1723 attempt cannot happen without risks
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review README.md and the existing maintainer guidance, then use the oldconfig and defconfig helpers under modules/linux and modules/coreboot as context. Document why configs remain under config/* as oldconfigs, how to use the two make commands, and the review and testing risks illustrated by #1723. Done means the README clearly explains this workflow and its cautions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 64/100