Re: x86 GENERIC kernels unlobotomized

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        Hello.  Creating a kern.tgz file in the sys/arch/xxx/compile/KERNEL
directory of modules built when that kernel was built would be an excellent
way to start getting me to use modular kernels as it would allow me to
easily know whether the modules I have installed are from a particular
build I did.  There are times when I want to use old binary kernels that I
built some time ago when my  source trees were in a different state.
Either I'm testing a change, and I want to be sure that I have a known
working kernel so I can revert if things go badly, or I built a kernel with
particular options for a specific application and there is a need to
reinstall that kernel into a similar environment.  I realize that the idea
behinD MODules is that you don't need to build specific kernels anymore,
but that doesn't solve the problem of debugging a change  one might be
making with the knowledge that there is an easy backout strategy, and there
are still options in our kernel, I believe, that are only tunable by
building specific kernels with specific options.
Disk is cheap.  Having a bunch of binary copies of modules laying around
various compile trees is a small price to pay for the flexibility and
versatility having those copies provides.

-thanks
-Brian

On Aug 9,  4:15pm, David Holland wrote:
} Subject: Re: x86 GENERIC kernels unlobotomized
} On Mon, Aug 08, 2011 at 11:42:50PM -0400, Martin S. Weber wrote:
}  > You mean -current's build.sh still doesn't put the modules in
}  > kern.tgz? Oh my...
}  > 
}  > That was the simple "no need for people to be trained much"
}  > suggestion that had been brought up ~ 1 day after the move to the
}  > modular kernel and the first dozen or so had chopped their feet off
}  > with it :(
} 
} That's been one of the most contentious points all along, the claim
} that modules are and must be independent of choice of kernel and must
} not / cannot be built or installed or treated in any way as part of
} the kernel.
} 
} There is, as far as I can tell, no sound technical basis for those
} claims and various reasons why it's folly, but that apparently doesn't
} change the situation.
} 
} -- 
} David A. Holland
} dholland%netbsd.org@localhost
>-- End of excerpt from David Holland