From owner-freebsd-arch Sat Mar 30 8:42:58 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 526FC37B416 for ; Sat, 30 Mar 2002 08:42:53 -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 g2UGdle7003838 for ; Sat, 30 Mar 2002 17:39:48 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: Rewamping kernel dumps... From: Poul-Henning Kamp Date: Sat, 30 Mar 2002 17:39:47 +0100 Message-ID: <3837.1017506387@critter.freebsd.dk> 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 Here is what I plan to do to the kernel dumping code. Device drivers can provide a dumping function, which will act as an blocked sequential write device. This _can_ be the traditional swap-partition-on-disk, but it could also be tapes or TFTP over a network interface. The function has the following type: typedef int dumper_t( void *private, /* Private to the driver. */ void *virtual, /* Virtual (mapped) address. */ void *physical, /* Physical address of virtual. */ off_t length); /* Number of bytes to dump. */ To register a dumping function, the driver fills out a data structure and calls set_dumper(): struct dumperinfo { dumper_t *dumper; /* Dumping function. */ void *private; /* Private parts. */ u_int blocksize; /* Size of block in bytes. */ off_t mediasize; /* Space available in bytes. */ }; int set_dumper(struct dumperinfo *); Only one dumping function can be registered at a time, the current registration can be cleared by calling set_dumper(NULL); Once a dump is desired, a MD function is called: void dumpsys(struct dumperinfo *); This function must dump any magic headers and any desired memory in whatever order the format for the platform is by repeatedly calling the struct dumperinfo->dumper function. If the dumper function returns non-zero, the dump should be aborted since the hardware (presumably) failed. The configuration mechanism for disks will change so that dumpon(8) will open the device and issue an ioctl to turn dumping on this device on/off, rather than the current sysctl based mechanism. I understand that various people have some ideas about the layout of the dump on the sequential media, this is an area I will not be involved in, and I suggest people interested hash this out somehow. Comments ? -- 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