Date: Tue, 12 Mar 2002 22:00:41 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Dag-Erling Smorgrav <des@ofug.org> Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite Message-ID: <14701.1015966841@critter.freebsd.dk> In-Reply-To: Your message of "12 Mar 2002 21:41:14 %2B0100." <xzp3cz5v7rp.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzp3cz5v7rp.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
>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:
`) Device driver or proxy for it register their ability to do dumps
with the kernel, informing the kernel about the number of bytes
they have room for (and the sector size of the media ?).
With or without GEOM we need to be certain to hit the right spot
on the disk. This includes tracking of "the right spot" gets
moved or deleted due to disklabel/MBR modifications.
>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.
These functions could profitably be registered in step `) above
rather than pollute struct devsw.
>c) the on-disk format will be as follows:
Make it XML while we're at it ? All it costs in the kernel is
a bit more text in the printfs.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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?14701.1015966841>