AIX Version 4.3 Differences Guide

The addr struct is a library-side structure that holds the information relevant to the
remapping of the address of a single 64-bit area. It also holds the size of the
structure pointed to. Segment crossings are allowed for items in the addr struct,
with the limitation that a single item to remap may not be contained in more than
fifteen segments. This limits the maximum size of an object to be remapped to
3.75 GB, assuming that it is aligned to a segment boundary.
The uremap struct is a library-side structure that consists of an array of addr
structs and an integer giving the size of the array. In the general case, the
number of entries can be quite large, such as the number of addresses of
environment variables passed on execve(). The size is set at 17 in the structure
definition to cover cases that need to pass this many addresses (writev() is one
such case). Cases with more than 17 addresses require individually-constructed
structs similar to uremap or just the C-allowed use of an index greater than an
array-size, with appropriate storage malloc()’d by the caller. The naddr field of the
uremap struct can accommodate large numbers of addr structs input. The point is
that __remap() is not limited to 17 addresses to remap on one call. It can accept
a large quantity. As of this writing, the upper bound has not been set. The number
17 was specifically arrived at from the iovec struct. 17 is iovcnt+1 to allow for the
vectors plus the address of the structure itself.
The remap struct is the basic data structure used to communicate remapping
information from the library side to the kernel extension. A single remap struct
contains an unremapped 64-bit address (actually ESID), and additionally, the low
bits of a remap struct (address) also have meaning. This will be discussed later.
The kremap struct is an array of remap structs plus an integer giving the number
of array elements actually used. In the general case, this structure is passed by
the library side to the kernel extension, which accesses it through copyin64(). The
elements of the r[.] array represent up to fifteen unremapped 64-bit addresses.
The remapping code gets the right answer implicitly by making sure that the
library remap code and the kernel remap code allocate srnos in the same order
while processing the kremap struct. It is particularly important, for segment
crossings, that adjacent segments become allocated in the kernel as needed.
The r_xingcnt field in the remap struct is used to indicate the number of segments
that a particular mapping crosses, so the segments may be created adjacently.
It is important not to confuse the uremap and kremap structures. The uremap
structures are where the full 64-bit to 32-bit address translations are kept for each
64-bit address remapped. The kremap structs are passed to the kernel and
indicate on a segment-basis which 64-bit ESIDs are remapped to which 32-bit
sreg numbers. The mapping of entries in a uremap struct to entries in a kremap
struct is typically many-to-one. For example, two pointers in the same ESID will
create two uremap entries and one kremap entry.
3.2.2.4 Remap Library Programming Interfaces
The remap library services set up the remap data structures to be passed to the
kernel remap services. There are three library remapping interfaces:
union __remap_handle __remap(struct uremap *up, struct kremap *kp)
struct remap __remap1(struct addr *ua)
void __remap2(struct addr *ua, struct kremap *kp)
42 AIX Version 4.3 Differences Guide