AIX Version 4.3 Differences Guide

3.2.2.7 Optimizations for One or Two Parameters
The library-side and the kernel-side remap routines have optimizations built into
them to pass one or two parameters by value if possible. This provides a
significant improvement over requiring a full copyin64() of the kremap structure
every time. There are three cases that the remap() code has to handle:
• The output library remapping resulted in only one remapping or remap struct
(R_IN_LINE - see the following).
• The output remapping resulted in two remappings, and __remap2() was called
(with two addr structs only).
• The output remapping resulted in more than one remapping if __remap() was
called.
The low order bit of the cookie passed to the kernel remap services, all the way
from the library, identifies what the cookie actually is. For example, although
remap_64() is documented to have a struct remap() passed to it, if the
R_IN_LINE bit is not set in this, then this struct remap is a pointer to a struct
kremap, on which a copyin64() must be performed. If, however, the R_IN_LINE
bit is set on input, then that indicates that all of the parameters collapsed into a
single remapping in the library (case 1), and remap_64() can call remap1_64() to
do the work. This avoids the copyin() when many parameters reside in the same
segment (ESID). This should be a common case.
The R_IN_LINE flag is interpreted differently by the remap2_64() kernel service.
The __remap2() subroutine sets the R_IN_LINE flag in the first remap struct if the
output remappings collapsed into one. This indicates that the second parameter
to remap2_64() should be ignored. See the next section for coding and calling
conventions for __remap2().
3.2.2.8 Using the Remapping Services
There are very rigid rules on how to invoke the remapping services and how to
handshake with the kernel-side remapping wrappers. Typically, whatever library
remapping service was invoked for a particular wrapper, it should have the
corresponding kernel remapping service called as well. For example, if
__remap2() is called in the library wrapper, the kernel-extension should call
remap2_64().
The following is very important:
• For a given system call, it is only permissible to make a single call to the
remapping kernel services. In other words, it is not legal to call remap_64()
twice on the same system call. Similarly, it is not legal to call remap1_64() and
then remap2_64() on the same system call.
To detect potential misuse of the remapping services, the remap data structures
are coded with a unique code for whichever library remap service created them. If
a kernel service other than the correct one for a given library service is called, an
error will result. For example, callers of __remap1() must call remap1_64().
Typically, a library wrapper will call a remap service and check if the return code
is -1. If so, it will fail. After that, the returned value remap structure from the
particular __remap* service is passed as the first parameter. If this is a
__remap2() call, the first parameter is kremap.r[0], and the second parameter is
kremap.r[1]. Of course, each of these parameters is split into two 32-bit registers.
64-Bit Enablement 45