Hi all,
I want to point out a question, and might even get an answer. Even if
not, whoever regularly compile their own kernels and try different
configs, pay attention.
I noticed this a few days ago, on Fedora Core 1. Since I currently
do not have access to such a machine, I did not try it on such, but
on RedHat 7.3. But - with Fedora's kernel sources, and gcc 3.2.0
(which shouldn't make a difference - I only ran menuconfig, which is
hopefully a trivial program, independent of a specific compiler. I
did this since make menuconfig wanted gcc32, and that's the closest
I had arround - they have a patched 3.2.2, IIRC).
I copied configs/kernel-2.4.22-i686.config to .config, ran 'make
menuconfig', immediately selected exit, yes for save. diff between
the original conf and the new .config is 2241 lines. Bad enough, you
say? Well, now I ran again menuconfig, now entered the first submenu
("Code maturity level options"), immediately exit, exit, yes for
save. There is a diff (although small) between .config between the
first run and the second!
Now, one might explain that since RedHat (Fedora?) has tons of patches
to the kernel, also the possible options are different, and although
I am _not_ doing this on vanilla kernel (which will probably be
different in what features it has), but on Fedora's, there might be
something I am missing which explains this. But why would there be
a diff between after the first run and after the second run is beyond
me.
Now, I do not want to spread smoke (is this how you say it in English?),
but I am pretty certain that on the real Fedora, for some weird reason,
it was even worse - there were actual, real, noticable differences
between the configs, that I could see. I did not go over this 2200 lines
diff, but I do see signs of such things - e.g.
configs/kernel-2.4.22-i686.config has *twice* this line
CONFIG_HIGHMEM4G=y
while the output .config has it once, and also has
CONFIG_HIGHMEM=y
which does not appear at all in configs/kernel-2.4.22-i686.config.
I do not see immediately how this specific diff can cause real changes
in the kernel, but it's also not at all obvious that it doesn't.
Any idea?
Anyway, all of this will hopefully be better in 2.6, where (so I
heard, I did not read it myself) the kernel config system was heavily
patched (somewhat rewritten? I do know ESR's CML2 didn't make it in).
For the record - while I do not pretend to know deeply how all this
config stuff works, and do not give any guarantees to the following,
I will say how I work.
At home, I have a quite-tuned config - I once skimmed over the entire
menuconfig, carefully chosen what I want (and the hardware I have),
and since then I copy over the config to every new version I compile,
adding features and drivers as I need/want. But I know that the base
was "good", and the changes are incremental. When I started working
here (in tau), 3+ years ago, I intended to do mostly the same, but
did not know what hardware there is, and also did not want to compile
a new kernel (or driver) every few weeks. So I started with RedHat's
config on a vanilla kernel, and continued the same as at home since
then - not following RedHat but using the last good config. So I got a
base config of many drivers, which take around twice+ to compile with
all those modules, and am mostly happy.
After this experience with Fedora a few days ago, I can't anymore
recommend their config whole-heartedly. I also stopped treating it
as passive, trivial data. Unless someone here will have a good
explanation. I will personally continue using my configs, and do not
mind posting them if anybody wants them.
--
Didi
On Tue, Mar 09, 2004 at 07:08:39PM +0200, Gilad Ben-Yossef wrote:
> On Tuesday 09 March 2004 15:31, Shachar Shemesh wrote:
> > Gilad Ben-Yossef wrote:
> > >Install the RedHat kernel source RPM (no, not SRPM, there's an RPM of the
> > >kernel sources), then go to /usr/src/linux-version/configs and you'll find
> > >the configuration files used to compile the RedHat supplied kernel.
> > >
> > >There are several config files suitable for SMP/UP, BIGMEM, no BIGMEM etc
> > >etc., so just cp the right one as .config and there you go.
> >
> > Wouldn't he rather get the SRPM and run rpmbuild?
>
> Since what he wants to do is build a vanilla kernel, but use the same
> configuration file as RedHat used to save time and hassle (I do it it myself
> quite often :-), then no - he wants the kernel source RPM which holds those
> config files.
>
> > What is in the kernel source RPM anyways? I was under the impression it
> > contained an almost vanilla kernel (as opposed to the SRPM, which is
> > heavilly patched).
>
> No, it's a /usr/src/linux-version that contain a Redhat patched version of the
> kernel. Usefull if you want to debug the kernel, build some (mostly badly
> written) modules that require kernel sources to build etc.
>
> >
> > Where is the SRPM for the kernel source rpm? :-)
>
> A single SRPM can generate several RPMs. In this case the relvant SRPM
> generates both the kernel RPM, the kernel headers RPM and the kernel source
> RPM.
>
> Gilad
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
