# Why are kernel config options deselected in new versions?

## srunni

Hi,

Does anyone know why kernel options that are enabled in one version of the kernel .config are disabled in the next version? Why isn't there a script in place to check these things and fix them? It seems that every time, FUSE, ethernet, ATI driver support, and a few others are disabled.

Thanks!

----------

## AllenJB

For different versions of the kernel, you need to explicitly copy your existing config over. The configuration is stored in the .config file in the kernel source base directory (the directory that /usr/src/linux symlinks to for the current version).

You need to copy the .config file, then run "make oldconfig", which will attempt to account for moved / renamed options and ask you about any new options.

My procedure for a new kernel is:

```

rm linux.prev

mv linux linux.prev

ln -s linux <new kernel>

cd linux

cp ../linux.prev/.config ./

make oldconfig

```

Then the usual procedure to compile and install the kernel.

----------

## krinn

the question is why a kernel should have these options enable? because it suits you, nah i don't care the ATI option personnaly...

and there's already a script that do it for you, the "make" from your kernel got many options and can import your old kernel config to keep up your favorites kernel options checked.

----------

## arch_dude

Here is the "WHY:" The Gentoo developers do not think of the kernel as a typical package. When you emerge an get a new kernel, you are getting a copy of the new kernel source, but you are not replacing the old one. Furthermore, by contrast to almost all other packages the emerge does not attempt to build the kernel and certainly does not attempt to install it. There are strong arguments in favor of this philisophy, but for the purpose of this discussion, please that it as given: The emerge of the kernel merely adds a new kernel source tree to your collection of kernel source trees. After that, you are on your own to use it properly.

As to the "how", the earlier answer shows how to use "make oldconfig" for the normal user and the normal usage of a new kernel source tree. The reason that Gentoo does not automate this is that there are a lot of other ways that kernel source trees are used, such as when cross-compiling for an embedded system.

----------

## srunni

I know about make oldconfig and use it, but according to the kernel upgrade guide, it can only be used for upgrading from one Gentoo kernel revision to another. That means that when you upgrade, for example, from 2.6.28 to 2.6.29, you can't do that.

 *krinn wrote:*   

> the question is why a kernel should have these options enable? because it suits you, nah i don't care the ATI option personnaly...

 Read what I wrote again. I don't want them to be enabled by default. I want a script to check if they were enabled in the previous version of the kernel, and if so, enable them. I basically want make oldconfig to work for moving from one kernel version to another.

 *arch_dude wrote:*   

> The reason that Gentoo does not automate this is that there are a lot of other ways that kernel source trees are used, such as when cross-compiling for an embedded system.

 OK, but that is an edge case. What I'm referring to is a very common use case. Why isn't there some script (official or unofficial) that gives the option to automate this process? I'm not saying the script has to be enabled by default.

----------

## 96140

--Last edited by 96140 on Wed Sep 11, 2013 8:50 am; edited 1 time in total

----------

## pappy_mcfae

 *srunni wrote:*   

> I know about make oldconfig and use it, but according to the kernel upgrade guide, it can only be used for upgrading from one Gentoo kernel revision to another. That means that when you upgrade, for example, from 2.6.28 to 2.6.29, you can't do that.

 

That isn't completely true. You can use make oldconfig to transition from one version to the next, and even jump numerous family versions, in an up or down direction. Because of the continuous reorganization of the kernel source, any attempt to use make oldconfig should be followed immediately by make xconfig (or make menuconfig or make gconfig), to make sure your transition was successful. You will wind up with some mismatch errors. In general, these are more annoyances than real problems.

As far as finding out what was used previously, make xconfig in the old and new kernel source directories, and do it manually. By the time you could whip up a script to do this, you'd be a lot farther ahead doing things manually. Keep it simple.

And, if you decide you want to start fresh, try one of my kernel seeds.

Blessed be!

Pappy

----------

## overkll

Pappy, your such a seed pusher.   :Laughing: 

----------

## pappy_mcfae

Who me? :eyes flutter:

Blessed be!

Pappy

----------

## srunni

 *nightmorph wrote:*   

> Because no one's written such a script yet. Much less submitted it to the kernel team for review and possible inclusion.

 Out of curiosity, do any other distributions use such a script?

 *nightmorph wrote:*   

> One of the reasons why no one's written such a script is that it's just about impossible. Between kernel releases, many features end up being renamed or otherwise altered so that the old answer is no longer valid. CONFIG_FOO becomes CONFIG_BAR; it's not an easy copy. Or the options get moved around, or even dropped entirely. Or what used to be a single boolean choice becomes a Y/M/N option, with required subsections if Y or M is selected. I'm thinking in particular about the Intel HDA config; it's gone through this process. So have other config options.

 I'm not suggesting that the script will be entirely without user input, just that the tedious process of comparing the menuconfig's for the two versions could be reduced/simplified.

 *pappy_mcfae wrote:*   

> You can use make oldconfig to transition from one version to the next, and even jump numerous family versions, in an up or down direction.

 Hmm, I wasn't aware of this. I'll give it a shot when going from 29 to 30.

 *pappy_mcfae wrote:*   

> Because of the continuous reorganization of the kernel source, any attempt to use make oldconfig should be followed immediately by make xconfig (or make menuconfig or make gconfig), to make sure your transition was successful. You will wind up with some mismatch errors. In general, these are more annoyances than real problems.

 Are these errors that will be brought to one's attention when make menuconfig is initializing, or will they simply be silently present in the ncurses menu?

 *pappy_mcfae wrote:*   

> As far as finding out what was used previously, make xconfig in the old and new kernel source directories, and do it manually. By the time you could whip up a script to do this, you'd be a lot farther ahead doing things manually. Keep it simple.

 Is it really that difficult to do? Seems like you'd just need to run a diff on the .config's, translate that to the menu option, and display those options.

----------

## pappy_mcfae

 *srunni wrote:*   

>  *pappy_mcfae wrote:*   Because of the continuous reorganization of the kernel source, any attempt to use make oldconfig should be followed immediately by make xconfig (or make menuconfig or make gconfig), to make sure your transition was successful. You will wind up with some mismatch errors. In general, these are more annoyances than real problems. Are these errors that will be brought to one's attention when make menuconfig is initializing, or will they simply be silently present in the ncurses menu?

 

They show up after compilation...natch. As I said, in most if not all cases, they are minor. Even starting with a seed kernel results in mismatches, and the kernel seed is just one step from make defconfig. The kernel is an imperfect critter, which is why they're always developing on it.

 *pappy_mcfae wrote:*   

> As far as finding out what was used previously, make xconfig in the old and new kernel source directories, and do it manually. By the time you could whip up a script to do this, you'd be a lot farther ahead doing things manually. Keep it simple.

 

 *Quote:*   

> Is it really that difficult to do? Seems like you'd just need to run a diff on the .config's, translate that to the menu option, and display those options.

 

Let's put it this way, there are several million lines of code which make the kernel do its thing. A .config file can run anywhere from 42k to easily over 100k. The script would have to take all that into account, as well as name changes (module A used to be called "foo", got renamed to "FU", then got renamed to "bar").

I don't want to quash the possibility that such a script could be made, and could be made to work. All things are possible. For future reference, your idea could become a very useful tool. If for only that reason, I'd recommend you at least see how far you can get with the idea.

Blessed be!

Pappy

----------

## srunni

 *pappy_mcfae wrote:*   

> Let's put it this way, there are several million lines of code which make the kernel do its thing. A .config file can run anywhere from 42k to easily over 100k. The script would have to take all that into account, as well as name changes (module A used to be called "foo", got renamed to "FU", then got renamed to "bar").

 Well, the script would primarily be to deal with changes in the kernel; the rest of the several thousand-odd lines could be ignored. I guess my real question should be ``is it feasible to improve make oldconfig so as to work most of the time when moving between kernel versions?''. Of course, make oldconfig is maintained along with the kernel, so the script would have to interface with it, rather than being a modification of it.

Is there somewhere one can obtain a list of the changes to the kernel .config settings between versions? As in, does the kernel development team publish such a list upon release of a new kernel version? If that list were converted into some data format parsable by the script, it would simply have to run make oldconfig and then make the necessary corrections, prompting the user in cases of ambiguity.

----------

## pappy_mcfae

There might be, but when all is said and done, the lineage is in the source. The make defconfig command reads files in order to set the initial configuration. You can look at my kernel seeds to find the exact files that defconfig uses to set up said initial configuration...or in any of your current unedited .config files you have lying about.

Blessed be!

Pappy

----------

## Snake

Is it possible to open two different files (old config and new .config) with menuconfig/xconfig? I haven't tried it yet, but it would be much easier to check the same options in new kernel as you had in old one. 

Upgrading to new kernel takes me pretty much time, that is the reason that I am still using 2.6.27.

----------

## pappy_mcfae

It might happen, but the actions of make xconfig creates three files that usually need to be cleared via make mrproper when working with another .config. That might put the screws to making it happen.

If it is possible, I don't know how to make it happen.

Blessed be!

Pappy

----------

## srunni

 *Snake wrote:*   

> Is it possible to open two different files (old config and new .config) with menuconfig/xconfig? I haven't tried it yet, but it would be much easier to check the same options in new kernel as you had in old one. 

 This is exactly what I do. I open up 2 terminals next to each other and run menuconfig in the old/new kernel source directories and manually go through all of the menus and fix the options that got reset/changed in the new kernel .config. It's extremely tedious (which is why I've been putting off the upgrade to 2.6.29-r5), but it works.

----------

## doctork

From /usr/src/linux/README:

 *Quote:*   

> If you want to carry your existing configuration to a
> 
>    new version with minimal work, use "make oldconfig", which will
> 
>    only ask you for the answers to new questions.

 

I just copy the .config file from my current kernel directory to the new kernel directory and run "make oldconfig".  There may be problems with this approach, but I've not seen them.

--

doc

----------

## jms.gentoo

Reading the post I am left wondering why the kernel does not (or does it?) have a feature like an associated unique long-lived name to avoid the problem

 *Quote:*   

> module A used to be called "foo", got renamed to "FU", then got renamed to "bar"

 

Implementing some of the ideas working in CVS or GIT  within the kernel to be able to track changes(or at least somes change or in a better way) from one version to another?

As the problem is about tracking changes isn´t it?

It´s strange as (as far as I know) there does not seem to be any features like this ,thinking of the Linus involvment in the kernel and git.

Disclaimer, I am no expert , have no idea how to implement this, just a thought.

Is this a mad idea?

jms

----------

## srunni

 *jms.gentoo wrote:*   

> Is this a mad idea?

 I don't think so; it makes sense to me. I have no idea why it isn't implemented already. You'd have to ask Linus or one of the other lead kernel developers about that, but I doubt they reply to emails from random people ;/

----------

