>> See the "Fedora Wiki" ( :-D ) for building the kernel - the target arch >> needs to be added as a comment on the first line of that .config file >> (that is particularly important if I do cross-compilation of the kernel >> - I add "# i386" for i686 targets for example). If that is not present >> all hell breaks loose! >> > > I think we use it during the 'make nonint_oldconfig' stage, ala > > for i in $config_list > ARCH=`cat $i|head -1|sed 's/# //'` > cp $i .config > make ARCH=$ARCH nonint_oldconfig > cp .config configs/$i > > without the #$arch thing, we wouldn't know what arch to pass into the > kernel Makefile system to get the right config options. > When I start the "rpmbuild -bb" process (from where everything kicks on) I could specify a "--target=XX" parameter. Why can't the build system utilise that? A simple solution would be "echo <target_parameter_value> > .target_arch", not to mention that this can also be stored in the environment as a variable. To add '# arch' every time I change the .config file is a bit, well, archaic, don't you think? >>>> cp .config ~/rpmbuild/SOURCES/config-x86_64-generic >>>> > > Yeah that won't work (explained below) > Would it work if I delete ALL .config files and leave the one I quoted above? If all .configs just 'stack-up', then by deleting everything else but what I actually configured should, in theory, do the trick, right? >> What do they actually change - after I build and install the kernel and >> then check the corresponding .config file in the /boot >> partition/directory it is the same as the one I have copied as >> config-x86_64-generic, so, naturally, I assume that nothing has been >> modified/changed. Is that not the case? >> > > The way the config options work is basically a bunch of templates that > override each other as they get stacked on top. So > > config-generic is usually the base config that all arches start with > config-$ARCH-generic is merged onto config-generic and overrides those > options > config-$ARCH-$VARIANT is merged onto that with more overrides > > the result config blob is full of stuff that may or may not be relevant to > the particular type of kernel we are building, therefore we use the > for-loop (from earlier in the email), to filter out that cruft. The magic > is 'make ARCH=$ARCH nonint_oldconfig' (think make oldconfig without the > prompting). > Riiiight! I get it now - a bit complicated, but at least I know what is happening! Thanks for that insight! My suggestion above stays though - would it work that way? > The output files are kernel-$version-$arch.config. If you want to copy > .config files somewhere, it really should be the kernel-*.config files. > I've noticed there are 2 files like that linux-<ver>-<arch>/configs/kernel-<ver>-<arch>.config and another file called kernel-debug-<ver>-<arch>.config. these files have the DRM_NOVEAU section of options missing from my .34 config file, but they are just a starting point and if I want to merge an older version (.34) with these by using oldconfig, that won't work - I already tried that as well. > But I don't have the .spec file handy to know if those get repeatedly > overwritten on a rpmbuild. > Tomorrow when I have more time to play with this stuff I would be able to check it out. > The way the kernel maintainers set the options is to modify the > config-$pickone-generic file with the option you care about to on/off. > > But as explained in other threads, we never supported custom configs so no > one really designed a process to make it easy. > So, if I use my customised .config file from the .34 version and call it config-x86_64-generic would that do the trick? Would I be able to get all the options merged in the final configs/kernel-2.6.35.xx-xx.config file do you think? _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel