Date: 12 Mar 2002 21:41:14 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: arch@freebsd.org Cc: peter@freebsd.org, jake@freebsd.org Subject: dumpsys() rewrite Message-ID: <xzp3cz5v7rp.fsf@flood.ping.uio.no>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp3cz5v7rp.fsf>