>Sometimes it matters to be small and sometimes fast. That is a decision
>made by the kernel hacker. Joe user does not make these decisions
>because he/she does not understand the overall impact.
>As someone else who writes code for this fine os would say: removing
>drivers is pure masturbation.
Oh dear....
I think that ye all do protest far too much.
Threats of unspecified system instability are hard to believe.
I strongly suggest that anyone desiring to optimize things
should be pointed at tools to monitor and profile system performance
before doing any changes at all, not just kernel mangling.
Hacking out chunks of kernel code "because it isn't used" is
clearly a bad idea. On the other hand, removing unused I/O device
drivers has been done for many decades in many O/Ss.
It's not a task for the uninitiated but it should not be fraught
with danger.
I suggest that there are reasonable cases where a non-core-team
person would correctly want to remove unused drivers.
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.
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.
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.
Secret, undocumented dependencies (neither in the man pages or
in the source code comments) between apparently unrelated modules
are very serious bugs.
-----
The x86 architecture and I/O devices are seriously flawed.
There are cases where it is not obvious which driver is the
correct one for a peripheral, and the order in which devices
are probed is critical. Self identifying devices such as on the PCI
bus are mostly immune from this problem, and the kernel is
quite good about announcing a PCI device for which no driver is found.
Still, ISA devices can be a minefield. While removing an ISA
driver has potential to recover the most space or time, it's the
hardest to verify. Unfortunately the biggest payback is often
from removing drivers intended for systems not made in 10 years or more.
-----
As an aside, I've been wondering what the heck named is doing to
initialize itself. It does many thousands of disk accesses for no
visible benefit and takes a very long time to do them.
curmudgeonly
geoff steckel
