[PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation

[Oren Laadan]

Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
>> * Anything that is decided at compiled time should probably go to the arch-
>> dependent header.
>>
>> * Anything that can change at boot time (e.g., for x86 that would include
>> the capabilities of the FPU), or even run time (is there any ?) should
>> be described to the letter (in fine print) in 'struct cr_hdr_cpu' and
>> friends.
> 
> I think we should avoid compile time completely.

For instance, TASK_COMM_LEN is currently defined as 16; but in future
(or custom) kernel it may be different; so in the task header I put a
field that explicitly indicates this length, just in case. I think it's
useful to be able to detect such inconsistencies.

(of course this example is not arch-specific; and it would be wiser to
have one such entry for the entire checkpoint image instead of one for
each process)

I concur with the rest below.

Oren

> 
> We mostly try to have kernels running on everything anyway, and there's
> no reason not to be able to move a snapshot to a different CPU if it's
> not using a feature of the CPU that is different.
> 
> Nathan, what about you start the structure with a 64 bit bitmask that
> indicates what "records" are present followed by concatenated records ?
> 
> IE. The "main" state (pt_regs) wouldn't change, but then, you could have
> a list of things:
> 
>  - FPRs
>  - old style VSX
>  - VSRs
>  - Freescale SPE state
>  - DABR
>  - BookE IAC/DACs
>  - tbd...
> 
> Then, when resuming a snapshot, we can use some bit masks trickery
> indicating the validity on a given target. IE. If CPU has no VSX and
> original program uses VSX then you can't resume. But if CPU has VSR you
> can.. etc... We can keep it trivial at fist, especting the same
> features, and try to be smart later.
> 
> Ben.
> 
> 
>