On Wed, 25 Apr 2001, Mike Sensney wrote:
> >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. [...]
>
> 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.
Possibly could work. Would - for major sections of code like the IDE or
SCSI support, would perhaps doing a patch that activates SCSI support,
then modifies everything under it to be modular? That might work best
all-around, and I'm personally of the opinion that you're either going to
be using something like this to compile a distributable kernel; if your
target is anything else, you SHOULD go in and configure by hand. (As
always, YMMV.)
> It should be possible to build the same final config file or useful
> variations of it just by selecting a different mix of patches.
Aye, it should.
> >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:
<Snip example script>
> 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:
Erm, I perhaps am missing something here, but I thought that the point of
all this was to avoid having to use the 'make *config' step altogether,
by building a kernel .config "by script" as it were. Was I misinterpreting
this?
> 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.
I like this way of doing it overall, and again, as a result of answering
e-mail at 4:30 or 5:00 in the morning, COMPLETELY forgot all the various
additional options that are floating around.
> To simplify the patching process, I still like
> LRPkernel IDE IPSEC PPORT <etc.>
> for apply the patches to the config file.
Definitely, will make it that much easier to do.
> 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.
Aye, it would. See above comment about early morning e-mail. =)
> >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. :-)
No I haven't. Need to check that out; the beauty of Open Source is that
you don't have to do too much work when you can plagiarize for your
project. =)
I'll go take a poke and see what I can see.
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
"We know what deterrence was with 'mutually assured destruction' during
the Cold War. But what is deterrence in information warfare?" -- Brigadier
General Douglas Richardson, USAF, Commander - Space Warfare Center
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
