--- mm.pod 2002/07/26 09:59:34 1.18
+++ mm.pod 2002/07/26 13:04:40 1.19
@@ -45,11 +45,11 @@
=head1 NAME
-B<MM - Shared Memory Library>
+B<MM - Shared Memory Allocation>
=head1 VERSION
-MM MM_VERSION_STR
+OSSP mm MM_VERSION_STR
=head1 SYNOPSIS
@@ -110,7 +110,7 @@
=head1 DESCRIPTION
-The B<MM> library is a 2-layer abstraction library which simplifies the usage
+The B<OSSP mm> library is a 2-layer abstraction library which simplifies the usage
of shared memory between forked (and this way strongly related) processes
under Unix platforms. On the first (lower) layer it hides all platform
dependent implementation details (allocation and locking) when dealing with
@@ -118,7 +118,7 @@
high-level malloc(3)-style API for a convenient and well known way to work
with data-structures inside those shared memory segments.
-The abbreviation B<MM> is historically and originally comes from the phrase
+The abbreviation B<OSSP mm> is historically and originally comes from the phrase
``I<memory mapped>'' as used by the POSIX.1 mmap(2) function. Because this
facility is internally used by this library on most platforms to establish the
shared memory segments.
@@ -155,7 +155,7 @@
=item B<Low-Level Shared Memory API>
-This is the basis of the whole B<MM> library. It provides low-level functions
+This is the basis of the whole B<OSSP mm> library. It provides low-level functions
for creating shared memory segments with mutual exclusion (in short I<mutex>)
capabilities in a portable way. Internally the shared memory and mutex
facility is implemented in various platform-dependent ways. A list of
@@ -168,10 +168,10 @@
Internally the shared memory facility is implemented in various
platform-dependent ways. Each way has its own advantages and disadvantages
(in addition to the fact that some variants aren't available at all on some
-platforms). The B<MM> library's configuration procedure tries hard to make a
+platforms). The B<OSSP mm> library's configuration procedure tries hard to make a
good decision. The implemented variants are now given for overview and
background reasons with their advantages and disadvantages and in an ascending
-order, i.e. the B<MM> configuration mechanism chooses the last available one
+order, i.e. the B<OSSP mm> configuration mechanism chooses the last available one
in the list as the preferred variant.
=over 4
@@ -211,7 +211,7 @@
As for the shared memory facility, internally the locking facility is
implemented in various platform-dependent ways. They are again listed
-in ascending order, i.e. the B<MM> configuration mechanism chooses the
+in ascending order, i.e. the B<OSSP mm> configuration mechanism chooses the
last available one in the list as the preferred variant. The list of
implemented variants is:
@@ -367,7 +367,7 @@
=item char *B<MM_error>(void);
-Returns the last error message which occurred inside the B<MM> library.
+Returns the last error message which occurred inside the B<OSSP mm> library.
=back
@@ -469,7 +469,7 @@
=item char *B<mm_error>(void);
-Returns the last error message which occurred inside the B<MM> library.
+Returns the last error message which occurred inside the B<OSSP mm> library.
=item void B<mm_display_info>(MM *I<mm>);
@@ -538,8 +538,8 @@
to the next virtual memory I<page> boundary used by the underlaying platform.
The memory page boundary under Unix platforms is usually somewhere between
2048 and 16384 bytes. You do not have to align the I<size> arguments of other
-B<MM> library functions yourself, because this is already done internally.
-This function is exported by the B<MM> library just for convenience reasons in
+B<OSSP mm> library functions yourself, because this is already done internally.
+This function is exported by the B<OSSP mm> library just for convenience reasons in
case an application wants to perform similar calculations for other purposes.
=item size_t B<mm_core_align2word>(size_t I<size>);
@@ -547,9 +547,9 @@
This is another utility function which can be used to align the number I<size>
to the next virtual memory I<word> boundary used by the underlaying platform.
The memory word boundary under Unix platforms is usually somewhere between 4
-and 16 bytes. You do not have to align the I<size> arguments of other B<MM>
+and 16 bytes. You do not have to align the I<size> arguments of other B<OSSP mm>
library functions yourself, because this is already done internally. This
-function is exported by the B<MM> library just for convenience reasons in case
+function is exported by the B<OSSP mm> library just for convenience reasons in case
an application wants to perform simular calculations for other purposes.
=back
@@ -572,9 +572,9 @@
=item int B<mm_lib_version>(void);
This function returns a hex-value ``0xI<V>I<RR>I<T>I<LL>'' which describes the
-current B<MM> library version. I<V> is the version, I<RR> the revisions, I<LL>
+current B<OSSP mm> library version. I<V> is the version, I<RR> the revisions, I<LL>
the level and I<T> the type of the level (alphalevel=0, betalevel=1,
-patchlevel=2, etc). For instance B<MM> version 1.0.4 is encoded as 0x100204.
+patchlevel=2, etc). For instance B<OSSP mm> version 1.0.4 is encoded as 0x100204.
The reason for this unusual mapping is that this way the version number is
steadily I<increasing>.
@@ -604,14 +604,7 @@
=head1 HOME
-=for html
-<a href="http://www.engelschall.com/sw/mm/">http://www.engelschall.com/sw/mm/</a>
-
-=for text
-http://www.engelschall.com/sw/mm/
-
-=for man
-http://www.engelschall.com/sw/mm/
+http://www.ossp.org/pkg/lib/mm/
=head1 HISTORY
@@ -625,6 +618,9 @@
October 1997 by I<Charles Randall> <crandall@matchlogic.com> for MatchLogic,
Inc.
+In 2000 this library joined the B<OSSP> project where all other software
+development projects of I<Ralf S. Engelschall> are located.
+
=head1 AUTHOR
Ralf S. Engelschall
|
