Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!ponderous.cc.iastate.edu!michaelv From: michaelv@iastate.edu (Michael L. VanLoon) Subject: Re: boot.c for kernel > 1M Message-ID: <michaelv.742631490@ponderous.cc.iastate.edu> Keywords: Mach, NetBSD Sender: news@news.iastate.edu (USENET News System) Organization: Iowa State University, Ames IA References: <27081@hq.hq.af.mil> Date: Wed, 14 Jul 1993 06:31:30 GMT Lines: 39 In <27081@hq.hq.af.mil> john@Pt.hq.af.mil (John Ryan) writes: >We are trying to merge NetBSD and Mach boot sequences. I wanted >some advice from people who might be trying to patch NetBSD to >load it above 1M. >Question 2) Has anyone calculated the text, bss, data, and symbol offsets > for > 1M? That is Are you going to want things a specific > locations. I would think it would be best to have it as low as possible, hence, right at the 1M boundary. My reason for this is that I sometimes throw in a ISA bus extended memory card to boost the memory on my system. This card is extremely slow, but generally faster than swapping. I would like to be reasonably well assured that my kernel is never going to get stuck in slow memory, even if some applications do. This is, I think, a reasonable request. What may be more difficult, but nevertheless desirable, is to have the boot code determine at startup time different areas of fast and slower memory. Anyone who's ever used QEMM seriously has seen this in action. It would allow the kernel to weight its decision about where to swap things in by how fast the memory location is. Or, alternatively, to stick disk buffers or something similar in slower memory, since even slower memory is generally faster than disks or tapes. Alternatively, you could maybe tell the system how your memory is layed out in your config file and build it into your kernel as a static table, which would relieve it of the task of gauging the speed of your memory at boot-up. But would still allow the VM mechanism to weight paging locations by memory speed. Or, maybe would allow the physical I/O buffers to be stuck in slower memory. -- ------------------------------------------------------------------------------ Michael L. VanLoon Project Vincent Systems Staff michaelv@iastate.edu Iowa State University Computation Center ------------------------------------------------------------------------------