105
edits
Changes
Jump to navigation
Jump to search
Line 18:
Line 18: + + + + + + + + + +
Add a note about mixed-bitness applications
From the Linux kernel's point of view, applications differ by values set during exec of application such as <code>mmap_base</code> or thread info flags <code>TIF_ADDR32</code>/<code>TIF_IA32</code>/<code>TIF_X32</code>.
From the Linux kernel's point of view, applications differ by values set during exec of application such as <code>mmap_base</code> or thread info flags <code>TIF_ADDR32</code>/<code>TIF_IA32</code>/<code>TIF_X32</code>.
Both native and compat applications can do 32 or 64-bit syscalls.
Both native and compat applications can do 32 or 64-bit syscalls.
== Mixed-bitness applications ==
That's entirely possible with current kernel ABI to create mixed-bitness applications, which may be ''very'' entangled.
For example, one could set ''both'' 32-bit and 64-bit robust futex list pointers.
Or one can create multi-threaded application where some threads are executing 32-bit code, some 64-bit code.
If we ever meet application of such mixed-bitness kind, the support may be added to CRIU quite easily, but it should be done under some compile-time config as it'll add more syscalls to usual C/R where they aren't needed.
At this moment there is no plans to add such support and it's quite unlikely that we'll find such application in real world (non-syntetic test).
== Approaches to C/R compatible applications ==
== Approaches to C/R compatible applications ==