Access 64 bit address space in legacy 32 bit applications.

libemm64 (and corresponding emm64_kern package) provide large
address space extensions to legacy 32 bit applications when running
on a 64 bit operating system.

(Bonus points to the people who remember using EMM.SYS on MS/DOS)

Once the emm64_kern package is installed, all 32 bit apps have access
to this extra address space.

To access the extra address space requires special assembler code,
or the use of the libemm64 library.  This only provides indirect
access to the upper address space block.

New functions:
/* generic bcopy/bzero functions */
void bcopy64(uint64_t src, uint64_t dst, uint64_t len);
void bzero64(uint64_t dst, uint64_t len);

/* Note: ANSI C memset returns first arg as void *.  Not this one. */
void memset64(uint64_t dst, int val, uint64_t len);

Inline helper functions:
void memcpy_to64(uintptr_t dst, void *src, size_t len);
void memcpy_from64(void *dst, uint64_t src, size_t len);
void memcpy64(uint64_t dst, uint64_t src, uint64_t len);
void memmove64(uint64_t dst, uint64_t src, uint64_t len);

Management functions for mappings above 4GB.
u_int64_t mmap64(u_int64_t addr, u_int64_t len, int prot, int flags, int fd, off_t offset);
int munmap64(u_int64_t addr, u_int64_t len);
int msync64(u_int64_t addr, u_int64_t len, int flags);

The above functions are prototyped in <libemm64.h>

mmap64/munmap64/msync64 behave just like their regular C counterparts,
except that they take and return 64 bit arguments.  mmap64 will attempt
to map all of its locations above the 4GB memory barrier to avoid
interference with regular 32 bit mmap operations.

Caveats:
* If a process crashes and core dumps, the 64 bit mappings will not be
  correctly handled in the 32 bit core dump.  gdb will likely be quite
  confused, at best.
* 32 bit gdb will NOT single step the 64 bit code.
* 32 bit gcc doesn't deal well with 64 bit values.  Dealing with 64
  bit offsets can be a hassle, especially since you cannot use a "pointer"
  type.
* Obviously, you can't address >4GB directly.  You have to use the
  indirect functions in the library.  The choice of functions is
  fairly limited but can be easily expanded on request.
* The expected usage of this would be to write your own abstraction
  layer to manage copying between your regular 32 bit address space and
  the large mmap file space.  If you share the mmap file among multiple
  users, you will need to do your own locking etc to manage the coherency
  of this, just as you would in normal 32 bit code anyway.  ylock or some
  other mechanism should serve well enough.
* I'm open to requests for new functions.  I have to write them in
  assembler code, so they have to be simple.  I anticipate the need for
  atomic operation functions etc.
* 'Out of memory' type situations won't have exactly the same semantics
  as before.  The kernel module wraps 32 bit functions that allocate
  address space (mmap, shmat, etc) and attempts to reverse any surprises
  if the 32 bit application was about to be given a mapping that extended
  above the 4GB barrier.  This means that the kernel wrapper will attempt
  to unmap a "successful" mapping that went higher than 4GB.  It should
  be close enough.

Benefits:
* bcopy64/bzero64/etc are faster than freebsd's native 32 bit
  bcopy/memcpy/memmove for copies that are not "small".  The threshold
  as to which is faster depends on the cpu model in the machine.
  The cutoff appears to be typically between 256 and 1024 bytes.
* You can gain many of the benefits of the address space of 64 bit processes
  even if your dependent packages have not been ported to 64 bit
  environments yet.  You can link libemm64 into your freebsd 4.x
  application and then mmap a 5TB file into your application if you
  had a use for it.

Bugs/missing things:
* The primitives for accessing the >4GB address space are limited.
  I'll write more primitives once it is clear what is needed.  Atomic
  operations are expected to be needed fairly quickly.
* This is uncharted terroritory.  It is likely that things will go wrong
  somehow, somewhere.

Change Log
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 0.9.1
* Fix cosmetic errors and documentation pointers.

Version 0.9.0
* Initial Version