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. > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
