Date: Sun, 31 Mar 2002 14:10:37 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Rewamping kernel dumps... Message-ID: <20020331133114.A4567-100000@gamplex.bde.org> In-Reply-To: <3837.1017506387@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Mar 2002, Poul-Henning Kamp wrote:
> 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. */
The type of `physical' is bogus. It should be vm_offset_t. I'm not
sure if physical addresses are necessary or good here. It is only
useful if the memory region is contiguous. But physical addresses can
be recovered easily from virtual addresses even if the memory is
discontiguous. The memory should just be contiguous to permit dump
routines to be as simple as possible.
The type of `length' is bogus. It should be size_t or vm_size_t.
off_t is for lengths of files, not for sizes of memory. dumpstatus()
has the same bogon.
> 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);
Not necessary or good. The current d_dump entry point is sufficient,
provided its type is changed to something like that above and its
semantics is changed to always do a complete intialization and
finalization for each memory region. The dump function needs to be
told where to write the dump (for each memory region) so that all dump
functions doesn't have to know about layers like slices and partitions.
You would need something like the above to handle non-disks, but I
think it should not be designed before we have experience with non-disk
dump routines. Dumps to tape probably shouldn't do a finalization for
each memory region... It's probably right for dump routines for non-disks
to make their devices look like disks (accept memory regions that are
blocked suitably for disks, and add headers and padding if necessary to
compensate for unusual block sizes).
> 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.
sysctls are wrong for almost everything :-).
Bruce
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?20020331133114.A4567-100000>