From owner-freebsd-arch Tue Mar 12 13: 1:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AB6F437B405; Tue, 12 Mar 2002 13:01:05 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2CL0fnp014702; Tue, 12 Mar 2002 22:00:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-Reply-To: Your message of "12 Mar 2002 21:41:14 +0100." Date: Tue, 12 Mar 2002 22:00:41 +0100 Message-ID: <14701.1015966841@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , 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