From: Zachary Amsden <zach@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Ingo Molnar <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] paravirt_ops: Use unsigned long instead of u32 for alloc_p*() pfn args
Date: Wed, 30 Jul 2008 14:59:53 -0700 [thread overview]
Message-ID: <1217455193.30348.341.camel@bodhitayantram.eng.vmware.com> (raw)
In-Reply-To: <4890E251.1090008@goop.org>
On Wed, 2008-07-30 at 14:51 -0700, Jeremy Fitzhardinge wrote:
> Eduardo Habkost wrote:
> > This patch changes the pfn args from 'u32' to 'unsigned long'
> > on alloc_p*() functions on paravirt_ops, and the corresponding
> > implementations for Xen and VMI. The prototypes for CONFIG_PARAVIRT=n
> > are already using unsigned long, so paravirt.h now matches the prototypes
> > on asm-x86/pgalloc.h.
> >
> > It shouldn't result in any changes on generated code on 32-bit, with
> > or without CONFIG_PARAVIRT. On both cases, 'codiff -f' didn't show any
> > change after applying this patch.
> >
> > On 64-bit, there are (expected) binary changes only when CONFIG_PARAVIRT
> > is enabled, as the patch is really supposed to change the size of the
> > pfn args.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> >
> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> Cc:ing Zach, since it touches vmi.
Thanks, looks good to me. I always thought u32 is ugly type name anyway.
Acked-by: Zachary Amsden <zach@vmware.com>
next prev parent reply other threads:[~2008-07-30 22:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 21:32 [PATCH] paravirt_ops: Use unsigned long instead of u32 for alloc_p*() pfn args Eduardo Habkost
2008-07-30 21:51 ` Jeremy Fitzhardinge
2008-07-30 21:59 ` Zachary Amsden [this message]
2008-07-31 21:51 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1217455193.30348.341.camel@bodhitayantram.eng.vmware.com \
--to=zach@vmware.com \
--cc=ehabkost@redhat.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.