Date: Sat, 30 Mar 2002 17:39:47 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: Rewamping kernel dumps... Message-ID: <3837.1017506387@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3837.1017506387>