On Friday 08 August 2008, Oren Laadan wrote:
It seems weird that you use __u64 members for the registers, but don'tIn the context of CR, x86-32 and x86-64 are distinct architectures because
include r8..r15 in the list. As a consequence, this structure does not
seem well suited for either x86-32 or x86-64.
you cannot always migrate from one to the other (though 32->64 is sometimes
possible). Therefore, each architecture can have a separate checkpoint file
format (eg r8..r15 only for x86-64).
So why do you use __u64 members for your 32 bit registers?
Except for this special case (32 bit running 64 bit), simple conversion can
be done in the kernel if needed, but most conversion between kernel the
format for different kernel versions (should it change) can be done in
user space (eg. with a filter).
The 32bit on 64bit case is quite common on non-x86 architectures, e.g.
powerpc or sparc, where 64 bit kernels typically run 32 bit user space.
A particularly interesting case is mixing 32 and 64 bit tasks in a container
that you are checkpointing. This is a very realistic scenario, so there
may be good arguments for keeping the format identical between the variations
of each architecture.
I would suggest either using struct pt_regs by reference, or definingWe prefer not to use the kernel structure directly, but an intermediate
it so that you can use the same structure for both 32 and 64 bit x86.
structure that can help mitigate subtle incompatibilities issues (between
kernel configurations, versions, and even compiler versions).
Anyway, either a single structure for both 32 and 64 bit x86, or separate
"struct cr_hdr_cpu{_32,_64}", one for each architecture.
struct pt_regs is part of the kernel ABI, it will not change.