Douglas A. Tutty wrote: ... > One thing I'm not clear on: if the only issue is kernel size based on > having an old box with low memory, where every MB counts, does > deactivating unnecessary drivers with config actually result in a > smaller kernel or just a kernel with deactivated drivers? Shrinking the > kernel would be the only reason I would have of touching the kernel as > I'm not into trying out experimental features. It would be too bad if > config doesn't do this.
config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. WELL...there MIGHT be a small savings in data structures not allocated for drivers, but that would most likely only be the case if you had such a device in the machine, but deactivated the driver. (i.e., em(4) (the driver) might allocate a RAM buffer for each em(4) card in the machine, but only for the cards in the machine...disable the driver, you don't allocate the buffers, but you can't use the card). Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. That would be a funky kind of relinking, or a bunch of loadable modules, ala Windows or Linux, which is why Windows and Linux needs so much less RAM than OpenBSD. Oh..wait... ;) Removing drivers for reduced memory is really a "for advanced users only" task, and you VERY QUICKLY run into diminishing returns. One problem is you almost certainly need another computer -- if you have 16M RAM, you want to whittle down the kernel a lot...but $DEITY help you if you need to build that new kernel on that machine, since just sitting at the shell prompt will have you into swap. HOWEVER, by the time you get to 32M, I doubt you will appreciate the time and effort required to build and reboot off a new kernel (even if compiled on another machine). You just won't be adding much functionality to the machine -- there won't be something major you will suddenly be able to do that you couldn't do before. Nick.
