acct.5, elf.5, hosts.5, resolv.conf.5, rpc.5, slabinfo.5, utmp.5: Formatting fix: replace blank lines with .PP/.IP

Blank lines shouldn't generally appear in *roff source (other
than in code examples), since they create large vertical
spaces between text blocks.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2017-08-16 02:59:28 +02:00
parent 2a86152e72
commit eabf3ae555
7 changed files with 32 additions and 32 deletions

View File

@ -33,18 +33,18 @@ If the kernel is built with the process accounting option enabled
then calling then calling
.BR acct (2) .BR acct (2)
starts process accounting, for example: starts process accounting, for example:
.PP
.in +4n .in +4n
acct("/var/log/pacct"); acct("/var/log/pacct");
.in .in
.PP
When process accounting is enabled, the kernel writes a record When process accounting is enabled, the kernel writes a record
to the accounting file as each process on the system terminates. to the accounting file as each process on the system terminates.
This record contains information about the terminated process, This record contains information about the terminated process,
and is defined in and is defined in
.I <sys/acct.h> .I <sys/acct.h>
as follows: as follows:
.PP
.in +4n .in +4n
.nf .nf
#define ACCT_COMM 16 #define ACCT_COMM 16
@ -119,7 +119,7 @@ and
fields is widened from 16 to 32 bits fields is widened from 16 to 32 bits
(in line with the increased size of UID and GIDs in Linux 2.4 and later). (in line with the increased size of UID and GIDs in Linux 2.4 and later).
The records are defined as follows: The records are defined as follows:
.PP
.in +4n .in +4n
.nf .nf
struct acct_v3 { struct acct_v3 {
@ -157,14 +157,14 @@ and the details vary somewhat between systems.
.SH NOTES .SH NOTES
Records in the accounting file are ordered by termination time of Records in the accounting file are ordered by termination time of
the process. the process.
.PP
In kernels up to and including 2.6.9, In kernels up to and including 2.6.9,
a separate accounting record is written for each thread created using a separate accounting record is written for each thread created using
the NPTL threading library; the NPTL threading library;
since Linux 2.6.10, since Linux 2.6.10,
a single accounting record is written for the entire process a single accounting record is written for the entire process
on termination of the last thread in the process. on termination of the last thread in the process.
.PP
The The
.I proc/sys/kernel/acct .I proc/sys/kernel/acct
file, described in file, described in

View File

@ -238,10 +238,10 @@ Two's complement, big-endian.
.PD .PD
.RE .RE
.TP .TP
.PD 0
.BR EI_VERSION .BR EI_VERSION
The seventh byte is the version number of the ELF specification: The seventh byte is the version number of the ELF specification:
.IP
.PD 0
.RS .RS
.TP 14 .TP 14
.BR EV_NONE .BR EV_NONE
@ -1852,7 +1852,7 @@ but many projects define their own set of extensions.
For example, For example,
the GNU tool chain uses ELF notes to pass information from the GNU tool chain uses ELF notes to pass information from
the linker to the C library. the linker to the C library.
.PP
Note sections contain a series of notes (see the Note sections contain a series of notes (see the
.I struct .I struct
definitions below). definitions below).
@ -1860,10 +1860,10 @@ Each note is followed by the name field (whose length is defined in
\fIn_namesz\fR) and then by the descriptor field (whose length is defined in \fIn_namesz\fR) and then by the descriptor field (whose length is defined in
\fIn_descsz\fR) and whose starting address has a 4 byte alignment. \fIn_descsz\fR) and whose starting address has a 4 byte alignment.
Neither field is defined in the note struct due to their arbitrary lengths. Neither field is defined in the note struct due to their arbitrary lengths.
.PP
An example for parsing out two consecutive notes should clarify their layout An example for parsing out two consecutive notes should clarify their layout
in memory: in memory:
.PP
.in +4n .in +4n
.nf .nf
void *memory, *name, *desc; void *memory, *name, *desc;
@ -1887,7 +1887,7 @@ next_note = memory + sizeof(*note) +
ALIGN_UP(note->n_descsz, 4); ALIGN_UP(note->n_descsz, 4);
.fi .fi
.in .in
.PP
Keep in mind that the interpretation of Keep in mind that the interpretation of
.I n_type .I n_type
depends on the namespace defined by the depends on the namespace defined by the
@ -2073,7 +2073,7 @@ Extensions used by the GNU tool chain.
.B NT_GNU_ABI_TAG .B NT_GNU_ABI_TAG
Operating system (OS) ABI information. Operating system (OS) ABI information.
The desc field will be 4 words: The desc field will be 4 words:
.IP
.PD 0 .PD 0
.RS .RS
.IP \(bu 2 .IP \(bu 2
@ -2091,7 +2091,7 @@ word 3: subminor version of the ABI
.B NT_GNU_HWCAP .B NT_GNU_HWCAP
Synthetic hwcap information. Synthetic hwcap information.
The desc field begins with two words: The desc field begins with two words:
.IP
.PD 0 .PD 0
.RS .RS
.IP \(bu 2 .IP \(bu 2
@ -2130,7 +2130,7 @@ A version string of some sort.
Architecture information. Architecture information.
.PD .PD
.RE .RE
.PP
.RE .RE
.SH NOTES .SH NOTES
.\" OpenBSD .\" OpenBSD

View File

@ -91,7 +91,7 @@ except in cases where the file is cached by applications.
.SS Historical notes .SS Historical notes
RFC\ 952 gave the original format for the host table, though it has RFC\ 952 gave the original format for the host table, though it has
since changed. since changed.
.PP
Before the advent of DNS, the host table was the only way of resolving Before the advent of DNS, the host table was the only way of resolving
hostnames on the fledgling Internet. hostnames on the fledgling Internet.
Indeed, this file could be Indeed, this file could be
@ -129,7 +129,7 @@ ff02::2 ip6-allrouters
.BR resolver (5), .BR resolver (5),
.BR hostname (7), .BR hostname (7),
.BR named (8) .BR named (8)
.PP
Internet RFC\ 952 Internet RFC\ 952
.\" .SH AUTHOR .\" .SH AUTHOR
.\" This manual page was written by Manoj Srivastava <srivasta@debian.org>, .\" This manual page was written by Manoj Srivastava <srivasta@debian.org>,

View File

@ -119,7 +119,7 @@ and optional network pairs are separated by slashes.
Up to 10 pairs may Up to 10 pairs may
be specified. be specified.
Here is an example: Here is an example:
.IP
.in +4n .in +4n
sortlist 130.155.160.0/255.255.240.0 130.155.0.0 sortlist 130.155.160.0/255.255.240.0 130.155.0.0
.in .in
@ -323,7 +323,7 @@ as explained above under \fBoptions\fP.
The keyword and value must appear on a single line, and the keyword The keyword and value must appear on a single line, and the keyword
(e.g., \fBnameserver\fP) must start the line. (e.g., \fBnameserver\fP) must start the line.
The value follows the keyword, separated by white space. The value follows the keyword, separated by white space.
.PP
Lines that contain a semicolon (;) or hash character (#) Lines that contain a semicolon (;) or hash character (#)
in the first column are treated as comments. in the first column are treated as comments.
.SH FILES .SH FILES
@ -337,5 +337,5 @@ in the first column are treated as comments.
.BR nsswitch.conf (5), .BR nsswitch.conf (5),
.BR hostname (7), .BR hostname (7),
.BR named (8) .BR named (8)
.PP
Name Server Operations Guide for BIND Name Server Operations Guide for BIND

View File

@ -16,7 +16,7 @@ The
file contains user readable names that file contains user readable names that
can be used in place of RPC program numbers. can be used in place of RPC program numbers.
Each line has the following information: Each line has the following information:
.PP
.PD 0 .PD 0
.IP \(bu 3 .IP \(bu 3
name of server for the RPC program name of server for the RPC program

View File

@ -55,7 +55,7 @@ which allows an application that is reading the file to handle changes
in the file format. in the file format.
(See VERSIONS, below.) (See VERSIONS, below.)
The next line lists the names of the columns in the remaining lines. The next line lists the names of the columns in the remaining lines.
.PP
Each of the remaining lines displays information about a specified cache. Each of the remaining lines displays information about a specified cache.
Following the cache name, Following the cache name,
the output shown in each line shows three components for each cache: the output shown in each line shows three components for each cache:
@ -94,9 +94,9 @@ When using the older SLAB allocator,
the tunables for a particular cache can be set by writing the tunables for a particular cache can be set by writing
lines of the following form to lines of the following form to
.IR /proc/slabinfo : .IR /proc/slabinfo :
.PP
# \fBecho 'name limit batchcount sharedfactor' > /proc/slabinfo\fP # \fBecho 'name limit batchcount sharedfactor' > /proc/slabinfo\fP
.PP
Here, Here,
.I name .I name
is the cache name, and is the cache name, and
@ -116,7 +116,7 @@ and
should be nonnegative. should be nonnegative.
If any of the specified values is invalid, If any of the specified values is invalid,
the cache settings are left unchanged. the cache settings are left unchanged.
.PP
The The
.I tunables .I tunables
entries in each line contain the following fields: entries in each line contain the following fields:
@ -155,7 +155,7 @@ Note that because of object alignment and slab cache overhead,
objects are not normally packed tightly into pages. objects are not normally packed tightly into pages.
Pages with even one in-use object are considered in-use and cannot be Pages with even one in-use object are considered in-use and cannot be
freed. freed.
.PP
Kernels configured with Kernels configured with
.B CONFIG_DEBUG_SLAB .B CONFIG_DEBUG_SLAB
will also have additional statistics fields in each line, will also have additional statistics fields in each line,
@ -222,14 +222,14 @@ Only root can read and (if the kernel was configured with
write the write the
.IR /proc/slabinfo .IR /proc/slabinfo
file. file.
.PP
The total amount of memory allocated to the SLAB/SLUB cache is shown in the The total amount of memory allocated to the SLAB/SLUB cache is shown in the
.I Slab .I Slab
field of field of
.IR /proc/meminfo . .IR /proc/meminfo .
.SH SEE ALSO .SH SEE ALSO
.BR slabtop (1) .BR slabtop (1)
.PP
The kernel source file The kernel source file
.IR Documentation/vm/slub.txt .IR Documentation/vm/slub.txt
and and

View File

@ -244,7 +244,7 @@ POSIX.1 does not specify the lengths of the
and and
.I ut_user .I ut_user
fields. fields.
.PP
Linux defines the Linux defines the
.I utmpx .I utmpx
structure to be the same as the structure to be the same as the
@ -253,14 +253,14 @@ structure.
.SS Comparison with historical systems .SS Comparison with historical systems
Linux utmp entries conform neither to v7/BSD nor to System V; they are a Linux utmp entries conform neither to v7/BSD nor to System V; they are a
mix of the two. mix of the two.
.PP
v7/BSD has fewer fields; most importantly it lacks v7/BSD has fewer fields; most importantly it lacks
\fIut_type\fP, which causes native v7/BSD-like programs to display (for \fIut_type\fP, which causes native v7/BSD-like programs to display (for
example) dead or login entries. example) dead or login entries.
Further, there is no configuration file Further, there is no configuration file
which allocates slots to sessions. which allocates slots to sessions.
BSD does so because it lacks \fIut_id\fP fields. BSD does so because it lacks \fIut_id\fP fields.
.PP
In Linux (as in System V), the \fIut_id\fP field of a In Linux (as in System V), the \fIut_id\fP field of a
record will never change once it has been set, which reserves that slot record will never change once it has been set, which reserves that slot
without needing a configuration file. without needing a configuration file.
@ -315,7 +315,7 @@ then instead of the call:
gettimeofday((struct timeval *) &ut.ut_tv, NULL); gettimeofday((struct timeval *) &ut.ut_tv, NULL);
.fi .fi
.in .in
.PP
the following method of setting this field is recommended: the following method of setting this field is recommended:
.in +4n .in +4n
.nf .nf