linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [C/R ARM][PATCH 3/3] c/r: ARM implementation of checkpoint/restart
Date: Tue, 23 Mar 2010 21:18:43 +0000	[thread overview]
Message-ID: <20100323211843.GC19572@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1269219965-23923-4-git-send-email-christofferdall@christofferdall.dk>

On Sun, Mar 21, 2010 at 09:06:05PM -0400, Christoffer Dall wrote:
> The ISA version (given by __LINUX_ARM_ARCH__) is checkpointed and verified
> against the machine architecture on restart.

I think you misunderstand what __LINUX_ARM_ARCH__ signifies.  It is the
build architecture for the kernel, and it indicates the lowest
architecture version that the kernel will run on.

That doesn't indicate what ISA version the system is running on, or even
if the ABI is compatible (we have two ABIs - OABI and EABI).

There's also the matter of FP implementation - whether it is VFP or FPA,
and whether iwMMXt is available or not.  (iwMMXt precludes the use of
FPA.)

> Regarding ThumbEE, the thumbee_state field on the thread_info is stored
> in checkpoints when CONFIG_ARM_THUMBEE and 0 is stored otherwise. If
> a value different than 0 is checkpointed and CONFIG_ARM_THUMBEE is not
> set on the restore system, the restore is aborted. Feedback on this
> implementation is very welcome.

I don't recognise this configuration symbol; it doesn't exist in mainline.

> We checkpoint whether the system is running with CONFIG_MMU or not and
> require the same configuration for the system on which we restore the
> process. It might be possible to allow something more fine-grained,
> if it's worth the energy. Input on this item is also very welcome,
> specifically from someone who knows the exact meaning of the end_brk
> field.

Processes which run on MMU and non-MMU CPUs are unlikely to be
interchangable - the run time environments are quite different.  I
think this is a sane check.

> +/* dump the thread_struct of a given task */
> +int checkpoint_thread(struct ckpt_ctx *ctx, struct task_struct *t)
> +{
> +	int ret;
> +	struct ckpt_hdr_thread *h;
> +	struct thread_info *ti = task_thread_info(t);
> +
> +	h = ckpt_hdr_get_type(ctx, sizeof(*h), CKPT_HDR_THREAD);
> +	if (!h)
> +		return -ENOMEM;
> +
> +	/*
> +	 * Store the syscall information about the checkpointed process
> +	 * as we need to know if the process was doing a syscall (and which)
> +	 * during restart.
> +	 */
> +	h->syscall = ti->syscall;
> +
> +	/*
> +	 * Store remaining thread-specific info.
> +	 */
> +	h->tp_value = ti->tp_value;

How do you safely obtain consistent information from a thread?  Do you
temporarily stop it?

  parent reply	other threads:[~2010-03-23 21:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22  1:06 [C/R ARM][PATCH 0/3] Linux Checkpoint-Restart - ARM port Christoffer Dall
2010-03-22  1:06 ` [C/R ARM][PATCH 1/3] ARM: Rudimentary syscall interfaces Christoffer Dall
2010-03-23 20:53   ` Russell King - ARM Linux
2010-03-24  2:03     ` Matt Helsley
2010-03-24  4:57       ` Oren Laadan
2010-03-24 14:02         ` Matt Helsley
2010-03-24 15:53           ` Oren Laadan
2010-03-24 19:36             ` Christoffer Dall
2010-03-25  1:11               ` Matt Helsley
2010-03-25  1:17                 ` Matt Helsley
2010-03-25 10:29                   ` Christoffer Dall
2010-03-25  1:35                 ` Oren Laadan
2010-03-25 10:34                   ` Christoffer Dall
2010-03-22  1:06 ` [C/R ARM][PATCH 2/3] ARM: Add the eclone system call Christoffer Dall
2010-03-23 21:06   ` Russell King - ARM Linux
2010-03-24 18:19     ` Sukadev Bhattiprolu
2010-03-24 19:42     ` Christoffer Dall
2010-03-22  1:06 ` [C/R ARM][PATCH 3/3] c/r: ARM implementation of checkpoint/restart Christoffer Dall
2010-03-23 16:09   ` Serge E. Hallyn
2010-03-24 19:46     ` Christoffer Dall
2010-03-23 21:18   ` Russell King - ARM Linux [this message]
2010-03-24  1:53     ` Matt Helsley
2010-03-24 20:48     ` Christoffer Dall
2010-03-26  2:47       ` Jamie Lokier
2010-03-26  3:02         ` Paul Mundt
2010-03-26  3:55           ` Jamie Lokier
2010-03-28 22:55           ` Christoffer Dall

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=20100323211843.GC19572@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).