Date: Sun, 4 Oct 1998 03:35:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: wollman@khavrinen.lcs.mit.edu, phk@critter.freebsd.dk, chuckr@mat.net, current@FreeBSD.ORG Subject: Re: comment about verbose booting Message-ID: <199810040335.UAA23111@usr06.primenet.com> In-Reply-To: <199809302334.HAA15192@spinner.netplex.com.au> from "Peter Wemm" at Oct 1, 98 07:34:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Don't joke... It's not all that difficult - the main problem is one of > fragmentation and the memory impact if we keep skipping page boundaries to > avoid bloating the kernel image (or .o or .so). Trynig to reclaim a page > in the middle of chunks of in-use data isn't fun. May I suggest the following for the characteristics flags field of the ELF section headers? 0x00000020 Code section 0x00000040 Initialized data section 0x00000080 Uninitialized data section 0x04000000 Section cannot be cached 0x08000000 Section is not pageable 0x10000000 Section is shared 0x20000000 Executable section 0x40000000 Readable section 0x80000000 Writable section Code in the paging path goes in a section with 0x08000000 set. Additional definitions for "preload", "relocatable", etc., are needed. The rest of the kernel (except the code that does this, which must also have 0x08000000) can be relocated, at will, to defrag the kernel VM space. > One possibility is if it ends up in a plaintext file in /boot somewhere as > part of a control mechanism for assigning a driver.o file to a pci or pnp > device id or a mapping between a probe module and a driver itself. I dislike seperate files. It complicates things beyond merely needing to read the / directory to find "kernel". I prefer agregation via archiving the ELF sections into a single file. Using a #pragma to name the section (I can dig out Microsoft's version of this #pragma, if forced to it) keeps the linker from jamming the sections together. The naming is sufficient to identify code needed in the probe phase, but not afterward, which can be discarded. A special "group" mechanism would be required for drivers that didn't probe true; you would effectively page them out. Using the relocation defragging of physical memory (which you could do, if you knew not to move the paging and relocation code) would buy you the ability to allocate large contiguous chunks of physical memory, as necessary, to support things like quickcam drivers loaded after 10 days of uptime. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810040335.UAA23111>