diff options
author | Niclas Axelsson <[email protected]> | 2011-03-02 15:36:49 +0100 |
---|---|---|
committer | Niclas Axelsson <[email protected]> | 2011-03-02 15:37:06 +0100 |
commit | 1ce3103d3bd8a869225bd461b586f97f90bf930a (patch) | |
tree | 0b0056363d83f3c49f2db0daf8bcfc2b3b31b550 | |
parent | a324127f378d5cf294cb87d1ae582996b72a2c00 (diff) | |
parent | 68aed1c7441ceb2e8dd87f5fa9ac8fefe98e3b47 (diff) | |
download | otp-1ce3103d3bd8a869225bd461b586f97f90bf930a.tar.gz otp-1ce3103d3bd8a869225bd461b586f97f90bf930a.tar.bz2 otp-1ce3103d3bd8a869225bd461b586f97f90bf930a.zip |
Merge branch 'ta/driver-entry-typos' into dev
* ta/driver-entry-typos:
Fix a couple typos in driver_entry(3)
OTP-9085
-rw-r--r-- | erts/doc/src/driver_entry.xml | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/erts/doc/src/driver_entry.xml b/erts/doc/src/driver_entry.xml index 7d1585f483..dfddbb18ea 100644 --- a/erts/doc/src/driver_entry.xml +++ b/erts/doc/src/driver_entry.xml @@ -36,7 +36,7 @@ <description> <p>As of erts version 5.5.3 the driver interface has been extended (see <seealso marker="driver_entry#extended_marker">extended marker</seealso>). - The extended interface introduce + The extended interface introduces <seealso marker="erl_driver#version_management">version management</seealso>, the possibility to pass capability flags (see <seealso marker="driver_entry#driver_flags">driver flags</seealso>) @@ -45,21 +45,21 @@ <note> <p>Old drivers (compiled with an <c>erl_driver.h</c> from an earlier erts version than 5.5.3) have to be recompiled - (but does not have to use the extended interface).</p> + (but do not have to use the extended interface).</p> </note> <p>The <c>driver_entry</c> structure is a C struct that all erlang - drivers defines. It contains entry points for the erlang driver + drivers define. It contains entry points for the erlang driver that are called by the erlang emulator when erlang code accesses the driver.</p> <p> <marker id="emulator"></marker> The <seealso marker="driver_entry">erl_driver</seealso> driver - API functions needs a port handle + API functions need a port handle that identifies the driver instance (and the port in the emulator). This is only passed to the <c>start</c> function, but not to the other functions. The <c>start</c> function returns a driver-defined handle that is passed to the other functions. A - common practice is to have the <c>start</c> function allocating + common practice is to have the <c>start</c> function allocate some application-defined structure and stash the <c>port</c> handle in it, to use it later with the driver API functions.</p> <p>The driver call-back functions are called synchronously from the @@ -239,7 +239,7 @@ typedef struct erl_drv_entry { </item> <tag>void *handle</tag> <item> - <p>This field is reserved for the emulators internal use. The + <p>This field is reserved for the emulator's internal use. The emulator will modify this field; therefore, it is important that the <c>driver_entry</c> isn't declared <c>const</c>.</p> </item> @@ -403,7 +403,7 @@ typedef struct erl_drv_entry { <tag>void *handle2</tag> <item> <p> - This field is reserved for the emulators internal use. The + This field is reserved for the emulator's internal use. The emulator will modify this field; therefore, it is important that the <c>driver_entry</c> isn't declared <c>const</c>. </p> |