Thus spake Michal Pasternak ("MP> ") sometime Today...


MP> Having 1000 modules not only makes the kernel smaller, it reduces the need
MP> for reboots and allows hardware vendors to distribute their own ones (aka
MP> "drivers").

I was previously dead-set against having kernel modules load at boot time
one by one because it seemed to tremendously slow down the boot process.
I think if it's done right, it can happen efficiently, so I'm somewhat
ambivalent.  Certainly, I think the GENERIC kernel might benefit from such
a scheme, although I think the option remaining to hardwire stuff in the
kernel for a particular HW config would be a very good idea.

After all, if you know what your hardware is and what it's going to be
for a while, there's no point in playing the by guess and by golly game
of a dynamically loading kernel.

And having those 1000 modules may make the kernel physically smaller
initially, but the modules take space too, so you're not really saving
any space.  You're just redistributing it.  In fact, technically,
all those modules could be taking more space since some of them are
less than a FS block in size, plus they take an inode.  Yeah, big
whoop, I know.  But technically, it doesn't save space.

				--*greywolf;
--
NetBSD: "Progress on your system is closer than it appears."