From owner-freebsd-arch Tue Mar 12 12:41:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 131A137B400; Tue, 12 Mar 2002 12:41:17 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 724025346; Tue, 12 Mar 2002 21:41:14 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Cc: peter@freebsd.org, jake@freebsd.org Subject: dumpsys() rewrite From: Dag-Erling Smorgrav Date: 12 Mar 2002 21:41:14 +0100 Message-ID: Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As noted on -committers, dumpsys() & co. need a serious revamp, to support kernel dumps on sparc64 and reduce code duplication. The required changes fall into two categories: 1) centralization of the dumping logic to avoid duplicating it in each disk driver. 2) a new on-disk format for kernel dumps, from which savecore(1) can extract all the necessary information to construct a correct core file. Drawing on input from Peter, I suggest the following: a) drivers will implement three functions instead of one: - dump_init: readies the device for dumping the specified number of pages at the specified offset (dumplo). - dump_write: writes the specified number of pages from the specified address to the device - dump_done: cleans up once everything has been written. b) dumpsys() will call the appropriate dump_init function, then loop over physical memory, doing the appropriate pmap_kenter_temporary() magic and calling the appropriate dump_write function, then finish off by calling the appropriate dump_done function. c) the on-disk format will be as follows: - first, a chunk of metadata beginning with "DUMPINFO\n" and listing a number of parameters as key-value pairs, like this: DUMPINFO dumpinfo_size=0x1000 page_size=0x1000 dev_bsize=0x200 dumplo=0x6c0020 kernbase=0xc0000000 - this is immediately followed by a section listing the chunks of physical memory that were dumped, as pairs of numbers indicating starting (physical) address and size in pages: MAPPINGS 0x0 0x27ffc - follwed by "END\n": END - the dumpinfo_size listed earlier is the size in bytes of the entire metadata block, from "DUMPINFO" to "END", rounded up to some unspecified multiple of page_size, which is assumed to be a multiple of dev_bsize. - the actual dump begins at offset ((dumplo * dev_bsize) + dumpinfo_size). - savecore(1) will first read the metadata and construct an internal list of chunks that need reading. For every chunk, it will then seek to the specified offset in the core file and copy the specified number of pages, using the same algorithm it already uses to skip sequences of zeroes. Comments? Suggestions? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message