From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kip Macy Subject: Re: policies on coredump Date: Wed, 27 Apr 2005 17:57:11 -0700 Message-ID: References: <200504280047.57968.mark.williamson@cl.cam.ac.uk> <200504280143.59630.mark.williamson@cl.cam.ac.uk> Reply-To: Kip Macy Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <200504280143.59630.mark.williamson@cl.cam.ac.uk> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Williamson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org My plan is for coredump to write out the domain state in a generic format and then post-process that into the format expected by the kernel GDB for a given OS. I can envision using the suspend support for offline state inspection by simply post-processing the output of suspend to disk into coredump format. I don't see anyone else clamoring to use xen as a development environment so I'll worry about that later. -Kip =20 On 4/27/05, Mark Williamson wrote: > > If it is in the reap path is there any reason to add it to xm as well > > other than testing? >=20 > I guess that now, for most things, you could use the gdbserver to poke at= the > state of domains that hadn't crashed (and auto-dumped) yet... Under some > circumstances it might be useful to manually dump domain state for later > analysis. >=20 > Unless anybody pipes up and asks then I guess it might not be worth addin= g. > It's probably worth getting the reap-path patch into the tree in the firs= t > instance - then other people can contribute patches to enable any use cas= es > they want ;-) >=20 > Cheers, > Mark >