The people reading the faq are not the people who need custom kernels. Those people *know* what they need and are not deterred. But as always, when we try to help the userbase by offering the advice they need, someone needs to chime in and muddy the waters. So now some dude is going to read your email and conclude that he can get better mysql speed on his 1gb box by shaving a driver. You're not doing anyone any favors.

And no, we cannot assume that people correctly self identify when they are special. Ignorant people don't know they are ignorant. But at least some of them read the faq. So at least let them get the best answer for them.

On Jun 6, 2008, at 2:17 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote:

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

Reply via email to