Wow, thanks for all this. There were a couple of things that I chose to
reword instead of taking your change, and "contiguous" is really the
word I wanted to use :). But this was a lot of very useful work. Thanks.
-Corey
coly wrote:
> hi, these days I read IPMI.pdf, and found some typos. the
> attachment is
> my patch for these typos based on IPMI.ltx from CVS.
> hope helping.
>
> Coly
>
>------------------------------------------------------------------------
>
>Index: IPMI.ltx
>===================================================================
>RCS file: /cvsroot/openipmi/OpenIPMI/doc/IPMI.ltx,v
>retrieving revision 1.36
>diff -u -r1.36 IPMI.ltx
>--- IPMI.ltx 5 Nov 2005 04:10:40 -0000 1.36
>+++ IPMI.ltx 26 Dec 2005 10:16:11 -0000
>@@ -232,7 +232,7 @@
> Replacable Unit. This includes things like the manufacturer, the
> serial number, date of manufacture, etc. A system generally has
> information about the chassis and information about each field
>-replacable unit it has. Field replacable units may include power
>+replaceable unit it has. Field replaceable units may include power
> supplies, DIMMs (memory devices), plug-in-boards, or a host of other
> things.
>
>@@ -423,9 +423,9 @@
> sensors, how the sensors advertise those capabilties, and the things
> that can be done to the sensors.
>
>-You may register with an entity to be told when it's physical presence
>+You may register with an entity to be told when its physical presence
> in the system changes. Some devices (like power supplies) are
>-field-replacable while the system is running; this type of device is
>+field-replaceable while the system is running; this type of device is
> called a hot-swappable \ac{FRU}. They may have sensors that monitor
> them, but those sensors may not be active if the device is not
> physically present in the system.
>@@ -494,7 +494,7 @@
> call when the operation completes. The functions passed around are
> called ``callbacks''. You allocate and pass around chunks
> of data to be passed to the handlers. And you register input handlers
>-that get called when certain event occur. So the code runs in short
>+that get called when certain event occurs. So the code runs in short
> non-blocking sections, registers for the next operation, then returns
> back to some invisible main loop that handles the details of scheduling
> operations. This may seem more complicated than the previous example,
>@@ -922,7 +922,7 @@
> doing multi-threaded programming.
> \end{itemize}
>
>-This it is pretty standard in multi-threaded systems. \ac{HPI}, for
>+This is pretty standard in multi-threaded systems. \ac{HPI}, for
> instance has the same problem. If you have one thread waiting for
> events from an \ac{HPI} domain, and another iterating the RDRs, or you
> have two threads each doing operations on sensors, you have exactly
>@@ -979,7 +979,7 @@
>
> \paragraph{Device-Relative vs System-Relative Entities}
>
>-In \acs{IPMI}, entities may be be either in a fixed place in the system, or
>+In \acs{IPMI}, entities may be either in a fixed place in the system, or
> they may be moved about the system. Fixed entities, are, well, in a
> fixed location in the system. These are called system relative
> entities. They have an entity instance less than 60h.
>@@ -1195,7 +1195,7 @@
> give it a handler to call when the reading has been fetched.
>
> This is always done for things that OpenIPMI might have to send a
>-message to do. If it a result of OpenIPMI's requirement to be able to
>+message to do. If it is a result of OpenIPMI's requirement to be able to
> work in non-threaded systems and still be responsive to operations
> while waiting.
>
>@@ -1489,7 +1489,7 @@
> \chapter{IPMI Interfaces}
> \label{ipmi-interfaces}
>
>-\acs{IPMI} has a large number of interfaces for talking to to management
>+\acs{IPMI} has a large number of interfaces for talking to management
> controllers. They vary in performance and capability, but the same
> messages work over the top of all of them. Generally, it does not
> matter how you interface to an \acs{IPMI} system, the messages will work the
>@@ -1503,7 +1503,7 @@
> but once set up, the interfaces all work the same. The file shown in
> Appendix \ref{ipmi-conn-h} defines the interface for connections.
>
>-Note that not all operations are not available on all interfaces. \acs{LAN}
>+Note that not all operations are available on all interfaces. \acs{LAN}
> connections, for instance, cannot receive commands.
>
> \section{System Interfaces}
>@@ -1667,7 +1667,7 @@
> req.msg.cmd = 0x2d; /* Get sensor reading */
> req.msg.data = data;
> req.msg.data_len = 1;
>-data[1] = 10; /* Read sensor 10 */
>+data[0] = 10; /* Read sensor 10 */
>
> rv = ioctl(fd, IPMICTL_SEND_COMMAND, &req);
> \end{verbatim}
>@@ -1857,7 +1857,7 @@
> printf("parms were: %d %d", tparms.retries, tparms.retry_time_ms);
>
> tparms.retries = 0; /* No resends */
>-tparms.retry_time = 1000; /* one second */
>+tparms.retry_time_ms = 1000; /* one second */
> rv = ioctl(fd, IPMICTL_SET_TIMING_PARMS_CMD, &tparms);
> if (rv == -1)
> error handling...
>@@ -1946,7 +1946,7 @@
> interface, and any other messaging interfaces will each have their own
> channel on the \ac{MC}.
>
>-Messages directly sent to the local management controller do nor
>+Messages directly sent to the local management controller do not
> require any type of channel information. When the user sends a
> message out to another interface, it must specify the channel. This
> is called ``bridging''. Channels also may have some type of
>@@ -2081,7 +2081,7 @@
> \end{tightdefs}
> \end{tightdefs}}
> \msgitem{5-7}{Vendor ID, used to specify the IANA number for the organization
>- the defined the protocol. This should always be the IPMI IANA,
>+ defined the protocol. This should always be the IPMI IANA,
> which is 7154 (decimal), or F2H, 1Bh, and 00H for these bytes.}
> \msgitem{8-9}{Auxiliary channel info.
>
>@@ -2184,7 +2184,7 @@
> \msgitem{1}{Channel information, bits are:
> \begin{tightdefs}
> \item[0-4] - Channel number
>- \item[4-7] - Inferred privilege leel for the message. Table
>+ \item[4-7] - Inferred privilege level for the message. Table
> \ref{ipmi-priv-levels} describes the privilege levels.
>
> If the message is received from a session-oriented channel,
>@@ -3539,7 +3539,7 @@
> interfaces, and whatnot. Channel Fh is used for the system interface.
>
> If you specify channel Eh in a command, it will use the channel the
>-command comes in on and any returned channel number will be the actual
>+command comes in and any returned channel number will be the actual
> channel number of the channel. This can be used to discover the
> channel number of the current channel.
>
>@@ -3936,7 +3936,7 @@
> an \ac{NMI}.\\
> \hline
> Send Alert & 5 & Send an alert of some type, via an \acs{SNMP} trap,
>- a page, or a modem dialin. Note that unlike the rest of the
>+ a page, or a modem dialing. Note that unlike the rest of the
> actions, this action will still be done if a higher priority
> action is done. Alerts can also be prioritized via the
> Alert Policy Table as described in section \ref{sec-pef-conf-parms}.\\
>@@ -4314,7 +4314,7 @@
> byte 3 of an alert policy table entry is set to 0, or indirectly
> through parameter 12 of this table if that bit is one.
>
>- The meanings of the values in this table are dependend on the
>+ The meanings of the values in this table are dependent on the
> alert type and channel.
>
> For dial paging, this string will have a carraige return
>@@ -4351,10 +4351,10 @@
>
> The \ac{PEF} table is read and written as part of the PEF
> Configuration table, parameter 6, but the contents are documented
>-separately in table \ref{pef-table-entry}. When and event comes in,
>+separately in table \ref{pef-table-entry}. When an event comes in,
> it is compared against each filter in order. If a match occurs on
> multiple filters, then the highest priority action is done and the
>-rest except for alerts are ignored. After the operation is complete,
>+rest except for alerts are ignored. After the operation is completed,
> any alert operations are done by scanning the alert policy table in
> order. The order of the alert policy table defines the priority of
> the different alerts.
>@@ -4991,7 +4991,7 @@
> responses. A user sends a command to an \ac{MC}, and the \ac{MC}
> returns a response. All commands have responses. Commands may
> optionally have some data; the data depends on the command. The same
>-goes for responses, except that all responses contain at least on data
>+goes for responses, except that all responses contain at least one data
> byte holding the completion code. Every response has a completion
> code in the first byte.
>
>@@ -5635,7 +5635,7 @@
> \hline
> 31 & CABLE \_INTERCONNECT & A cable routing device.\\
> \hline
>-32 & MEMORY\_DEVICE & A replacable memory device, like a DIMM. This should
>+32 & MEMORY\_DEVICE & A replaceable memory device, like a DIMM. This should
> not be used for individual memory chips, but for the board that
> holds the memory chips.\\
> \hline
>@@ -5680,7 +5680,7 @@
>
> \section{Discovering Entities}
> In OpenIPMI, the entities in a system are part of the domain. As
>-OpenIPMI scans \acs{SDR}s it find, it will create the entities
>+OpenIPMI scans \acs{SDR}s it finds, it will create the entities
> referenced in those SDRs. The user can discover the entities in a
> domain in two ways: iterating or registering callbacks.
>
>@@ -5831,7 +5831,7 @@
> Entities come in four different flavors:
> \begin{description}
> \item[\acs{MC}] - An \acs{MC} entity is for a \acs{MC}.
>-\item[FRU] - This is for field-replacable entities that are
>+\item[FRU] - This is for field-replaceable entities that are
> not \acs{MC}s.
> \item[Generic] - Some other device on the \acs{IPMB} bus.
> \item[Unknown] - This is for entities that do not have an \acs{SDR}
>@@ -6048,7 +6048,7 @@
> int allocated = 0;
>
> if (length == 0)
>- name = ``empty name'';
>+ name = "empty name";
> else {
> name = malloc(length+1);
> if (!name) {
>@@ -6121,7 +6121,7 @@
> int allocated = 0;
>
> if (length == 0)
>- name = ``empty name'';
>+ name = "empty name";
> else {
> name = malloc(length+1);
> if (!name) {
>@@ -6401,7 +6401,7 @@
> const char **name,
> ipmi_fru_node_t **node);
> \end{verbatim}
>-This function returns the name of the FRU (either ``SPD FRU'' or
>+This function returns the name of the FRU, either ``SPD FRU'' or
> ``standard FRU'' or some other OEM name and the actual root node. If
> either of these is NULL, it will be ignored. The root node is always
> a record node.
>@@ -6419,7 +6419,7 @@
> unsigned int *data_len,
> ipmi_fru_node_t **sub_node);
> \end{verbatim}
>-The index is a contiguous range from zero that holds every field. So
>+The index is a continuous range from zero that holds every field. So
> you can iterate through the indexes from 0 until it returns EINVAL to
> find all the fields. If a field is not present in the \acs{FRU} data,
> this will return \verb=ENOSYS=. Note that later fields may still be
>@@ -6603,7 +6603,7 @@
> unsigned int area,
> unsigned int *used_length);
> \end{verbatim}
>-The \verb=used_length= variable tells how much of teh length of the
>+The \verb=used_length= variable tells how much of the length of the
> FRU is actually used. Note that area offsets and length must be
> multiples of 8.
>
>@@ -6833,7 +6833,7 @@
> can only do so much.
>
> So starting at the beginning, the first thing you need to know about a
>-sensor is it's type. You fetch that with the function:
>+sensor is its type. You fetch that with the function:
> \begin{verbatim}
> int ipmi_sensor_get_event_reading_type(ipmi_sensor_t *sensor);
> \end{verbatim}
>@@ -7333,7 +7333,7 @@
>
> \subsubsection{Sensor Name}
> The SDR contains a string giving a name for the sensor. This is
>-useful for printing out sensorinformation. The functions to get
>+useful for printing out sensor information. The functions to get
> this are:
> \begin{verbatim}
> int ipmi_sensor_get_id_length(ipmi_sensor_t *sensor);
>@@ -8701,7 +8701,7 @@
> \section{\acs{IPMI} strings}
> \label{appendix-ipmi-strings}
>
>-IPMI uses a special format for storing strings. It allows data two be
>+IPMI uses a special format for storing strings. It allows data to be
> stored in four different formats. The first byte describes the type
> and length; the format is:
> \begin{tightdefs}
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
