various fixes; little dancing ;(

marco: new sentence, new line please!

1 files changed, 98 insertions, 69 deletions

diff --git a/share/man/man4/ipmi.4 b/share/man/man4/ipmi.4
index 9fe23ecfdeb..c94c9af0087 100644
--- a/share/man/man4/ipmi.4
+++ b/share/man/man4/ipmi.4
@@ -1,12 +1,12 @@
-.\"	$OpenBSD: ipmi.4,v 1.1 2005/10/06 20:58:09 marco Exp $
+.\"	$OpenBSD: ipmi.4,v 1.2 2005/10/07 09:12:38 jmc Exp $
 .\"
 .\" Copyright (c) Marco Peereboom <marco@openbsd.org>
 .\" Text was heavily borrowed from the IPMI spec V1.5
-.\" 
+.\"
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\" 
+.\"
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
@@ -27,91 +27,121 @@ The
 .Nm
 term Intelligent Platform Management refers to autonomous monitoring and
 recovery features implemented directly in platform management hardware and
-firmware.  The key characteristics of Intelligent Platform Management is that
-inventory, monitoring, logging and recovery control functions are available
-indepent of the main processor, BIOS and operating system.
+firmware.
+The key characteristics of Intelligent Platform Management is that
+inventory, monitoring, logging, and recovery control functions are available
+independent of the main processor, BIOS, and operating system.
 .Pp
-Platform status information can be obtiained and recovery actions initiated
+Platform status information can be obtained and recovery actions initiated
 under situations where vendor "in-band" management mechanisms are unavailable.
-The independent monitoring, logging and access functions available through IPMI
-provide a level of manageability built-in to the platform hardware.  This can
-support systems where there is no systems management software available for a
-particular operating system.
-.Pp
-At the heart of the IPMI architecture is a microcontroller called the Baseboard Management Controller or BMC.  The BMC provides the intelligence behind Intelligent Platform Management.  The BMC manages the interface between system management software and the platform management hardware, provides autonomous monitoring, event logging and recovery control and serves as the gateway between systems management software and hardware.
+The independent monitoring, logging, and access functions available through IPMI
+provide a level of manageability built in to the platform hardware.
+This can support systems where there is no systems management software
+available for a particular operating system.
 .Pp
+At the heart of the IPMI architecture is a microcontroller called
+the Baseboard Management Controller (BMC).
+The BMC provides the intelligence behind Intelligent Platform Management.
+The BMC manages the interface between system management software
+and the platform management hardware, provides autonomous monitoring,
+event logging, and recovery control and serves as the gateway
+between systems management software and hardware.
 .Sh IPMI MESSAGING
 IPMI uses message-based interfaces for the different interfaces to the platform
-management subsystems.  All IPMI messages share the same fields in the message
-"payload"; regardless of the interface (transport) that they're transferred
-over.  IPMI messaging uses a request/response protocol.  IPMI request messages are commonly referred to as commands.  The use of request/response protocol facilitates the transfer of IPMI messages over different transports.  IPMI commands are grouped into functional command sets using a field called network function code.  There are command sets for sensor and even related commands, chassis commands etc.  This functional grouping makes it easier to organize and manage the assignment and allocation of command values.
+management subsystems.
+All IPMI messages share the same fields in the message "payload",
+regardless of the interface (transport) that they're transferred over.
+IPMI messaging uses a request/response protocol.
+IPMI request messages are commonly referred to as commands.
+The use of request/response protocol facilitates the transfer of
+IPMI messages over different transports.
+IPMI commands are grouped into functional command sets
+using a field called network function code.
+There are command sets for sensor and even related commands,
+chassis commands etc.
+This functional grouping makes it easier to organize and manage
+the assignment and allocation of command values.
 .Sh SENSOR MODEL
 Access to monitored information such as temperatures, voltages, fan status
-etc., is provided via the IPMI Sensor Model.  Instead of providing direct
-access to the monitoring hardware IPMI provides access by abstracted sensor
-commands such as the "Get Seonsor Reading" command, implemented via a
-management controller.  This approach isolates the software from changes in the
+etc., is provided via the IPMI Sensor Model.
+Instead of providing direct access to the monitoring hardware,
+IPMI provides access by abstracted sensor commands
+such as the "Get Seonsor Reading" command,
+implemented via a management controller.
+This approach isolates the software from changes in the
 platform management hardware implementation.
 .Pp
-Sensors are classified according to the type of readings they provide and/or the type of events they generate.  A sensor can return either an analog or discrete reading.  Sensor events can be discrete or threshold-based.
+Sensors are classified according to the type of readings they provide
+and/or the type of events they generate.
+A sensor can return either an analog or discrete reading.
+Sensor events can be discrete or threshold-based.
 .Sh SYSTEM EVENT LOG AND EVENT MESSAGES
-The BMC provides a centralized non-volatile System Event Log, or SEL.  Having
-the SEL and logging functions managed by the BMC helps ensure that post-mortem
-logging information is available should a failure occur that disables the
-systems processor(s).
+The BMC provides a centralized non-volatile System Event Log, or SEL.
+Having the SEL and logging functions managed by the BMC
+helps ensure that post-mortem logging information is available
+should a failure occur that disables the systems processor(s).
 .Pp
-A set of IPMI commands alows the SEL to be read and cleared and for events to be added to the SEL.  The common request message (command) used for adding events to the SEL is referred to as Event Message.
+A set of IPMI commands alows the SEL to be read and cleared
+and for events to be added to the SEL.
+The common request message (command)
+used for adding events to the SEL is referred to as an Event Message.
 .Sh SENSOR DATA RECORDS & CAPABILITIES COMMANDS
-IPMI's extensibility and scalability mean that each platform implementation can
-have a differerent population of management controllers and sensors and
-different event generation capabilities.  The design of IPMI allows system
-management software to retrieve information from the platform and automatically
-configure itself to the platform's capabilities.
+IPMI's extensibility and scalability mean that
+each platform implementation can have
+a differerent population of management controllers and sensors and
+different event generation capabilities.
+The design of IPMI allows system
+management software to retrieve information from the platform
+and automatically configure itself to the platform's capabilities.
 .Pp
-Information that describes the platform management capabilities is provided via
-two mechanisms: Capabilities Commands and Sensor Data Records (SDRs).
+Information that describes the platform management capabilities
+is provided via two mechanisms:
+Capabilities Commands and Sensor Data Records (SDRs).
 Capabilities commands are commands within the IPMI command sets that return
 fields that provide information on other commands and functions the controller
 can handle.
 .Sh SYSTEMS INTERFACES
-IPMI defines three standardized systems intefaces that systems software uses
-for transfering IPMI messages to the BMC.  In order to support a variety of
-microcontrollers, IPMI offers a choice of systems interfaces.  The system
-interfaces are similar enough so that a single driver can handle all IPMI
-system interfaces.
-.Pp
-.Bl -tag -width <10> -compact
+IPMI defines three standardized systems interfaces that systems software uses
+for transferring IPMI messages to the BMC.
+In order to support a variety of microcontrollers,
+IPMI offers a choice of systems interfaces.
+The system interfaces are similar enough so that
+a single driver can handle all IPMI system interfaces.
+.Bl -tag -width Ds
 .It Keyboard Controller Style (KCS)
-The bit definitions, and operation of the registers follows that used in the
-Intel 8742 Universal Peripheral Interface microcontroller.  The term "Keyboard
-Controller Style" reflects the fact that the 8742 interface was used as the
-legacy keyboard controller interface in PC architecture computer systems.  This
-interface is available built-in to several commercially available
-microcontrollers.  Data is transferred accross the KCS interface using a per
-byte-byte handshake.
-.Pp
+The bit definitions and operation of the registers follows that used in the
+Intel 8742 Universal Peripheral Interface microcontroller.
+The term "Keyboard Controller Style" reflects the fact that
+the 8742 interface was used as the legacy keyboard controller interface
+in PC architecture computer systems.
+This interface is available built in to several commercially available
+microcontrollers.
+Data is transferred across the KCS interface using a per byte-byte handshake.
 .It System Management Interface Chip (SMIC)
-The SMIC interface provides an alternative when the implementer wishes to use a
-microcontroller for the BMC that does not have the built-in hardware for a KCS
-interface.  This interface is a three I/O port interface that can be
-implemented using a simple ASIC, FPGA or discrete logic devices.  It may also
-be built-in to a custom-designed management controller.  Like the KCS interface
-a per-byte handshake is also used for transferring data accross the SMIC
-interface.
-.Pp
+The SMIC interface provides an alternative
+when the implementer wishes to use a microcontroller for the BMC
+that does not have the built-in hardware for a KCS interface.
+This interface is a three I/O port interface that can be
+implemented using a simple ASIC, FPGA, or discrete logic devices.
+It may also be built in to a custom-designed management controller.
+Like the KCS interfacei,
+a per-byte handshake is also used
+for transferring data across the SMIC interface.
 .It Block Transfer (BT)
-This interface provides a higher performance system interface option.  Unlike
-the KCS and SMIC interfaces a per-block handshake is used for transferring data
-accross the interface.  The BT interface also provides an alternative to using
-a controller with a built-in KCS interface.  The BT interface has three I/O
-mapped ports.  A typical implementation includes hardware buffers for holding
-upstream and downstream message blocks.  The BT interface can be implemented
-using an ASIC or FPGA or may be built-in to a custom-designed management
-controller.
+This interface provides a higher performance system interface option.
+Unlike the KCS and SMIC interfaces,
+a per-block handshake is used for transferring data across the interface.
+The BT interface also provides an alternative to using
+a controller with a built-in KCS interface.
+The BT interface has three I/O mapped ports.
+A typical implementation includes hardware buffers for holding
+upstream and downstream message blocks.
+The BT interface can be implemented using an ASIC or FPGA
+or may be built in to a custom-designed management controller.
 .El
 .Sh SEE ALSO
-.Xr sysctl 8 ,
-.Xr sensorsd 8
+.Xr sensorsd 8 ,
+.Xr sysctl 8
 .Sh HISTORY
 The
 .Nm
@@ -120,7 +150,6 @@ driver first appeared in
 and conforms to the IPMI 1.5 specification.
 .Sh AUTHORS
 The
-.Om
 .Nm
-driver was written by Jordan Hargrave <jordan@openbsd.org>
-
+driver was written by
+.An Jordan Hargrave Aq jordan@openbsd.org .