AIX kernel extensions run in 32-bit mode, even when processing requests made by 64-bit applications. This allows kernel extensions which were built for AIX releases which only supported 32-bit systems to run on AIX releases which support both 32-bit and 64-bit systems. For these old kernel extensions and all kernel extensions which have not been designed to work with 64-bit applications, only 32-bit applications can be supported. A 64-bit application will fail to link if it attempts to make use of a system call from a kernel extension that has not been modified to support 64-bit applications.
A kernel extension can indicate that it supports 64-bit applications by setting the SYS_64BIT flag when it is loaded using the sysconfig routine.
Kernel extension support for 64-bit applications has two aspects.
The first aspect is the use of new kernel services for working with the 64-bit user address space. The new 64-bit services for examining and manipulating the 64-bit address space are as_att64, as_det64, as_geth64, as_puth64, as_seth64, and as_getsrval64. The new services for copying data to or from 64-bit address spaces are copyin64, copyout64, copyinstr64, fubyte64, fuword64, subyte64, and suword64. The new service for doing cross-memory attaches to memory in a 64-bit address space is xmattach64. The new services for creating real memory mappings are rmmap_create64 and rmmap_remove64. The major difference between all these services and their 32-bit counterparts is that they use 64 bit user addresses rather than 32 bit user addresses.
The new service for determining whether a process (and its address space) is 32-bit or 64-bit is IS64U.
The second aspect of supporting 64-bit applications is taking 64 bit user data passed to system calls and transforming that data to 32 bit data which can be passed through the system call handler to the kernel extension. If the types of the parameters passed to a system call are all 32 bit sized or smaller (in 64-bit compilation mode), then no extra work is required. However, if 64-bit data (long or long long C types) or addresses are passed to the system call, then the data must be split and passed in two parameters or transformed into a 32-bit value.
To assist in using 64-bit user addresses in kernel mode, a set of "remapping" services are provided which transform the 64 bit user addresses into 32 bit addresses which can be used by most of the old 32-bit user address manipulation services in the kernel. In this way, kernel code which has not been modified to work with 64-bit user addresses can always use the 32 bit address (either from a 32-bit application or as a transformed 64-bit address from a 64-bit application). Services such as copyin, copyout, xmattach, fuword, fubyte, suword, and subyte will correctly work with the 32-bit address by transforming it back to a 64-bit address.
The remapping services consist of a set of routines which can be called (in 64-bit execution mode) from a library and a matching set of routines which can be called (in 32-bit mode) from a kernel extension. The library routines determine which 32-bit addresses should be matched to each 64-bit address and package this information in a data structure to be passed to the kernel. The library then passes all the parameters (including the 32-bit addresses which were associated with the 64-bit addresses) through the 64-bit system call to the kernel extension.
The kernel extension passes the remapping information (created by the library remapping routine) to the remapping kernel service, which saves it for use by address space services for the duration of that system call.
A limited number of addresses can be remapped because remapping must be done on a segment (256K bytes) basis. One address remapping can use multiple of these segments, depending on the location of the address relative to a segment boundary and depending on the length of the address range being remapped. Multiple address remappings can utilize a single segment of remapping if they all happen to fall in the range of a single segment.
To simplify the use of these remapping services, a set of macros have been declared (in sys/remap.h) which hide many of the underlying details. These macros should be used to avoid mistakes in the use of the underlying services. REMAP_DCL is used to declared the data structures used by the other services. REMAP_SETUP and REMAP_SETUP_WITH_LEN are used to fill in the data structures with the 64-bit addresses and lengths. REMAP, REMAP_VOID, REMAP_IDENTITY, and REMAP_IDENTITY_VOID are called by the library to determine the remappings. REMAP_64 and REMAP_64_VOID are called by the kernel extension to register the remapping information with the kernel.