Are there methods to move lots of tri-state symbols from built-in to modules in the kernel dot config file?

I have a kernel dot config file that produces a working kernel that I can use to boot one of my machines. I would however like to move lots of drivers from builtin to modules. I don't want everything to be modules, because I would like to boot without having to use a initram that contains modules. I understand this means that hard drive and other drivers must be builtin. In addition I have created short list of a few drivers I would like builtin. Other than under those categories, I would like most other things to be modules such as sound card, Ethernet, Frame buffer.

In the config file, I am only interested in turning symbols set at "=y" to symbols set at "=m". The lines that are "=n" I wish to leave as "=n". I have some ideas how I can run "make xconfig" and go on a hunt and destroy mission, but that seems labor intensive. What might help is to have an automation that will look at symbols that lie under a submenu and change those to "=m"

From what I understand,, "make allmodconfig" will turn both "=y" and "=n" into "=m" where as I want "=n" to remain "=n". Also From what I understand, "make localmodconfig" will only effect symbols that are already set to "=m".

::Background::
I am moving from a discontinued longterm stable kernel to 4.9.X LTS. I am currently experimenting with configuration files. I would like to build a kernel that I will use on a few wintel computers. They use different sound, video and networking hardware.

Do you have any suggestions that could make the task easier and less dependent on searching by hand?

Unless you intimately understand the make dependencies, labour intensive is the way to go. Dicking with the .config directly is definitely off the radar.

IMHO only.

Especially as you cannot know which ones of those =y config file options DO have a =m alternative, there are a lot that only have =n as the other choice.
And quite a lot of those modules would get loaded in all cases anyway, so there's no memory saving BY making them into a module instead of built-in.

I was hoping there was some sort of automated or simi-automated way to make the change, rather than manually changing the .config directly. At this point, it is more of an aside as to how well the "make oldconfig" can repair a .config file that has been set to an untenable state. Many years ago, I did create a python script that took two .config files and merged them, but the two files were different in very slight ways. I was able able to compile the kernel without a hitch. Again the changes were only minor, and I used "make oldconfig" and "make xconfig" to warn me of an untenable state.

It looks like I will use the more laborious method of boot the computer with a live distro. Armed with a list of modules, I will hunt the "make xconfig" to see what can be formed into modules.

I considered running "make allmodconfig" and comparing the .config to the .config I am using, but to make the comparison in any meaningful way I don't think would be worth the time.

I suppose it depends on how well the original kernel configuration was trimmed to work on the computer it runs on. If the modules never get loaded in the first place, or many of the modules rarely get loaded that can produce a less portly kernel. Also, I have more than one computer with different sound cards and other hardware I wish to modularize the drivers for. In my case, I started with a somewhat generic configuration. I was able to go from 4.9 LTS kernel that was 6.1MB in size down to 3.7MB. With nostalgia, I look at a 2.2MB 3.4.X kernel on my HD. I suppose it is sort of old school to worry about kernel size in an age when computers with less than 4GiB are considered obsolete.



Contrary to my previous statement, I decide it was worth the time to compare my kernel to a "make allmodconfig" config file.

The idea is to make an allmodconfig file then compare the =m in that file to the =y in your file to create a file if what is common. I was able to look through "cfg-common-list.txt" and research symbols using "make xconfig". Many of which I was able to change.

Here is a step by step outline to help anyone in the future who finds this thread searching the archive.