> 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?