The recent discussion regarding kernel configuration directives and a file containing "defaults" reminds me of a poster I saw in college long ago. The poster warned students who were headed home for the Thanksgiving holiday to lock their rooms to avoid theft, saying, "Don't be a turkey." The illustration showed the familiar circle and slash with a turkey in the middle, saying, "Nogobble, nogobble." My roommate, who was drinking a can of soda when he saw this, lost about half of the 12 ounce can through his nose. 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). My humble opinion, for what it's worth, is that the GENERIC kernel configuration should be very heavily commented and documented and that the DEFAULT file will then be completely unnecessary. Just my $0.02. --Brett Glass
On Thu, Nov 03, 2005 at 05:39:28PM -0700, Brett Glass wrote:> My humble opinion, for what it's worth, is that the GENERIC kernel > configuration should be very heavily commented and documented and > that the DEFAULT file will then be completely unnecessary.Thanks for your $0.02, but that doesn't work in reality, as discussed previously. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051103/65b09a2d/attachment.bin
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