Re: [PATCH 00/04] Kexec / Kdump: Release 20061023 (xen-unstable-11856)

[Magnus Damm <magnus@valinux.co.jp>]

Hi Keir!

I thought that my latest patchset ended up in a spam filter somewhere,
but it seems like it finally made it through to xen-devel!

On Wed, 2006-10-25 at 11:10 +0100, Keir Fraser wrote:
> 
> 
> On 23/10/06 10:05, "Magnus Damm" <magnus@valinux.co.jp> wrote:
> 
> > 20060931 - Take XIV for xen-unstable-11296 posted by Simon Horman
> > 
> > Enjoy!
> 
> A couple of comments on this patchset:
> 
> Firstly, the new public header file is nicely laid out and commented
> but
> it'd be nice to add some comments to the KEXEC_TYPE_* definitions
> explaining
> what they mean. Also the same for xen_kexec_image_t (what do
> indirection_page and start_address mean?). As far as possible it would
> be
> good to have an explanation of the Xen kexec interface that stands
> alone and
> allows independent implementation to that interface (e.g., in Solaris)
> with
> as little need to crib from other kexec implementations as possible.
> So, for
> example, adding a short 'story board' comment explaining the sequence
> of
> hypercalls that would be used to set up and execute a kdump or kexec
> would
> be useful. It would be very hard to add *too many* helpful
> comments. :-)

Yeah, you can never have too many comments. I definitely agree that some
kind of story board would be nice too.

In theory it should be possible to add an independent implementation
that works with our interface, but the values passed are quite tightly
bound together with the current kexec implementation. A good example of
that is the indirection_page which is a list of pages and their
destination addresses. This page together with the start_address is used
by the code page, ie the page that is passed in page_list[0]. But we
don't actually touch that much data in the hypervisor, we just pass the
data along to the code in the code page that does the rest for us.

But more documentation, yes - added to the TODO list.

> Secondly, you appear to stuff over 1000 lines of code into the
> patches/
> directory. What is that all about? Will it go away when we move to a
> more
> recent Linux kernel (which would be an argument to hold off on merging
> until
> we have done that)?

All the git-<nnn>.patch-patches are taken from Linus git tree. They are
patches that are merged in 2.6.19-rc1. Some of the patches are needed,
and a few are pushed in just to make the other ones apply.

So yes, patches will go away. At least most of them. I have not started
trying to merge the other smaller patches yet. It is kind of difficult
to get things merged upstream when Xen is not merged yet. But if I could
say that my changes are merged into Xen then it would probably be
easier... =)

I don't think see why you should wait with the merge. But it's your call
of course. My plan is to address the issues you pointed out together
with some kdump fixes and resend early next week. How does that work
with the grand merge plan?

Thanks!

/ magnus