From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27610 invoked from network); 25 Aug 2022 16:30:44 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 25 Aug 2022 16:30:44 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 78edc6d4 for ; Thu, 25 Aug 2022 11:30:43 -0500 (EST) Received: from mx.stare.cz (uvt.stare.cz [185.63.96.79]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 62055251 for ; Thu, 25 Aug 2022 11:30:27 -0500 (EST) Received: from localhost (stare.cz [local]) by stare.cz (OpenSMTPD) with ESMTPA id c0ae4423 for ; Thu, 25 Aug 2022 18:30:26 +0200 (CEST) Date: Thu, 25 Aug 2022 18:30:26 +0200 From: Jan Stary To: discuss@mdocml.bsd.lv Subject: Re: -Tps rendering of verbatim .TS/.TE Message-ID: References: X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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