Havard Eidnes wrote:
7 NetBSD 5.0 (GENERIC) #0: Sun Apr 26 18:50:08 UTC 2009 8 builds%b6.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-RELEASE/i386/200904260229Z-obj/home/builds/ab/netbsd-5-0 -RELEASE/src/sys/arch/i386/compile/GENERIC 9 total memory = 15996 KB 10 avail memory = 4152 KBNotice how little memory is available after the kernel has been loaded and grabbed it's resources? It's my guess that most of the reason for this is that the GENERIC kernel has outgrown what's reasonable to expect to run well in 16MB on i386. A lot of this weight is made up of device drivers which take up both program and data space (the isp(4) microcode files embedded in the drivers are just one example of the kind of bloat you don't need on this machine), but is unused on the hardware you're trying to run on. My guess is that a customized kernel only supporting the actual hardware in the machine will work a lot better.
Ooo. Is that really the way nowadays? And here I was, still thinking that it was pretty neat that the microcode patches for the VAX-11/750 came as a separate file, which the system applies at boot time. Smart, both because it don't take space in the kernel, and smart because if a new version of the patch file came out (not that it is likely), we'd just have to replace a file in the file system, and we are all set. And smart because we could keep binary cruft out of the image. And smart because we could keep data that could be (c) by someone out of our images... And smart, since we could totally skip the microcode patches by just (re)moving the file if we didn't want them.
Boy, am I backwards or what?I guess that falls in the same category as config files formatted for human readin and editing. :-)
Progress... There is no denying that we are moving. People might be facing in different directions though, so forward isn't in the same direction for all...
Johnny