I''m soliciting opinions on where domU coredumps should be put, if they should be enabled by default, and what the default naming convention should be. This will probably all have to change when capabilities are added, but in the meantime I''d like to know before I submit a patch. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I''m soliciting opinions on where domU coredumps should be put,/var/xen/dump/ perhaps?> if they > should be enabled by defaultHrrrmmmmm. I guess I''d err towards not enabling them by default - as long as we document it (fancy including a patch to the user manual? ;-)). This is on the grounds that people who will use this feature will know who they are and go switch it on.> and what the default naming convention > should be.Howsabout domainname.{0,1,2,3...} ? The textual domain name will be available in Xend and is a bit more useful than the domid, particularly if you''re running many domains.> This will probably all have to change when capabilities are > added, but in the meantime I''d like to know before I submit a patch.I don''t think capabilities are coming up for a while, though I''ve not heard anything about it recently. I bet you can get your patch in first anyhow ;-) Are you planning to hook into Xend''s reaper function to do this automatically and / or provide an xm command for manual dumps? Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Are you planning to hook into Xend''s reaper function to do this automatically > and / or provide an xm command for manual dumps?If it is in the reap path is there any reason to add it to xm as well other than testing? -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> If it is in the reap path is there any reason to add it to xm as well > other than testing?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. Unless anybody pipes up and asks then I guess it might not be worth adding. It''s probably worth getting the reap-path patch into the tree in the first instance - then other people can contribute patches to enable any use cases they want ;-) Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
On 4/27/05, Mark Williamson <mark.williamson@cl.cam.ac.uk>
wrote:> > If it is in the reap path is there any reason to add it to xm as well
> > other than testing?
>
> 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.
>
> Unless anybody pipes up and asks then I guess it might not be worth adding.
> It''s probably worth getting the reap-path patch into the tree in
the first
> instance - then other people can contribute patches to enable any use cases
> they want ;-)
>
> Cheers,
> Mark
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel