From: "H. Peter Anvin" <hpa@zytor.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: randy.dunlap@oracle.com, arnd@arndb.de,
Albert Cahalan <acahalan@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linuxppc-dev@lists.ozlabs.org, roland@redhat.com
Subject: Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
Date: Wed, 09 Jun 2010 11:46:19 -0700 [thread overview]
Message-ID: <4C0FE17B.10108@zytor.com> (raw)
In-Reply-To: <20100609181431.GB1211@us.ibm.com>
On 06/09/2010 11:14 AM, Sukadev Bhattiprolu wrote:
> |
> | Even for x86, it's an easier API. Callers would be specifying
> | two numbers they already have: the argument and return value
> | for malloc. Currently the numbers must be added together,
> | destroying information, except on hppa (must not add size)
> | and ia64 (must use what I'm proposing already).
>
> I agree its easier and would avoid #ifdefs in the applications.
>
> Peter, Arnd, Roland - do you have any concerns with requiring all
> architectures to specify the stack to eclone() as [base, offset]
>
Makes sense to me. There might be advantages to be able to track the
size of the "stack allocation" even for other architectures, too.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Albert Cahalan <acahalan@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
randy.dunlap@oracle.com, linuxppc-dev@lists.ozlabs.org,
roland@redhat.com, arnd@arndb.de
Subject: Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
Date: Wed, 09 Jun 2010 11:46:19 -0700 [thread overview]
Message-ID: <4C0FE17B.10108@zytor.com> (raw)
In-Reply-To: <20100609181431.GB1211@us.ibm.com>
On 06/09/2010 11:14 AM, Sukadev Bhattiprolu wrote:
> |
> | Even for x86, it's an easier API. Callers would be specifying
> | two numbers they already have: the argument and return value
> | for malloc. Currently the numbers must be added together,
> | destroying information, except on hppa (must not add size)
> | and ia64 (must use what I'm proposing already).
>
> I agree its easier and would avoid #ifdefs in the applications.
>
> Peter, Arnd, Roland - do you have any concerns with requiring all
> architectures to specify the stack to eclone() as [base, offset]
>
Makes sense to me. There might be advantages to be able to track the
size of the "stack allocation" even for other architectures, too.
-hpa
next prev parent reply other threads:[~2010-06-09 19:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-29 10:31 [PATCH v21 011/100] eclone (11/11): Document sys_eclone Albert Cahalan
2010-06-01 19:32 ` Sukadev Bhattiprolu
2010-06-01 19:32 ` Sukadev Bhattiprolu
2010-06-01 19:59 ` Albert Cahalan
2010-06-01 19:59 ` Albert Cahalan
2010-06-02 1:38 ` Sukadev Bhattiprolu
2010-06-02 1:38 ` Sukadev Bhattiprolu
2010-06-05 11:49 ` Albert Cahalan
2010-06-05 11:49 ` Albert Cahalan
2010-06-05 11:58 ` Albert Cahalan
2010-06-05 11:58 ` Albert Cahalan
2010-06-05 12:08 ` Albert Cahalan
2010-06-05 12:08 ` Albert Cahalan
2010-06-09 18:14 ` Sukadev Bhattiprolu
2010-06-09 18:14 ` Sukadev Bhattiprolu
2010-06-09 18:46 ` H. Peter Anvin [this message]
2010-06-09 18:46 ` H. Peter Anvin
2010-06-09 22:32 ` Roland McGrath
2010-06-09 22:32 ` Roland McGrath
2010-06-10 9:15 ` Arnd Bergmann
2010-06-10 9:15 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2010-05-01 14:14 [PATCH v21 00/100] Kernel based checkpoint/restart Oren Laadan
[not found] ` <1272723382-19470-1-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-05-01 14:14 ` [PATCH v21 011/100] eclone (11/11): Document sys_eclone Oren Laadan
2010-05-01 14:14 ` Oren Laadan
2010-05-01 14:14 ` Oren Laadan
[not found] ` <1272723382-19470-12-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-05-05 21:14 ` Randy Dunlap
2010-05-05 21:14 ` Randy Dunlap
2010-05-05 21:14 ` Randy Dunlap
2010-05-05 21:14 ` Randy Dunlap
[not found] ` <20100505141447.fc2397f6.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2010-05-05 22:25 ` Sukadev Bhattiprolu
2010-05-05 22:25 ` Sukadev Bhattiprolu
2010-05-05 22:25 ` Sukadev Bhattiprolu
2010-05-05 22:25 ` Sukadev Bhattiprolu
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=4C0FE17B.10108@zytor.com \
--to=hpa@zytor.com \
--cc=acahalan@gmail.com \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=randy.dunlap@oracle.com \
--cc=roland@redhat.com \
--cc=sukadev@linux.vnet.ibm.com \
/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.