On Thu, Jan 06, 2011 at 04:14:08AM +0000, Mr Dash Four wrote:
>>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?
Well it was written 6-7 years ago. ;-) No one cared enough to change it.
But regardless, it is only used as a temporary thing to get by running
'make ARCH=$ARCH nonint_oldconfig' I think.
Most developers here are used to doing the equivalent of a
'rpmbuild -bp' and have the config files spit out for all the arches
regardless of the --target passed in.
Anyway, patches welcome, if you think it is worth fixing.
>>>>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?
Never tried it, but your theory makes sense to me. Try it and see what
happens.
>>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.
I guess the kernel-*.config files get overwritten every time then.
>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?
That could work too, I believe (again never tried).
Cheers,
Don