On Fri, 6 Jun 2008 10:14:55 -0400 "Ted Unangst" <[EMAIL PROTECTED]> wrote
On 6/6/08, Geoff Steckel <[EMAIL PROTECTED]> wrote: >> For systems which must boot very quickly, removing unused drivers >> whose probe routines cause significant timeouts can make a big >> difference. Sometimes timeouts are the only way to check for an >> I/O device behind a blind interface. For instance, checking >> a floppy drive's seek time is a significant wait. >introducing config. You're compiling your own kernel, so you must >have read the man page for config, right? So you know there's no >reason to actually compile anything, right? Yes, there is. Applying config multiple times to a built system is much harder to maintain over versions and releases than tracking cvs of GENERIC, files.xxx, etc. and applying diff3/merging, which is scriptable. >> For systems which are intended to run with little memory or which >> are straining at architectural limits, 100K here and 100K there >> can make quite a big difference in what applications can run. >> Many drivers are over 150K when linked. When a megabyte or two >> counts, removing 10 drivers could make a big difference. >Given the cost of hardware today, the fraction of total memory that >one megabyte represents, and the nature of any job that needs "all >your memory", by the time you finish compiling that kernel it's going >to need two megabytes more, not just one. And then what? Hmmmmm... Maybe you should look up the concept "transaction cost". Changing hardware, especially multiple installations, can be expensive, disallowed, or impossible. In those cases the cost of adding memory is essentially infinite. Some platforms cannot add memory at any cost. The advantage of being able to run even for a few months more on existing hardware can be very large. The advantage of using a smaller hardware platform and saving (say) two watts of power can multiply to hundreds of dollars or even the possibility of a project at all. >> If the kernel code is well structured, the following must be true: >> >> Removing a driver which is essential to normal operation must >> cause the kernel compile or link stage to fail. >What compiler are you using that can detect your system's hardware for you? I think we had already determined that the user removing drivers is reasonably well informed, especially about the details of the platforms to use the kernel. I'm speaking to any entanglements between drivers or with apparently hardware-independent functionality, etc. geoff steckel
