# How to maintain an annotated kernel config?

## equaeghe

I'm using `make menuconfig` to configure my kernel (trying to keep it minimal) and carry over the config between versions using `make oldconfig`. I notice that I'm adding options/modules for different reasons, such as (i) required by the hardware, (ii) required by system software, (iii) required by some tool I may just be using for a short while. I'd like to avoid permanently getting stray options and modules selected mostly due to (iii). I think that I need some way to create an annotated kernel config, so that I can keep track of why I enabled the options/modules I enabled. Is there some standard approach to this? Is it compatible with `make menuconfig`? Are there tools better than `make menuconfig` (its searching/filtering functionality is really basic)?

----------

## fedeliallalinea

I've never thought about something like this but you could use git on the .config file and commit when you change something.

----------

## pa4wdh

I don't think there is a specific tool for the job, but git one that comes to mind ...

If git is too much you could always keep some copies of your kernel config.

Like this: config-<version>-<what's special>

For example, i have a used kernel 5.10.27 for some time and at some point i enabled the ftdi drivers, so i could have:

config-5.10.27-clean (with just the required basics)

config-5.10.27-fdti (where i enabled the ftdi drivers)

When you keep those you can always copy the config file to .config and go through the kernel build process again.

----------

## Goverp

I'd guess the engine that handles generating the kernel 

```
make <foo>config 
```

prompts could be modified to record and display specially-formatted comments in .config; perhaps with a flag (say change of colour, or a symbol such as "***" for command-line config, and a new Fkey/reserved key to call up the annotation).

That's probably in "make" programming language; I wear a crucifix and wash in garlic to keep that stuff away from me!

Something like:

Device Drivers  --->

   <*> ATA/ATAPI/MFM/RLL support (DEPRECATED)  --->

      --- ATA/ATAPI/MFM/RLL support (DEPRECATED)

      [ ]   Support for SATA (deprecated; conflicts with libata SATA driver)

      <*>   generic ATA/ATAPI disk support

!!![M]     ATA disk support     !!! Needed for my old foobar drive !!!

      [M]     ATAPI floppy support

      <*>   Include IDE/ATAPI CDROM support

      <*>   Include IDE/ATAPI TAPE support

            *** IDE chipset support/bugfixes ***

      <*>   generic/default IDE chipset support

            *** PCI IDE chipsets support ***

Something similar would be useful for portage world-set entries - though AFAIK there's no portage configurator... But a warning "you are removing a package that you included because of 'xxxx'" would be useful. About twice a year I think "why am I emerging that?" followed by "drat! that's why". This one's been remarked about before.

----------

## figueroa

I keep my notes in a text file in /usr/src/kernel.txt. Keeping it simple.

----------

## Jaglover

 *figueroa wrote:*   

> I keep my notes in a text file in /usr/src/kernel.txt. Keeping it simple.

 

Same here, only I do not use file extensions, left the habit with DOS. So it is /root/log for me. Practically the only file in /root, besides some hidden conf.

----------

## equaeghe

Many thanks for everyone's input!

Git for version control will be part of the solution, but I consider that a bit orthogonal to what I was still missing.

I've searched the web a bit more and found some interesting things:

 qconfig was a tool that allowed for file-based programmatic kernel configuration with dependency resolution, but is outdated/deprecated,

 Kernel Expect allows for file-based programmatic kernel configuration with dependency resolution and seems maintained and in working order.

Nevertheless, I did not choose at this point to go the Kernel Expect-route. I'm now trying out creating a custom Kconfig file in a similar way that the Gentoo kernel devs use to create Gentoo-specific options. This has the advantage that it is directly integrated with the existing configuration tools such as menuconfig/nconfig (which I like to use).

What I created for now is a file Kconfig.MyComputerID, which should be copied to /usr/src/linux and then integrated by adding the following at the end of /usr/src/linux/Kconfig

```
source "Kconfig.MyComputerID"
```

Then whatever I put in that file is added to, e.g., the menus visible with menuconfig. In that file, I've for now put

```
menu "MyComputerID selection (<my computer short hardware description>)"

config MYCOMPUTERID_GENTOO

   bool "Basic Gentoo support"

   

   default y

   

   select GENTOO_LINUX

   select GENTOO_LINUX_UDEV

   select GENTOO_LINUX_PORTAGE

   select GENTOO_LINUX_INIT_SYSTEMD

   select GENTOO_KERNEL_SELF_PROTECTION

   # select GENTOO_KERNEL_SELF_PROTECTION_COMMON is not available because PROC_KCORE, HIBERNATION, and MODIFY_LDT_SYSCALL are selected 

   select GENTOO_PRINT_FIRMWARE_INFO

   

   help

      The basic Gentoo-related selections for MyComputerID

endmenu

```

All the selected configurations become fixed when MYCOMPUTERID_GENTOO is selected (which I'll of course do). The structuring, title, help, and comment functionality of Kconfig files allow for ample documentation of the why of my kernel configuration.

Next up: defining config options for hardware (at least four separate ones, for built-in/modules and in-machine/peripheral), then options for software (when some software requires some modules or config, I can put it in one of those).

----------

## pa4wdh

This is a very neat solution equaeghe, nice!

----------

## pietinger

 *equaeghe wrote:*   

> What I created for now is a file Kconfig.MyComputerID, which should be copied to /usr/src/linux and then integrated by adding the following at the end of /usr/src/linux/Kconfig
> 
> [...]
> 
> Next up: defining config options for hardware (at least four separate ones, for built-in/modules and in-machine/peripheral), then options for software (when some software requires some modules or config, I can put it in one of those).

 

I have known this before (because of playing with /usr/src/linux/distro/Kconfig) and its really nice, but ... you cant disable some kernel settings with a Kconfig file - only enable something ...  :Sad: 

----------

## equaeghe

 *pietinger wrote:*   

> […] you cant disable some kernel settings with a Kconfig file - only enable something ... 

 

True. But you can add a negative dependency, so that a certain option is not allowed. Because this may give dependency conflicts too easily according to my tastes, I add a message that depends on the option, so that in menuconfig and the like, it is clearly visible if a certain undesirable option is enabled.

A remaining downside is that choices and values cannot seem to be specified in the Kconfig language.

----------

## pietinger

 *equaeghe wrote:*   

> A remaining downside is that choices and values cannot seem to be specified in the Kconfig language.

 

Yes, we have this with KSPP. But as far as I can see, it seems our Gentoo developer have also patched other Kconfig file to get desired values in there (CONFIG_DEFAULT_MMAP_MIN_ADDR).

----------

