aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc/src')
-rw-r--r--erts/doc/src/alt_disco.xml2
-rw-r--r--erts/doc/src/communication.xml2
-rw-r--r--erts/doc/src/crash_dump.xml2
-rw-r--r--erts/doc/src/erl_driver.xml24
-rw-r--r--erts/doc/src/erl_ext_dist.xml6
-rw-r--r--erts/doc/src/erl_nif.xml4
-rw-r--r--erts/doc/src/erlang.xml6
-rw-r--r--erts/doc/src/notes.xml10
8 files changed, 28 insertions, 28 deletions
diff --git a/erts/doc/src/alt_disco.xml b/erts/doc/src/alt_disco.xml
index d04221b9b3..148d6f549e 100644
--- a/erts/doc/src/alt_disco.xml
+++ b/erts/doc/src/alt_disco.xml
@@ -63,7 +63,7 @@
<seealso marker="kernel:erl_epmd">EPMD module</seealso>. However, instead of
communicating with EPMD you can connect to any service to find out
connection details of other nodes. A discovery module is enabled
- by setting <seealso marker="erts:erl#epmd_module">-epmd_module</seealso>
+ by setting <seealso marker="erts:erl">-epmd_module</seealso>
when starting erlang. The discovery module must implement the following
callbacks:</p>
diff --git a/erts/doc/src/communication.xml b/erts/doc/src/communication.xml
index 7e18a73aa8..251b52dc65 100644
--- a/erts/doc/src/communication.xml
+++ b/erts/doc/src/communication.xml
@@ -64,7 +64,7 @@
a synchronous communication operation consists of two asynchronous
signals; one request signal and one reply signal. An example of
such a synchronous communication is a call to
- <seealso marker="erlang:process_info/2">
+ <seealso marker="erlang#process_info/2">
<c>erlang:process_info/2</c></seealso>
when the first argument is not <c>self()</c>. The caller sends
an asynchronous signal requesting information, and then
diff --git a/erts/doc/src/crash_dump.xml b/erts/doc/src/crash_dump.xml
index a9aeb1888c..33d0903622 100644
--- a/erts/doc/src/crash_dump.xml
+++ b/erts/doc/src/crash_dump.xml
@@ -290,7 +290,7 @@ Slogan: &lt;reason&gt;</pre>
<title>Memory Information</title>
<p>Under the tag <em>=memory</em> is shown information similar
to what can be obtainted on a living node with
- <seealso marker="erts:erlang#erlang:memory/0">
+ <seealso marker="erts:erlang#memory/0">
<c>erlang:memory()</c></seealso>.</p>
</section>
diff --git a/erts/doc/src/erl_driver.xml b/erts/doc/src/erl_driver.xml
index 58678f2393..3e2d3bb447 100644
--- a/erts/doc/src/erl_driver.xml
+++ b/erts/doc/src/erl_driver.xml
@@ -230,7 +230,7 @@
<item>
<p>With these functions, the driver sends data back to the emulator.
The data is received as messages by the port owner process, see
- <seealso marker="erlang:open_port/2">
+ <seealso marker="erlang#open_port/2">
<c>erlang:open_port/2</c></seealso>. The vector function and the
function taking a driver binary are faster, as they avoid
copying the data buffer. There is also a fast way of sending
@@ -1154,27 +1154,27 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<taglist>
<tag><seealso marker="driver_entry#start">
<c>start</c></seealso></tag>
- <item>Called from <seealso marker="erlang:open_port/2">
+ <item>Called from <seealso marker="erlang#open_port/2">
<c>erlang:open_port/2</c></seealso>.</item>
<tag><seealso marker="driver_entry#output">
<c>output</c></seealso></tag>
- <item>Called from <seealso marker="erlang:send/2">
+ <item>Called from <seealso marker="erlang#send/2">
<c>erlang:send/2</c></seealso> and
- <seealso marker="erlang:port_command/2">
+ <seealso marker="erlang#port_command/2">
<c>erlang:port_command/2</c></seealso>.</item>
<tag><seealso marker="driver_entry#outputv">
<c>outputv</c></seealso></tag>
- <item>Called from <seealso marker="erlang:send/2">
+ <item>Called from <seealso marker="erlang#send/2">
<c>erlang:send/2</c></seealso> and
- <seealso marker="erlang:port_command/2">
+ <seealso marker="erlang#port_command/2">
<c>erlang:port_command/2</c></seealso>.</item>
<tag><seealso marker="driver_entry#control">
<c>control</c></seealso></tag>
- <item>Called from <seealso marker="erlang:port_control/3">
+ <item>Called from <seealso marker="erlang#port_control/3">
<c>erlang:port_control/3</c></seealso>.</item>
<tag><seealso marker="driver_entry#call">
<c>call</c></seealso></tag>
- <item>Called from <seealso marker="erlang:port_call/3">
+ <item>Called from <seealso marker="erlang#port_call/3">
<c>erlang:port_call/3</c></seealso>.</item>
</taglist>
<p>Notice that this function is <em>not</em> thread-safe, not
@@ -2305,7 +2305,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<c>*value_size</c> has been set to the buffer size needed.</p>
<warning>
<p>This function reads the emulated environment used by
- <seealso marker="os:getenv/1"><c>os:getenv/1</c></seealso> and not
+ <seealso marker="kernel:os#getenv/1"><c>os:getenv/1</c></seealso> and not
the environment used by libc's <c>getenv(3)</c> or similar. Drivers
that <em>require</em> that these are in sync will need to do so
themselves, but keep in mind that they are segregated for a reason;
@@ -2656,7 +2656,7 @@ erl_drv_output_term(driver_mk_port(drvport), spec, sizeof(spec) / sizeof(spec[0]
</note>
<warning>
<p>This function modifies the emulated environment used by
- <seealso marker="os:putenv/2"><c>os:putenv/2</c></seealso> and not
+ <seealso marker="kernel:os#putenv/2"><c>os:putenv/2</c></seealso> and not
the environment used by libc's <c>putenv(3)</c> or similar. Drivers
that <em>require</em> that these are in sync will need to do so
themselves, but keep in mind that they are segregated for a reason;
@@ -2849,7 +2849,7 @@ erl_drv_output_term(driver_mk_port(drvport), spec, sizeof(spec) / sizeof(spec[0]
<desc>
<marker id="erl_drv_set_os_pid"></marker>
<p>Sets the <c>os_pid</c> seen when doing
- <seealso marker="erlang:port_info/2">
+ <seealso marker="erlang#port_info/2">
<c>erlang:port_info/2</c></seealso> on this port.</p>
<p><c>port</c> is the port handle of the port (driver instance) to set
the pid on. <c>pid</c>is the pid to set.</p>
@@ -3204,7 +3204,7 @@ erl_drv_output_term(driver_mk_port(drvport), spec, sizeof(spec) / sizeof(spec[0]
<c>control</c></seealso> driver entry
function will return data to the port owner process.
(The <c>control</c> function is called from
- <seealso marker="erlang:port_control/3">
+ <seealso marker="erlang#port_control/3">
<c>erlang:port_control/3</c></seealso>.)</p>
<p>Currently there are only two meaningful values for
<c>flags</c>: <c>0</c> means that data is returned in a list,
diff --git a/erts/doc/src/erl_ext_dist.xml b/erts/doc/src/erl_ext_dist.xml
index 4721747097..6b7a6db943 100644
--- a/erts/doc/src/erl_ext_dist.xml
+++ b/erts/doc/src/erl_ext_dist.xml
@@ -399,7 +399,7 @@
<tcaption>REFERENCE_EXT</tcaption></table>
<p>
Encodes a reference object (an object generated with
- <seealso marker="erlang:make_ref/0">erlang:make_ref/0</seealso>).
+ <seealso marker="erlang#make_ref/0">erlang:make_ref/0</seealso>).
The <c>Node</c> term is an encoded atom, that is,
<seealso marker="#ATOM_UTF8_EXT"><c>ATOM_UTF8_EXT</c></seealso>,
<seealso marker="#SMALL_ATOM_UTF8_EXT"><c>SMALL_ATOM_UTF8_EXT</c></seealso>, or
@@ -437,7 +437,7 @@
<tcaption>PORT_EXT</tcaption></table>
<p>
Encodes a port object (obtained from
- <seealso marker="erlang:open_port/2">
+ <seealso marker="erlang#open_port/2">
<c>erlang:open_port/2</c></seealso>).
The <c>ID</c> is a node-specific identifier for a local port.
Port operations are not allowed across node boundaries.
@@ -467,7 +467,7 @@
<tcaption>PID_EXT</tcaption></table>
<p>
Encodes a process identifier object (obtained from
- <seealso marker="erlang:spawn/3"><c>erlang:spawn/3</c></seealso> or
+ <seealso marker="erlang#spawn/3"><c>erlang:spawn/3</c></seealso> or
friends). The <c>ID</c> and <c>Creation</c> fields works just like in
<seealso marker="#REFERENCE_EXT"><c>REFERENCE_EXT</c></seealso>, while
the <c>Serial</c> field is used to improve safety.
diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml
index cf1994887a..c0be715678 100644
--- a/erts/doc/src/erl_nif.xml
+++ b/erts/doc/src/erl_nif.xml
@@ -546,8 +546,8 @@ int writeiovec(ErlNifEnv *env, ERL_NIF_TERM term, ERL_NIF_TERM *tail,
<p>Many operations communicating with a process executing a
dirty NIF can, however, complete while it executes the
dirty NIF. For example, retrieving information about it through
- <seealso marker="erlang:process_info/1">
- <c>erlang:process_info</c></seealso>, setting its group leader,
+ <seealso marker="erlang#process_info/1">
+ <c>process_info</c></seealso>, setting its group leader,
register/unregister its name, and so on.</p>
<p>Termination of a process executing a dirty NIF can only be
completed up to a certain point while it executes the dirty NIF.
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 0d94f83493..2b444ccf01 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -126,7 +126,7 @@
instance.</p>
<p>One can get an approximation of the <c>native</c>
time unit by calling
- <seealso marker="erlang:convert_time_unit/3">
+ <seealso marker="#convert_time_unit/3">
<c>erlang:convert_time_unit(1, second, native)</c></seealso>.
The result equals the number
of whole <c>native</c> time units per second. If
@@ -4663,6 +4663,7 @@ RealSystem = system + MissedSystem</code>
<name name="port_info" arity="2" clause_i="6" since="OTP R16B"/>
<fsummary>Information about the memory size of a port.</fsummary>
<desc>
+ <marker id="port_info_memory"/>
<p><c><anno>Bytes</anno></c> is the total number of
bytes allocated for this port by the runtime system. The
port itself can have allocated memory that is not
@@ -5387,6 +5388,7 @@ RealSystem = system + MissedSystem</code>
</item>
<tag><c>{memory, <anno>Size</anno>}</c></tag>
<item>
+ <marker id="process_info_memory"/>
<p><c><anno>Size</anno></c> is the size in bytes of the process.
This includes call stack, heap, and internal structures.</p>
</item>
@@ -6676,7 +6678,7 @@ lists:map(
<tag><c>async</c></tag>
<item>Async threads are used by various linked-in drivers (mainly the
file drivers) do offload non-CPU intensive work. See
- <seealso marker="erts:erl#+async_thread_pool_size">erl +A</seealso> for more details.</item>
+ <seealso marker="erts:erl#async_thread_pool_size">erl +A</seealso> for more details.</item>
<tag><c>aux</c></tag>
<item>Takes care of any work that is not
specifically assigned to a scheduler.</item>
diff --git a/erts/doc/src/notes.xml b/erts/doc/src/notes.xml
index 7c5a8aefad..13cd4129ac 100644
--- a/erts/doc/src/notes.xml
+++ b/erts/doc/src/notes.xml
@@ -8363,8 +8363,7 @@
Erlang/OTP has been ported to the realtime operating
system OSE. The port supports both smp and non-smp
emulator. For details around the port and how to started
- see the User's Guide in the <seealso
- marker="ose:ose_intro">ose</seealso> application. </p>
+ see the User's Guide in the <em>ose</em> application.</p>
<p>
Note that not all parts of Erlang/OTP has been ported. </p>
<p>
@@ -9470,9 +9469,9 @@
<c>fix_alloc</c> allocator, a different strategy for
management of fix blocks will be used.</item> <item>The
information returned from <seealso
- marker="erlang:system_info_allocator_tuple"><c>erlang:system_info({allocator,
+ marker="erlang#system_info_allocator_tuple"><c>erlang:system_info({allocator,
A})</c></seealso>, and <seealso
- marker="erlang:system_info_allocator_sizes"><c>erlang:system_info({allocator_sizes,
+ marker="erlang#system_info_allocator_sizes"><c>erlang:system_info({allocator_sizes,
A})</c></seealso> will be slightly different when this
feature has been enabled. An <c>mbcs_pool</c> tuple will
be present giving information about abandoned carriers,
@@ -10281,8 +10280,7 @@
information about signal ordering guarantees, see the
chapter on <seealso
marker="erts:communication">communication</seealso> in
- the ERTS user's guide. The <seealso
- marker="erts:erl#+n">+n</seealso> command line flag of
+ the ERTS user's guide. The <c>+n</c> command line flag of
<seealso marker="erts:erl">erl(1)</seealso> can be
helpful when trying to find signaling order bugs in
Erlang code that have been exposed by these