AIX Version 4.3 Differences Guide
AIX Version 4.3 Differences Guide
AIX Version 4.3 Differences Guide
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
It is also possible to have a situation similar to the preceding example, except<br />
that the second remapping could touch fifteen segments, starting with ESID 2.<br />
This case would fail the first pass, and a second pass becomes necessary to sort<br />
them into ascending order. Although this second pass, when required, does add<br />
some overhead, it guarantees that the ranges to be mapped will fit into fifteen<br />
segments.<br />
3.2.2.6 Remap Kernel Programming Interfaces<br />
There are remapping programming interfaces that are exported to kernel<br />
extensions from the kernel. These are primarily for use by the 64-bit kernel<br />
extension; however, applications that add their own system calls will need these<br />
as well. For this reason, these services take up regular namespace and are not<br />
prefixed with an underscore. See the man pages for formal documentation of<br />
these routines as_unremap64() is intended for kernel extensions that really need<br />
to have the unremapped address.<br />
The library-side maps 64-bit addresses to 32-bit in that it selects the sreg<br />
numbers to correspond to the ESIDs of the 64-bit addresses. However, the<br />
kernel-extension still has to update the address space map for the 64-bit thread<br />
to reflect these values, so that when the kernel uses these 32-bit addresses to<br />
access memory, the proper SID will be inferred. These services update the<br />
MST-extension remap struct described previously:<br />
int remap_64(struct remap r)<br />
int remap1_64(struct remap r)<br />
int remap2_64(struct remap r1, struct remap r2)<br />
unsigned long long as_unremap64(uint addr32)<br />
The reason for three different remap routines is to optimize for cases where only<br />
one or two ESIDs are used. This is a very common case. The remap_64() call<br />
handles the case of greater than two remap structs input as well as all other<br />
cases. Parameters to remap1_64() and remap2_64() are passed entirely in<br />
registers, so these routines do not have to copyin() a remap struct from<br />
user-mode.<br />
There is also an internal kernel routine, remap(), that is used by copyin64() and<br />
others. The purpose of remap() is to support 64-bit-enabled code in the kernel<br />
that handles non-remapped addresses. Code calling remap() passes the address<br />
of a remap-like struct on the stack (typically), and this is used as a save area for<br />
the regular MST remap fields that are overwritten by this remap() call. At the end<br />
of the copyin64(), or any other call, restoremap() is called with the address of the<br />
stack-resident remap-like struct. The original contents of the MST remap fields<br />
that were temporarily overwritten are written back to the MST. An additional<br />
internal routine, as_remapaddr(), is used to return the original 64-bit unremapped<br />
address (modulo SEGSIZE) for a given 32-bit remapped address.<br />
static void remap(ptr64 addr, uint nbytes, struct remaps * ptr)<br />
static void restoremap(struct remaps * ptr)<br />
ptr64 as_remapaddr(uint addr32)<br />
These services take only one address and length to remap, and there is no place,<br />
currently, where calls to remap() are nested without restoremap(). Only one data<br />
structure at a time can be remapped in this fashion. The on-stack remaps<br />
structure is able to store the entire mstext->remaps array when there are fifteen<br />
segments total in the range to be remapped through savemap().<br />
44 <strong>AIX</strong> <strong>Version</strong> <strong>4.3</strong> <strong>Differences</strong> <strong>Guide</strong>