>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 is my thought.
>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;
Yes.
>if your
>target is anything else, you SHOULD go in and configure by hand. (As
>always, YMMV.)
Yes again. But make a patch file of your changes. Your new patch may
become the basis of another 'standard' patch if it becomes popular.
> > 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.
>
> > 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?
Only a small confusion.
LRPkernel is the tool for applying patches.
Newpatch is the tool for creating patches.
