On Thu, 3 Nov 2005, Brett Glass wrote:
The notion of creating directives to reverse those in a file of defaults (the most amusing one being "nocpu", which sounds as if one is saying that the system has no CPU) shows how absurd this approach is. Yes, it's handy to have defaults; however, if one is building a custom kernel at all one is most likely building something vastly different from the original or it would not be worth doing at all. He or she and should expect to specify in detail what will be included in it. Copying GENERIC (or LINT, which is now absent but used to be extremely handy) and then editing it is a far better and less error-prone way of crafting a kernel than having to inspect a file and then hopping back and forth to another editor window disabling EVERYTHING in the first file you don't want (which can be quite a list if you're trimming down the statically linked portions of the kernel to the hardware that your machine actually has).
In practice, I've found the include mechanism extremely valuable in keeping a number of variations on a single kernel synchronized. For example, when configuring systems, I often have a UP configuration, an SMP configuration, sometimes a couple of specific extension kernels, and a full debugging version of each. While the current mechanism still allows me to do it the old way, that approach is prone to error: what I want is a single base configuration (be it GENERIC or RWATSON or whatever), and then a series of variations that I can easily maintain. If you prefer to copy GENERIC, no one is stopping you, but I find the copy-and-paste approach quite error prone in practice, especially when tracking a branch, as it requires manual propagation of changes to all the kernel configurations.
BTW, LINT does exist, but it is generated dynamically using "make LINT" in the configuration directory. This combines both cross-architecture and architecture-specific NOTES entries to produce a kernel configuration.
Robert N M Watson _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
