Re: -Tps rendering of verbatim .TS/.TE

[Jan Stary <hans@stare.cz>]

On Aug 25 18:26:02, hans@stare.cz wrote:
> This is the mandoc of current/amd64 OpenBSD
> rendering the attached manpage (of the dmidecode package).
> 
> The manpage is in man(7) and use low-level roff.
> It contains a list of DMI types, marked up as follows:
> 
> .SH "DMI TYPES"
> The \s-1SMBIOS\s0 specification defines the following \s-1DMI\s0 types:
> .TS
> r l
> __
> r l.
> Type	Information
> 0	BIOS
> 1	System
> 2	Baseboard
> [...]
> 41	Onboard Devices Extended Information
> 42	Management Controller Host Interface
> .TE
> 
> The table renders fine in -Tascii
> 
>        Type   Information
>        --------------------------------------------
>           0   BIOS
>           1   System
>           2   Baseboard
> 	 [...]
>          41   Onboard Devices Extended Information
>          42   Management Controller Host Interface
> 
> but it becomes rather ugly with -Tps (attached).
> There is no space between the columns, so
> 
> 	0BIOS
> 	1System
> 
> etc, and the lines seem to be arbitrarily broken, as in
> 
> 	12System Configuration
> 	 Options
> 	13BIOS
> 	 Language

Hm, there is another .TS table in the manpages:

.TS
l l
__
l l.
Keyword	Types
bios	0, 13
system	1, 12, 15, 23, 32
baseboard	2, 10, 41
chassis	3
processor	4
memory	5, 6, 16, 17
cache	7
connector	8
slot	9
.TE

Looking at the "r l" and "l l" preambule, respectively,
perhaps the -Tps rendering just does what it's told?
(Sorry, I don't speak roff: "r"ight and "l"eft justified?
In that case, the -Tps rendering would make sense.)

	Jan

> In fact, some lines get broken where longer ones still continue.
> It seems that it always breaks before the last word.
> 
> I realize the markup is ugly and -Tps is a bit exotic
> (I only noticed because I printed a PS hardcopy,
> before shuting the machine to single user
> to do the actual dmidecode stuff).
> 
> 	Jan
> 
> 

> .TH DMIDECODE 8 "January 2019" "dmidecode"
> .\"
> .SH NAME
> dmidecode \- \s-1DMI\s0 table decoder
> .\"
> .SH SYNOPSIS
> .B dmidecode
> .RI [ OPTIONS ]
> .\"
> .SH DESCRIPTION
> .B dmidecode
> is a tool for dumping a computer's \s-1DMI\s0 (some say \s-1SMBIOS\s0) table
> contents in a human-readable format. This table contains a description of the
> system's hardware components, as well as other useful pieces of information
> such as serial numbers and \s-1BIOS\s0 revision. Thanks to this table, you can
> retrieve this information without having to probe for the actual hardware.
> While this is a good point in terms of report speed and safeness, this also
> makes the presented information possibly unreliable.
> 
> The \s-1DMI\s0 table doesn't only describe what the system is currently made
> of, it also can report the possible evolutions (such as the fastest supported
> \s-1CPU\s0 or the maximal amount of memory supported).
> 
> \s-1SMBIOS\s0 stands for System Management \s-1BIOS\s0, while \s-1DMI\s0
> stands for Desktop Management Interface. Both standards are tightly related
> and developed by the \s-1DMTF\s0 (Desktop Management Task Force).
> 
> As you run it,
> .B dmidecode
> will try to locate the \s-1DMI\s0 table. It will first try to read the DMI table
> from sysfs, and next try reading directly from memory if sysfs access failed.
> If
> .B dmidecode
> succeeds in locating a valid DMI table, it will then parse this table
> and display a list of records like this one:
> 
> Handle 0x0002, DMI type 2, 8 bytes.
> Base Board Information
>         Manufacturer: Intel
>         Product Name: C440GX+
>         Version: 727281-001
>         Serial Number: INCY92700942
> 
> Each record has:
> .IP \(bu "\w'\(bu'u+1n"
> A handle. This is a unique identifier, which allows records to
> reference each other. For example, processor records usually reference
> cache memory records using their handles.
> .IP \(bu
> A type. The \s-1SMBIOS\s0 specification defines different types of elements
> a computer can be made of. In this example, the type is 2, which
> means that the record contains "Base Board Information".
> .IP \(bu
> A size. Each record has a 4-byte header (2 for the handle, 1 for the type,
> 1 for the size), the rest is used by the record data. This value doesn't
> take text strings into account (these are placed at the end of the record),
> so the actual length of the record may be (and is often) greater than the
> displayed value.
> .IP \(bu
> Decoded values. The information presented of course depends on the type
> of record. Here, we learn about the board's manufacturer, model, version
> and serial number.
> .\"
> .SH OPTIONS
> .TP
> .BR "-d" ", " "--dev-mem \fIFILE\fP"
> Read memory from device \fIFILE\fP (default: \fI/dev/mem\fP)
> .TP
> .BR "-q" ", " "--quiet"
> Be less verbose. Unknown, inactive and \s-1OEM\s0-specific entries are not
> displayed. Meta-data and handle references are hidden.
> .TP
> .BR "-s" ", " "--string \fIKEYWORD\fP"
> Only display the value of the \s-1DMI\s0 string identified by \fIKEYWORD\fP.
> It must be a keyword from the following list:
> .nh
> .BR bios\-vendor ,
> .BR bios\-version ,
> .BR bios\-release\-date ,
> .BR bios\-revision ,
> .BR firmware\-revision ,
> .BR system\-manufacturer ,
> .BR system\-product\-name ,
> .BR system\-version ,
> .BR system\-serial\-number ,
> .BR system\-uuid ,
> .BR system\-sku\-number ,
> .BR system\-family ,
> .BR baseboard\-manufacturer ,
> .BR baseboard\-product\-name ,
> .BR baseboard\-version ,
> .BR baseboard\-serial\-number ,
> .BR baseboard\-asset\-tag ,
> .BR chassis\-manufacturer ,
> .BR chassis\-type ,
> .BR chassis\-version ,
> .BR chassis\-serial\-number ,
> .BR chassis\-asset\-tag ,
> .BR processor\-family ,
> .BR processor\-manufacturer ,
> .BR processor\-version ,
> .BR processor\-frequency .
> .hy
> Each keyword corresponds to a given \s-1DMI\s0 type and a given offset
> within this entry type.
> Not all strings may be meaningful or even defined on all systems. Some
> keywords may return more than one result on some systems (e.g.
> .nh
> .B processor\-version
> .hy
> on a multi-processor system).
> If \fIKEYWORD\fP is not provided or not valid, a list of all valid
> keywords is printed and
> .B dmidecode
> exits with an error.
> This option cannot be used more than once.
> 
> Note: on Linux, most of these strings can alternatively be read directly
> from
> .BR sysfs ,
> typically from files under
> .IR /sys/devices/virtual/dmi/id .
> Most of these files are even readable by regular users.
> .TP
> .BR "-t" ", " "--type \fITYPE\fP"
> Only display the entries of type \fITYPE\fP. It can be either a
> \s-1DMI\s0 type number, or a comma-separated list of type numbers, or a
> keyword from the following list:
> .nh
> .BR bios ,
> .BR system ,
> .BR baseboard ,
> .BR chassis ,
> .BR processor ,
> .BR memory ,
> .BR cache ,
> .BR connector ,
> .BR slot .
> .hy
> Refer to the DMI TYPES section below for details.
> If this option is used more than once, the set of displayed entries will be
> the union of all the given types.
> If \fITYPE\fP is not provided or not valid, a list of all valid keywords
> is printed and
> .B dmidecode
> exits with an error.
> .TP
> .BR "-H" ", " "--handle \fIHANDLE\fP"
> Only display the entry whose handle matches \fIHANDLE\fP.
> \fIHANDLE\fP is a 16-bit integer.
> .TP
> .BR "-u" ", " "--dump"
> Do not decode the entries, dump their contents as hexadecimal instead.
> Note that this is still a text output, no binary data will be thrown upon
> you. The strings attached to each entry are displayed as both
> hexadecimal and \s-1ASCII\s0. This option is mainly useful for debugging.
> .TP
> .BR "  " "  " "--dump-bin \fIFILE\fP"
> Do not decode the entries, instead dump the DMI data to a file in binary
> form. The generated file is suitable to pass to \fB--from-dump\fP
> later.
> .TP
> .BR "  " "  " "--from-dump \fIFILE\fP"
> Read the DMI data from a binary file previously generated using
> \fB--dump-bin\fP.
> .TP
> .BR "  " "  " "--no-sysfs"
> Do not attempt to read DMI data from sysfs files. This is mainly useful for
> debugging.
> .TP
> .BR "  " "  " "--oem-string \fIN\fP"
> Only display the value of the \s-1OEM\s0 string number \fIN\fP. The first
> \s-1OEM\s0 string has number \fB1\fP. With special value \fBcount\fP, return the
> number of OEM strings instead.
> .TP
> .BR "-h" ", " "--help"
> Display usage information and exit
> .TP
> .BR "-V" ", " "--version"
> Display the version and exit
> .P
> Options
> .BR --string ,
> .BR --type,
> .BR --dump-bin " and " --oem-string
> determine the output format and are mutually exclusive.
> .P
> Please note in case of
> .B dmidecode
> is run on a system with BIOS that boasts new SMBIOS specification, which
> is not supported by the tool yet, it will print out relevant message in
> addition to requested data on the very top of the output. Thus informs the
> output data is not reliable.
> .\"
> .SH "DMI TYPES"
> The \s-1SMBIOS\s0 specification defines the following \s-1DMI\s0 types:
> .TS
> r l
> __
> r l.
> Type	Information
> 0	BIOS
> 1	System
> 2	Baseboard
> 3	Chassis
> 4	Processor
> 5	Memory Controller
> 6	Memory Module
> 7	Cache
> 8	Port Connector
> 9	System Slots
> 10	On Board Devices
> 11	OEM Strings
> 12	System Configuration Options
> 13	BIOS Language
> 14	Group Associations
> 15	System Event Log
> 16	Physical Memory Array
> 17	Memory Device
> 18	32-bit Memory Error
> 19	Memory Array Mapped Address
> 20	Memory Device Mapped Address
> 21	Built-in Pointing Device
> 22	Portable Battery
> 23	System Reset
> 24	Hardware Security
> 25	System Power Controls
> 26	Voltage Probe
> 27	Cooling Device
> 28	Temperature Probe
> 29	Electrical Current Probe
> 30	Out-of-band Remote Access
> 31	Boot Integrity Services
> 32	System Boot
> 33	64-bit Memory Error
> 34	Management Device
> 35	Management Device Component
> 36	Management Device Threshold Data
> 37	Memory Channel
> 38	IPMI Device
> 39	Power Supply
> 40	Additional Information
> 41	Onboard Devices Extended Information
> 42	Management Controller Host Interface
> .TE
> 
> Additionally, type 126 is used for disabled entries and type 127 is an
> end-of-table marker. Types 128 to 255 are for \s-1OEM\s0-specific data.
> .B dmidecode
> will display these entries by default, but it can only decode them
> when the vendors have contributed documentation or code for them.
> 
> Keywords can be used instead of type numbers with \fB--type\fP.
> Each keyword is equivalent to a list of type numbers:
> 
> .TS
> l l
> __
> l l.
> Keyword	Types
> bios	0, 13
> system	1, 12, 15, 23, 32
> baseboard	2, 10, 41
> chassis	3
> processor	4
> memory	5, 6, 16, 17
> cache	7
> connector	8
> slot	9
> .TE
> 
> Keywords are matched case-insensitively. The following command lines are equivalent:
> .IP \(bu "\w'\(bu'u+1n"
> dmidecode --type 0 --type 13
> .IP \(bu
> dmidecode --type 0,13
> .IP \(bu
> dmidecode --type bios
> .IP \(bu
> dmidecode --type BIOS
> .\"
> .SH BINARY DUMP FILE FORMAT
> The binary dump files generated by \fB--dump-bin\fP and read using \fB--from-dump\fP
> are formatted as follows:
> .IP \(bu "\w'\(bu'u+1n"
> The SMBIOS or DMI entry point is located at offset 0x00.
> It is crafted to hard-code the table address at offset 0x20.
> .IP \(bu "\w'\(bu'u+1n"
> The DMI table is located at offset 0x20.
> .\"
> .SH UUID FORMAT
> There is some ambiguity about how to interpret the UUID fields prior to SMBIOS
> specification version 2.6. There was no mention of byte swapping, and RFC 4122
> says that no byte swapping should be applied by default. However, SMBIOS
> specification version 2.6 (and later) explicitly states that the first 3 fields
> of the UUID should be read as little-endian numbers (byte-swapped).
> Furthermore, it implies that the same was already true for older versions of
> the specification, even though it was not mentioned. In practice, many hardware
> vendors were not byte-swapping the UUID. So, in order to preserve
> compatibility, it was decided to interpret the UUID fields according to RFC
> 4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to
> interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS
> version is 2.6 or later. The Linux kernel follows the same logic.
> .\"
> .SH FILES
> .I /dev/mem
> .br
> .I /sys/firmware/dmi/tables/smbios_entry_point
> (Linux only)
> .br
> .I /sys/firmware/dmi/tables/DMI
> (Linux only)
> .\"
> .SH BUGS
> More often than not, information contained in the \s-1DMI\s0 tables is inaccurate,
> incomplete or simply wrong.
> .\"
> .SH AUTHORS
> Alan Cox, Jean Delvare
> .\"
> .SH "SEE ALSO"
> .BR biosdecode (8),
> .BR mem (4),
> .BR ownership (8),
> .BR vpddecode (8)


--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv