|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code
To: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code |
From: |
Horms <horms@xxxxxxxxxxxx> |
Date: |
Tue, 17 Oct 2006 10:25:21 +0900 |
Cc: |
Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, magnus.damm@xxxxxxxxx, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx> |
Delivery-date: |
Thu, 19 Oct 2006 09:22:17 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C1594FC1.2934%Keir.Fraser@xxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<20061016083324.7611.3312.sendpatchset@localhost> <C1594FC1.2934%Keir.Fraser@xxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
mutt-ng/devel-r804 (Debian) |
On Mon, Oct 16, 2006 at 03:03:29PM +0100, Keir Fraser wrote:
> Some comments:
>
> No need for IO-APIC work on the guest side of the kexec interfaces (e.g.,
> don't call disable_IO_APIC()).
>
> What's the second argument to the hypercall for? There's no clear
> explanation of what the TYPE parameter means, and currently it is only ever
> specified as TYPE_CRASH. So what's TYPE_DEFAULT for? And do we really need
> to avoid copy_to/from_guest so it can't be folded into the structural
> parameter?
TYPE_DEFAULT is kexec, TYPE_CRASH is kdump.
Its just to avoid a from_guest. If you think that isn't worthwhile
we can fold it into the structural parameter.
> The comment attached to every use of xchg() is dubious. We don't specify
> warn_unused_result on that function so there's no good reason for the
> compiler to complain about discarding the result. If it's a reproducible
> problem it needs investigating. We shouldn't work around a broken compiler.
I certainly saw the problem. I'll do some more investigations.
... Actually now that I think about it for a moment, perhaps it was
inheriting -Wall from CFLAGS in my environment. If that is the case,
then I think the work-around I added is valid.:wq
> Attribution at the top of many files: 'Horms' is a bit vague. Could we have
> a full name? A company name? An email address?
Sure.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, (continued)
- Re: [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Horms
- Re: [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Keir Fraser
- Re: [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Adam Heath
- Re: [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Horms
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code,
Horms <=
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Keir Fraser
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Horms
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Keir Fraser
- [Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code, Horms
[Xen-devel] [PATCH 02/04] Kexec / Kdump: Code shared between x86_32 and x86_64, Magnus Damm
[Xen-devel] [PATCH 03/04] Kexec / Kdump: x86_32 specific code, Magnus Damm
[Xen-devel] [PATCH 04/04] Kexec / Kdump: x86_64 specific code, Magnus Damm
|
|
|
|
|