At 04:44 AM 04/25/2001 -0400, George Metz wrote
>On Tue, 24 Apr 2001, Mike Sensney wrote:
> > Would it possible to create a "base" .config then create a series of
> patch
> > files to modify the .config file? Would this be manageable or would it
> be a
> > can of worms best not visited?
>
>It's easily possible, yes. The only problem I see is that there may be
>issues where it's best left to the person building the kernel to go in and
>verify by hand. For example, if you've got a system with two SCSI CD-ROM
>drives, and you want to use both for data in a thin-server mode of
>operation, then you want the SCSI CD-ROM to be modular. The alternative
>is, if you've got only one, your best bet may be compiled in. Things like
>that get tough to handle.
Not a problem. Use the base config and appropriate standard patches to
create a starting config file for your SCSI kernel. Then do your hand
tuning. To document the changes, create a new patch file that notes the
differences between your starting config and your final config.
It should be possible to build the same final config file or useful
variations of it just by selecting a different mix of patches.
> > I was thinking of a script, call it LRPkernel that first copies a base
> > .config to /usr/src/linux, then applies the patches listed on the
> command
> > line. It would look something like:
> > LRPkernel IDE IPSEC PPORT <etc.>
> > Then compile the kernel as usual.
>
>Ouch. That is a LOT of grunt work to get the various different configs
>done.
Not necessarily. Let us say that .config.base (our base config file) is set
for a 486 CPU type. But we need to allow for 386 CPU with no FPU. We create
a patch to do this using the newpatch script:
<newpatch>
#!/bin/sh
# Create a patch to base .config file
#
cp .config.base .config
make menuconfig
rm .config.$1 >nul 2>&1
mv .config .config.$1
cp .config.base .config
echo "diff -uNr .config .config.$1" > $1
diff -uNr .config .config.$1 >> $1
</newpatch>
We run "./newpatch 386FPU". Newpatch runs "make menuconfig" where we change
processor type and math emulation, save our changes and exit. Newpatch then
creates the 386FPU patch
file:
<386FPU>
diff -uNr .config .config.386FPU
--- .config Wed Apr 25 09:01:55 2001
+++ .config.386FPU Wed Apr 25 09:01:55 2001
@@ -21,8 +21,8 @@
#
# Processor type and features
#
-# CONFIG_M386 is not set
-CONFIG_M486=y
+CONFIG_M386=y
+# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
@@ -35,14 +35,8 @@
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
-CONFIG_X86_WP_WORKS_OK=y
-CONFIG_X86_INVLPG=y
-CONFIG_X86_CMPXCHG=y
-CONFIG_X86_BSWAP=y
-CONFIG_X86_POPAD_OK=y
+# CONFIG_X86_CMPXCHG is not set
CONFIG_X86_L1_CACHE_SHIFT=4
-CONFIG_X86_USE_STRING_486=y
-CONFIG_X86_ALIGNMENT_16=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
@@ -50,7 +44,7 @@
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
-# CONFIG_MATH_EMULATION is not set
+CONFIG_MATH_EMULATION=y
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
# CONFIG_X86_UP_IOAPIC is not set
</386FPU>
Now all I or anybody else has to do is to apply the 386FPU patch to the
base
.config file to change the .config file to supporting a 386 with no FPU.
patch <386FPU
To simplify the patching process, I still like
LRPkernel IDE IPSEC PPORT <etc.>
for apply the patches to the config file.
>It MIGHT be easier if the parameters offered on the command line did
>something like the following. (I'd like to note for the record that I
>almost was able to come up with the script commands here, but not quite.
>I'm getting there!)
>
>If $OPT = IDE, then 'cat .config | grep CONFIG_IDE' and somehow (sed?) set
>CONFIG_IDE=y(or m, as the case may be).
Look at my 386FPU patch. To change from a 486 to a 386FPU involves changing
4 lines and removing 6 lines from the .config file. This implies having to
insert lines for other desired options. This will add complexity to your
script.
>It'd be a lot easier - and smaller - than patching the .config file from
>dozens of separate .config files. This IS doable, but it's just a wee bit
>beyond me, for the moment. I've already set up a script to build the
>kernel after I've configured it, copy the new kernel to the installed
>modules directory along with UPX, compress the kernel, remove UPX, tar up
>everything, and copy it to my Sourceforge directory on localdisk. What
>you're suggesting would work excellently at the beginning of this script,
>assuming I can figure out how to do it.
Hmmm. This could be the start of set of LEAF kernel builder scripts for
newbies. Have you looked at the Buildkernel script? Theoretically, it will
d/l, compile and install a new kernel for you with little/no need of user
input. :-)
