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 _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
