docs/generic-kernels: clarify requirements, guidance for adding options
Here are some things I noticed while adding options to generic kconfig, that I think would have been helpful for me to know ahead of time. Signed-off-by: Clayton Craft <craftyguy@postmarketos.org> Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9163>
This commit is contained in:
parent
235160c20c
commit
77a6de8660
1 changed files with 29 additions and 11 deletions
|
|
@ -51,8 +51,7 @@ only exist for grouping things together, no filtering is performed, so don't
|
|||
think too much about it.
|
||||
|
||||
If this configuration option was only added recently, find out since when it
|
||||
exists in Linux. Also, make sure to check whether it can be enabled on all
|
||||
architectures or only on select few.
|
||||
exists in Linux.
|
||||
|
||||
You can then add to `kconfig-generic.toml`:
|
||||
|
||||
|
|
@ -64,16 +63,35 @@ VIDEO_OV8856 = "m"
|
|||
This would result in `CONFIG_VIDEO_OV8856=m` being set for all generic kernels
|
||||
newer than 6.12-rc1 and enable it on all architectures.
|
||||
|
||||
If a lot of unrelated configs are being changed, make sure to split the
|
||||
changes into separate GitLab MRs according to what they are for. For
|
||||
example: don't combine enabling a WiFi driver for a device with also
|
||||
enabling generic cryptography configs.
|
||||
Before submitting your change in a GitLab MR for the generic kernel maintainers
|
||||
to review, make sure:
|
||||
|
||||
You can submit your change in a GitLab MR for the generic kernel maintainers to
|
||||
review. Please do **not** regenerate the kernel configurations; your change
|
||||
will be included as part of the next kernel upgrade. Rebuilds of the kernel
|
||||
packages take a long time and they get updated regularly, so you'll only need
|
||||
to wait a few days until your change makes it into the released binaries.
|
||||
- Architecture scoping is as broad as possible. The default should be `"all"`
|
||||
unless there is a specific reason to restrict it to one architecture. For
|
||||
example, `CONFIG_PINCTRL_AMD` only makes sense on `x86_64`, but a config
|
||||
option like `CONFIG_I2C_DESIGNWARE_CORE` is not architecture-specific and
|
||||
should use `"all"`. When in doubt, prefer `"all"`.
|
||||
- Each option is not already enabled or pulled in by a dependency in the
|
||||
existing config. Check the Kconfig dependency chain in the Linux kernel
|
||||
source. If an option you are already enabling selects another option via
|
||||
`select` in Kconfig, adding the selected option explicitly is redundant. You
|
||||
can check dependencies using `make menuconfig` or by reading the relevant
|
||||
`Kconfig` files.
|
||||
- Device drivers are set to `"m"` (built as modules). Subsystem infrastructure
|
||||
and platform or bus dependencies that are prerequisites for drivers (for
|
||||
example, `I2C_DESIGNWARE_CORE` or `PINCTRL`) should be set to `"y"` instead.
|
||||
- Categories in the file are sorted alphabetically.
|
||||
- Unrelated config changes are split into separate MRs. For example, don't
|
||||
combine enabling a WiFi driver for a device with also enabling generic
|
||||
cryptography configs. A single MR with multiple configs is fine as long as
|
||||
they are related, for example all the drivers needed for one device.
|
||||
- You have run `pmbootstrap kconfig generate` for all supported architectures
|
||||
and verified that your options appear in the generated configs.
|
||||
|
||||
Please do **not** regenerate the kernel configurations; your change will be
|
||||
included as part of the next kernel upgrade. Rebuilds of the kernel packages
|
||||
take a long time and they get updated regularly, so you'll only need to wait a
|
||||
few days until your change makes it into the released binaries.
|
||||
|
||||
## Policy for patches
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue