Quoting Benjamin Herrenschmidt (benh@xxxxxxxxxxxxxxxxxxx): > 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. > > 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. Absolutely, but the accepted way to handle that so far is that if you want to run an "incompatible" checkpoint image on a new cpu, a userspace program will rewrite the image to be correct for the target cpu. But what you list below seems more usable than trying to encapsulate that info in some hokey version number system. > 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. > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
