execve.2, ioctl_console.2, ioctl_iflags.2, ioctl_ns.2, ioctl_userfaultfd.2, kcmp.2, kexec_load.2, keyctl.2, link.2, listxattr.2, membarrier.2, memfd_create.2, mmap.2, modify_ldt.2, mprotect.2, msgctl.2, nanosleep.2, open_by_handle_at.2, perf_event_open.2, poll.2, posix_fadvise.2, process_vm_readv.2, ptrace.2, query_module.2, quotactl.2, readdir.2, readv.2, recv.2, recvmmsg.2, request_key.2, sched_rr_get_interval.2, sched_setaffinity.2, sched_setattr.2, sched_setscheduler.2, seccomp.2, select.2, select_tut.2, semctl.2, semop.2, send.2, sendmmsg.2, set_thread_area.2, setns.2, shmctl.2, shmget.2, sigaction.2, sigaltstack.2, signal.2, sigwaitinfo.2, stat.2, statfs.2, statx.2, sync_file_range.2, syscall.2, sysctl.2, sysinfo.2, tee.2, timer_create.2, timer_settime.2, timerfd_create.2, unshare.2, userfaultfd.2, ustat.2, utime.2, utimensat.2, vmsplice.2, wait.2, adjtime.3, aio_init.3, backtrace.3, basename.3, bswap.3, btree.3, clock_getcpuclockid.3, cmsg.3, confstr.3, dbopen.3, dl_iterate_phdr.3, dladdr.3, dlinfo.3, dlopen.3, duplocale.3, encrypt.3, end.3, endian.3, err.3, errno.3, ether_aton.3, fgetgrent.3, fgetpwent.3, fmemopen.3, frexp.3, ftime.3, fts.3, getaddrinfo.3, getaddrinfo_a.3, getdate.3, getfsent.3, getgrent.3, getgrent_r.3, getgrnam.3, getgrouplist.3, gethostbyname.3, getifaddrs.3, getipnodebyname.3, getmntent.3, getnameinfo.3, getnetent.3, getopt.3, getprotoent.3, getprotoent_r.3, getpw.3, getpwent.3, getpwent_r.3, getpwnam.3, getrpcent.3, getservent.3, getservent_r.3, getspnam.3, getttyent.3, glob.3, gnu_get_libc_version.3, hash.3, hsearch.3, if_nameindex.3, inet.3, inet_net_pton.3, inet_pton.3, insque.3, isalpha.3, makecontext.3, mallinfo.3, malloc_info.3, mallopt.3, matherr.3, mbstowcs.3, mcheck.3, memchr.3, mq_getattr.3, mq_open.3, mq_receive.3, mq_send.3, mtrace.3, newlocale.3, ntp_gettime.3, posix_openpt.3, printf.3, pthread_attr_init.3, pthread_attr_setschedparam.3, pthread_cancel.3, pthread_cleanup_push.3, pthread_cleanup_push_defer_np.3, pthread_create.3, pthread_getattr_default_np.3, pthread_getattr_np.3, pthread_getcpuclockid.3, pthread_setname_np.3, pthread_setschedparam.3, pthread_sigmask.3, pthread_tryjoin_np.3, readdir.3, realpath.3, recno.3, regex.3, rpc.3, scanf.3, sched_getcpu.3, sem_wait.3, setaliasent.3, sigqueue.3, statvfs.3, strcat.3, strcpy.3, strftime.3, strtok.3, strtol.3, strverscmp.3, toupper.3, ttyslot.3, xdr.3, fuse.4, loop.4, rtc.4, st.4, acct.5, core.5, elf.5, slabinfo.5, aio.7, arp.7, capabilities.7, cgroup_namespaces.7, cgroups.7, ddp.7, fanotify.7, feature_test_macros.7, inode.7, inotify.7, ip.7, keyrings.7, locale.7, mount_namespaces.7, namespaces.7, netdevice.7, netlink.7, packet.7, pkeys.7, pthreads.7, sched.7, session-keyring.7, sock_diag.7, socket.7, spufs.7, udplite.7, unix.7, user_namespaces.7, vdso.7, x25.7, ld.so.8: Use consistent markup for code snippets

Change .nf/.fi to .EX/.EE

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2017-08-18 21:52:46 +02:00
parent 7a34607716
commit b8302363ed
219 changed files with 813 additions and 813 deletions

View File

@ -296,9 +296,9 @@ An interpreter script is a text file that has execute
permission enabled and whose first line is of the form:
.PP
.in +4n
.nf
.EX
\fB#!\fP \fIinterpreter \fP[optional-arg]
.fi
.EE
.in
.PP
The
@ -313,9 +313,9 @@ specifies an interpreter script, then
will be invoked with the following arguments:
.PP
.in +4n
.nf
.EX
\fIinterpreter\fP [optional-arg] \fIfilename\fP arg...
.fi
.EE
.in
.PP
where

View File

@ -455,7 +455,7 @@ struct kbsentry {
unsigned char kb_func;
unsigned char kb_string[512];
};
.fi
.EE
.in
.IP
.I kb_string

View File

@ -35,7 +35,7 @@ These flags can be retrieved and modified using two
operations:
.PP
.in +4n
.nf
.EX
int attr;
fd = open("pathname", ...);
@ -44,7 +44,7 @@ ioctl(fd, FS_IOC_GETFLAGS, &attr); /* Place current flags
attr |= FS_NOATIME_FL; /* Tweak returned bit mask */
ioctl(fd, FS_IOC_SETFLAGS, &attr); /* Update flags for inode
referred to by \(aqfd\(aq */
.fi
.EE
.in
.PP
The

View File

@ -39,9 +39,9 @@ and
The form of the calls is:
.PP
.in +4n
.nf
.EX
new_fd = ioctl(fd, request);
.fi
.EE
.in
.PP
In each case,
@ -125,9 +125,9 @@ the type of namespace referred to by the file descriptor
.IR fd :
.PP
.in +4n
.nf
.EX
nstype = ioctl(fd, NS_GET_NSTYPE);
.fi
.EE
.in
.PP
.I fd
@ -154,10 +154,10 @@ of the process that created the user namespace).
The form of the call is:
.PP
.in +4n
.nf
.EX
uid_t uid;
ioctl(fd, NS_GET_OWNER_UID, &uid);
.fi
.EE
.in
.PP
.I fd
@ -198,10 +198,10 @@ Trying to get the parent of the initial user namespace fails,
since it has no parent:
.PP
.in +4n
.nf
.EX
$ \fB./ns_show /proc/self/ns/user p\fP
The parent namespace is outside your namespace scope
.fi
.EE
.in
.PP
Create a process running
@ -210,26 +210,26 @@ that resides in new user and UTS namespaces,
and show that the new UTS namespace is associated with the new user namespace:
.PP
.in +4n
.nf
.EX
$ \fBunshare \-Uu sleep 1000 &\fP
[1] 23235
$ \fB./ns_show /proc/23235/ns/uts u\fP
Device/Inode of owning user namespace is: [0,3] / 4026532448
$ \fBreadlink /proc/23235/ns/user \fP
user:[4026532448]
.fi
.EE
.in
.PP
Then show that the parent of the new user namespace in the preceding
example is the initial user namespace:
.PP
.in +4n
.nf
.EX
$ \fBreadlink /proc/self/ns/user\fP
user:[4026531837]
$ \fB./ns_show /proc/23235/ns/user p\fP
Device/Inode of parent namespace is: [0,3] / 4026531837
.fi
.EE
.in
.PP
Start a shell in a new user namespace, and show that from within
@ -239,13 +239,13 @@ Similarly, the UTS namespace
can't be discovered.
.PP
.in +4n
.nf
.EX
$ \fBPS1="sh2$ " unshare \-U bash\fP
sh2$ \fB./ns_show /proc/self/ns/user p\fP
The parent namespace is outside your namespace scope
sh2$ \fB./ns_show /proc/self/ns/uts u\fP
The owning user namespace is outside your namespace scope
.fi
.EE
.in
.SS Program source
\&

View File

@ -513,13 +513,13 @@ structure pointed to by
.IR argp :
.PP
.in +4n
.nf
.EX
struct uffdio_zeropage {
struct uffdio_range range;
__u64 mode; /* Flags controlling behavior of copy */
__s64 zeropage; /* Number of bytes zeroed, or negated error */
};
.fi
.EE
.in
.PP
The following value may be bitwise ORed in

View File

@ -175,13 +175,13 @@ is a pointer to a structure where the target file is described.
This structure has the form:
.PP
.in +4n
.nf
.EX
struct kcmp_epoll_slot {
__u32 efd;
__u32 tfd;
__u64 toff;
};
.fi
.EE
.in
.PP
Within this structure,
@ -329,7 +329,7 @@ as described in the program output.
An example run of the program is as follows:
.PP
.in +4n
.nf
.EX
$ \fB./a.out\fP
Parent PID is 1144
Parent opened file on FD 3
@ -343,7 +343,7 @@ Child opened file on FD 4
Child duplicated FD 3 to create FD 5
Compare duplicated FDs in same process:
kcmp(1145, 1145, KCMP_FILE, 3, 5) ==> same
.fi
.EE
.in
.SS Program source
\&

View File

@ -126,7 +126,7 @@ struct kexec_segment {
void *mem; /* Physical address of kernel */
size_t memsz; /* Physical address length */
};
.fi
.EE
.in
.PP
The kernel image defined by

View File

@ -1281,12 +1281,12 @@ but the payload data is specified as an array of
structures:
.IP
.in +4n
.nf
.EX
struct iovec {
void *iov_base; /* Starting address of buffer */
size_t iov_len; /* Size of buffer (in bytes) */
};
.fi
.EE
.in
.IP
The pointer to the payload vector is specified in
@ -1424,14 +1424,14 @@ keys used in the Diffie-Hellman calculation,
packaged in a structure of the following form:
.IP
.in +4n
.nf
.EX
struct keyctl_dh_params {
int32_t private; /* The local private key */
int32_t prime; /* The prime, known to both parties */
int32_t base; /* The base integer: either a shared
generator or the remote public key */
};
.fi
.EE
.in
.IP
Each of the three keys specified in this structure must grant the caller
@ -1709,21 +1709,21 @@ we use the example program shown in
to request a key.
.PP
.in +4n
.nf
.EX
$ \fBcc \-o key_instantiate key_instantiate.c \-lkeyutils\fP
$ \fBsudo mv /sbin/request\-key /sbin/request\-key.backup\fP
$ \fBsudo cp key_instantiate /sbin/request\-key\fP
$ \fB./t_request_key user mykey somepayloaddata\fP
Key ID is 20d035bf
$ \fBsudo mv /sbin/request\-key.backup /sbin/request\-key\fP
.fi
.EE
.in
.PP
Looking at the log file created by this program,
we can see the command-line arguments supplied to our example program:
.PP
.in +4n
.nf
.EX
$ \fBcat /tmp/key_instantiate.log \fP
Time: Mon Nov 7 13:06:47 2016
@ -1741,7 +1741,7 @@ Key description: user;1000;1000;3f010000;mykey
Auth key payload: somepayloaddata
Destination keyring: 256e6a6
Auth key description: .request_key_auth;1000;1000;0b010000;20d035bf
.fi
.EE
.in
.PP
The last few lines of the above output show that the example program
@ -1780,11 +1780,11 @@ and ID
.IR 20d035bf .
.PP
.in +4n
.nf
.EX
$ \fBcat /proc/keys | egrep \(aqmykey|256e6a6\(aq\fP
0256e6a6 I\-\-Q\-\-\- 194 perm 3f030000 1000 1000 keyring _ses: 3
20d035bf I\-\-Q\-\-\- 1 perm 3f010000 1000 1000 user mykey: 16
.fi
.EE
.in
.SS Program source
\&

View File

@ -170,10 +170,10 @@ this can be used as an alternative to
like this:
.IP
.in +4n
.nf
.EX
linkat(AT_FDCWD, "/proc/self/fd/<fd>", newdirfd,
newname, AT_SYMLINK_FOLLOW);
.fi
.EE
.in
.PP
Before kernel 2.6.18, the

View File

@ -205,7 +205,7 @@ some extended file attributes,
and then listing the attributes with the example program.
.SS Example output
.in +4n
.nf
.EX
$ \fBtouch /tmp/foo\fP
$ \fBsetfattr -n user.fred -v chocolate /tmp/foo\fP
$ \fBsetfattr -n user.frieda -v bar /tmp/foo\fP
@ -214,7 +214,7 @@ $ \fB./listxattr /tmp/foo\fP
user.fred: chocolate
user.frieda: bar
user.empty: <no value>
.fi
.EE
.in
.SS Program source (listxattr.c)
.nf

View File

@ -186,7 +186,7 @@ following code (x86) can be transformed using
.BR membarrier ():
.PP
.in +4n
.nf
.EX
#include <stdlib.h>
static volatile int a, b;
@ -228,7 +228,7 @@ main(int argc, char **argv)
exit(EXIT_SUCCESS);
}
.fi
.EE
.in
.PP
The code above transformed to use
@ -236,7 +236,7 @@ The code above transformed to use
becomes:
.PP
.in +4n
.nf
.EX
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
@ -314,5 +314,5 @@ main(int argc, char **argv)
exit(EXIT_SUCCESS);
}
.fi
.EE
.in

View File

@ -325,11 +325,11 @@ First we create a
file and set some seals on it:
.PP
.in +4n
.nf
.EX
$ \fB./t_memfd_create my_memfd_file 4096 sw &\fP
[1] 11775
PID: 11775; fd: 3; /proc/11775/fd/3
.fi
.EE
.in
.PP
At this point, the
@ -349,12 +349,12 @@ symbolic link, and use our
program to view the seals that have been placed on the file:
.PP
.in +4n
.nf
.EX
$ \fBreadlink /proc/11775/fd/3\fP
/memfd:my_memfd_file (deleted)
$ \fB./t_get_seals /proc/11775/fd/3\fP
Existing seals: WRITE SHRINK
.fi
.EE
.in
.SS Program source: t_memfd_create.c
\&

View File

@ -263,10 +263,10 @@ field exposed by
Thus, the above two constants are defined as:
.IP
.in +4n
.nf
.EX
#define MAP_HUGE_2MB (21 << MAP_HUGE_SHIFT)
#define MAP_HUGE_1GB (30 << MAP_HUGE_SHIFT)
.fi
.EE
.in
.IP
The range of huge page sizes that are supported by the system

View File

@ -88,7 +88,7 @@ struct user_desc {
unsigned int seg_not_present:1;
unsigned int useable:1;
};
.fi
.EE
.in
.PP
In Linux 2.4 and earlier, this structure was named

View File

@ -292,11 +292,11 @@ An example of what we might see when running the program is the
following:
.PP
.in +4n
.nf
.EX
.RB "$" " ./a.out"
Start of region: 0x804c000
Got SIGSEGV at address: 0x804e000
.fi
.EE
.in
.SS Program source
\&

View File

@ -72,7 +72,7 @@ struct msqid_ds {
pid_t msg_lspid; /* PID of last msgsnd(2) */
pid_t msg_lrpid; /* PID of last msgrcv(2) */
};
.fi
.EE
.in
.PP
The
@ -82,7 +82,7 @@ structure is defined as follows
.BR IPC_SET ):
.PP
.in +4n
.nf
.EX
struct ipc_perm {
key_t __key; /* Key supplied to msgget(2) */
uid_t \fBuid\fP; /* Effective UID of owner */
@ -92,7 +92,7 @@ struct ipc_perm {
unsigned short \fBmode\fP; /* Permissions */
unsigned short __seq; /* Sequence number */
};
.fi
.EE
.in
.PP
Valid values for

View File

@ -78,12 +78,12 @@ is used to specify intervals of time with nanosecond precision.
It is defined as follows:
.PP
.in +4n
.nf
.EX
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.PP
The value of the nanoseconds field must be in the range 0 to 999999999.

View File

@ -70,14 +70,14 @@ The file handle is returned via the argument
which is a pointer to a structure of the following form:
.PP
.in +4n
.nf
.EX
struct file_handle {
unsigned int handle_bytes; /* Size of f_handle [in, out] */
int handle_type; /* Handle type [out] */
unsigned char f_handle[0]; /* File identifier (sized by
caller) [out] */
};
.fi
.EE
.in
.PP
It is the caller's responsibility to allocate the structure
@ -471,7 +471,7 @@ and the mount directory specified in that record is opened.
The following shell session demonstrates the use of these two programs:
.PP
.in +4n
.nf
.EX
$ \fBecho 'Can you please think about it?' > cecilia.txt\fP
$ \fB./t_name_to_handle_at cecilia.txt > fh\fP
$ \fB./t_open_by_handle_at < fh\fP
@ -479,7 +479,7 @@ open_by_handle_at: Operation not permitted
$ \fBsudo ./t_open_by_handle_at < fh\fP # Need CAP_SYS_ADMIN
Read 31 bytes
$ \fBrm cecilia.txt\fP
.fi
.EE
.in
.PP
Now we delete and (quickly) re-create the file so that
@ -492,7 +492,7 @@ recognizes that the original file referred to by the file handle
no longer exists.
.PP
.in +4n
.nf
.EX
$ \fBstat \-\-printf="%i\\n" cecilia.txt\fP # Display inode number
4072121
$ \fBrm cecilia.txt\fP
@ -501,7 +501,7 @@ $ \fBstat \-\-printf="%i\\n" cecilia.txt\fP # Check inode number
4072121
$ \fBsudo ./t_open_by_handle_at < fh\fP
open_by_handle_at: Stale NFS file handle
.fi
.EE
.in
.SS Program source: t_name_to_handle_at.c
\&

View File

@ -201,7 +201,7 @@ structure provides detailed configuration information
for the event being created.
.PP
.in +4n
.nf
.EX
struct perf_event_attr {
__u32 type; /* Type of event */
__u32 size; /* Size of attribute structure */
@ -274,7 +274,7 @@ struct perf_event_attr {
__u16 __reserved_2; /* align to u64 */
};
.fi
.EE
.in
.PP
The fields of the
@ -1034,7 +1034,7 @@ value appearing twice.
The layout is described by this pseudo-structure:
.IP
.in +4n
.nf
.EX
struct sample_id {
{ u32 pid, tid; } /* if PERF_SAMPLE_TID set */
{ u64 time; } /* if PERF_SAMPLE_TIME set */
@ -1361,7 +1361,7 @@ If
was specified to allow reading all events in a group at once:
.IP
.in +4n
.nf
.EX
struct read_format {
u64 nr; /* The number of events */
u64 time_enabled; /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
@ -1371,7 +1371,7 @@ struct read_format {
u64 id; /* if PERF_FORMAT_ID */
} values[nr];
};
.fi
.EE
.in
.IP *
If
@ -1381,14 +1381,14 @@ was
specified:
.IP
.in +4n
.nf
.EX
struct read_format {
u64 value; /* The value of the event */
u64 time_enabled; /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
u64 time_running; /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
u64 id; /* if PERF_FORMAT_ID */
};
.fi
.EE
.in
.PP
The values read are as follows:
@ -1442,7 +1442,7 @@ ring buffer when sampling even if you do not plan to access it.
The structure of the first metadata mmap page is as follows:
.PP
.in +4n
.nf
.EX
struct perf_event_mmap_page {
__u32 version; /* version number of this structure */
__u32 compat_version; /* lowest version this is compat with */
@ -1476,7 +1476,7 @@ struct perf_event_mmap_page {
__u64 aux_size;
}
.fi
.EE
.in
.PP
The following list describes the fields in the
@ -1552,7 +1552,7 @@ without syscall (this is the "rdpmc" instruction on x86), then
the following code can be used to do a read:
.IP
.in +4n
.nf
.EX
u32 seq, time_mult, time_shift, idx, width;
u64 count, enabled, running;
u64 cyc, time_offset;
@ -1580,7 +1580,7 @@ do {
barrier();
} while (pc\->lock != seq);
.fi
.EE
.in
.TP
.IR cap_user_time " (since Linux 3.12)"
@ -1603,11 +1603,11 @@ read using the rdpmc or equivalent instruction.
This can be used to sign extend the result like:
.IP
.in +4n
.nf
.EX
pmc <<= 64 \- pmc_width;
pmc >>= 64 \- pmc_width; // signed shift right
count += pmc;
.fi
.EE
.in
.TP
.IR time_shift ", " time_mult ", " time_offset
@ -1761,13 +1761,13 @@ fields being ignored.
The mmap values start with a header:
.PP
.in +4n
.nf
.EX
struct perf_event_header {
__u32 type;
__u16 misc;
__u16 size;
};
.fi
.EE
.in
.PP
Below, we describe the
@ -1882,7 +1882,7 @@ user-space IPs to code.
They have the following structure:
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid, tid;
@ -1891,7 +1891,7 @@ struct {
u64 pgoff;
char filename[];
};
.fi
.EE
.in
.RS
.TP
@ -1915,14 +1915,14 @@ is a string describing the backing of the allocated memory.
This record indicates when events are lost.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u64 id;
u64 lost;
struct sample_id sample_id;
};
.fi
.EE
.in
.RS
.TP
@ -1937,7 +1937,7 @@ is the number of events that were lost.
This record indicates a change in the process name.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid;
@ -1945,7 +1945,7 @@ struct {
char comm[];
struct sample_id sample_id;
};
.fi
.EE
.in
.RS
.TP
@ -1963,7 +1963,7 @@ is a string containing the new name of the process.
This record indicates a process exit event.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid, ppid;
@ -1971,14 +1971,14 @@ struct {
u64 time;
struct sample_id sample_id;
};
.fi
.EE
.in
.TP
.BR PERF_RECORD_THROTTLE ", " PERF_RECORD_UNTHROTTLE
This record indicates a throttle/unthrottle event.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u64 time;
@ -1986,14 +1986,14 @@ struct {
u64 stream_id;
struct sample_id sample_id;
};
.fi
.EE
.in
.TP
.B PERF_RECORD_FORK
This record indicates a fork event.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid, ppid;
@ -2001,28 +2001,28 @@ struct {
u64 time;
struct sample_id sample_id;
};
.fi
.EE
.in
.TP
.B PERF_RECORD_READ
This record indicates a read event.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid, tid;
struct read_format values;
struct sample_id sample_id;
};
.fi
.EE
.in
.TP
.B PERF_RECORD_SAMPLE
This record indicates a sample.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u64 sample_id; /* if PERF_SAMPLE_IDENTIFIER */
@ -2486,7 +2486,7 @@ record, but includes extra values that allow uniquely identifying
shared mappings.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid;
@ -2549,7 +2549,7 @@ This record reports that new data is available in the separate
AUX buffer region.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u64 aux_offset;
@ -2587,7 +2587,7 @@ trace event, allowing tools to properly correlate the instruction
addresses in the AUX buffer with the proper executable.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 pid;
@ -2609,7 +2609,7 @@ When using hardware sampling (such as Intel PEBS) this record
indicates some number of samples that may have been lost.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u64 lost;
@ -2633,7 +2633,7 @@ field indicates whether it was a context switch into
or away from the current process.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
struct sample_id sample_id;
@ -2656,7 +2656,7 @@ field indicates whether it was a context switch into
or away from the current process.
.IP
.in +4n
.nf
.EX
struct {
struct perf_event_header header;
u32 next_prev_pid;

View File

@ -62,7 +62,7 @@ struct pollfd {
short events; /* requested events */
short revents; /* returned events */
};
.fi
.EE
.in
.PP
The caller should specify the number of items in the
@ -315,7 +315,7 @@ struct timespec {
long tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.PP
If

View File

@ -214,10 +214,10 @@ but is otherwise exactly the same as
For example, since Linux 2.6.14, ARM has the following system call:
.PP
.in +4n
.nf
.EX
.BI "long arm_fadvise64_64(int " fd ", int " advice ,
.BI " loff_t " offset ", loff_t " len );
.fi
.EE
.in
.PP
These architecture-specific details are generally

View File

@ -121,12 +121,12 @@ structures, defined in
as:
.PP
.in +4n
.nf
.EX
struct iovec {
void *iov_base; /* Starting address */
size_t iov_len; /* Number of bytes to transfer */
};
.fi
.EE
.in
.PP
Buffers are processed in array order.

View File

@ -412,7 +412,7 @@ struct ptrace_peeksiginfo_args {
u32 flags; /* PTRACE_PEEKSIGINFO_SHARED or 0 */
s32 nr; /* Number of signals to copy */
};
.fi
.EE
.in
.IP
Currently, there is only one flag,

View File

@ -85,7 +85,7 @@ struct module_symbol {
unsigned long value;
unsigned long name;
};
.fi
.EE
.in
.IP
followed by null-terminated strings.
@ -107,7 +107,7 @@ struct module_info {
unsigned long size;
unsigned long flags;
};
.fi
.EE
.in
.IP
where

View File

@ -218,7 +218,7 @@ field that is used to return the ID for which
quota information is being returned:
.IP
.in +4n
.nf
.EX
struct nextdqblk {
uint64_t dqb_bhardlimit;
uint64_t dqb_bsoftlimit;
@ -231,7 +231,7 @@ struct nextdqblk {
uint32_t dqb_valid;
uint32_t dqb_id;
};
.fi
.EE
.in
.TP
.B Q_SETQUOTA
@ -394,7 +394,7 @@ that contains a combination of the following flags (defined in
.IR <xfs/xqm.h> ):
.IP
.in +4n
.nf
.EX
#define XFS_QUOTA_UDQ_ACCT (1<<0) /* User quota
accounting */
#define XFS_QUOTA_UDQ_ENFD (1<<1) /* User quota limits
@ -407,7 +407,7 @@ that contains a combination of the following flags (defined in
accounting */
#define XFS_QUOTA_PDQ_ENFD (1<<5) /* Project quota limits
enforcement */
.fi
.EE
.in
.IP
This operation requires privilege
@ -444,7 +444,7 @@ structure, which is defined in
as follows:
.IP
.in +4n
.nf
.EX
/* All the blk units are in BBs (Basic Blocks) of
512 bytes. */
@ -490,7 +490,7 @@ struct fs_disk_quota {
int16_t d_padding3; /* Padding - for future use */
char d_padding4[8]; /* Yet more padding */
};
.fi
.EE
.in
.IP
Unprivileged users may retrieve only their own quotas;
@ -543,7 +543,7 @@ The
structure itself is defined as follows:
.IP
.in +4n
.nf
.EX
#define FS_QSTAT_VERSION 1 /* fs_quota_stat.qs_version */
struct fs_qfilestat {
@ -570,7 +570,7 @@ struct fs_quota_stat {
uint16_t qs_bwarnlimit; /* Limit for # of warnings */
uint16_t qs_iwarnlimit; /* Limit for # of warnings */
};
.fi
.EE
.in
.IP
The
@ -592,7 +592,7 @@ The
structure itself is defined as follows:
.IP
.in +4n
.nf
.EX
#define FS_QSTATV_VERSION1 1 /* fs_quota_statv.qs_version */
struct fs_qfilestatv {
@ -623,7 +623,7 @@ struct fs_quota_statv {
uint16_t qs_iwarnlimit; /* Limit for # of warnings */
uint64_t qs_pad2[8]; /* For future proofing */
};
.fi
.EE
.in
.IP
The

View File

@ -67,14 +67,14 @@ The
structure is declared as follows:
.PP
.in +4n
.nf
.EX
struct old_linux_dirent {
long d_ino; /* inode number */
off_t d_off; /* offset to this \fIold_linux_dirent\fP */
unsigned short d_reclen; /* length of this \fId_name\fP */
char d_name[NAME_MAX+1]; /* filename (null-terminated) */
}
.fi
.EE
.in
.PP
.I d_ino

View File

@ -96,12 +96,12 @@ as:
.PP
.br
.in +4n
.nf
.EX
struct iovec {
void *iov_base; /* Starting address */
size_t iov_len; /* Number of bytes to transfer */
};
.fi
.EE
.in
.PP
The
@ -381,7 +381,7 @@ The following code sample demonstrates the use of
.BR writev ():
.PP
.in +4n
.nf
.EX
char *str0 = "hello ";
char *str1 = "world\\n";
struct iovec iov[2];
@ -393,7 +393,7 @@ iov[1].iov_base = str1;
iov[1].iov_len = strlen(str1);
nwritten = writev(STDOUT_FILENO, iov, 2);
.fi
.EE
.in
.SH SEE ALSO
.BR pread (2),

View File

@ -189,7 +189,7 @@ struct sock_extended_err
};
struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);
.fi
.EE
.in
.IP
.I ee_errno
@ -340,7 +340,7 @@ struct msghdr {
size_t msg_controllen; /* ancillary data buffer len */
int msg_flags; /* flags on received message */
};
.fi
.EE
.in
.PP
The
@ -391,7 +391,7 @@ struct cmsghdr {
/* followed by
unsigned char cmsg_data[]; */
};
.fi
.EE
.in
.PP
Ancillary data should be accessed only by the macros defined in

View File

@ -72,12 +72,12 @@ structure is defined in
as:
.PP
.in +4n
.nf
.EX
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.EE
.in
.PP
The
@ -196,7 +196,7 @@ containing a random number:
.EX
.RB "$" " while true; do echo $RANDOM > /dev/udp/127.0.0.1/1234; "
.B " sleep 0.25; done"
.fi
.EE
.in
.PP
These datagrams are read by the example application, which
@ -211,7 +211,7 @@ can give the following output:
3 304
4 13514
5 28421
.fi
.EE
.in
.SS Program source
\&

View File

@ -461,12 +461,12 @@ we first create a suitable entry in the file
.IR /etc/request-key.conf .
.PP
.in +4n
.nf
.EX
$ sudo sh
# \fBecho 'create user mtk:* * /bin/keyctl instantiate %k %c %S' \\\fP
\fB> /etc/request-keys.conf\fP
# \fBexit\fP
.fi
.EE
.in
.PP
This entry specifies that when a new "user" key with the prefix
@ -499,11 +499,11 @@ Then we run the program and check the contents of
to verify that the requested key has been instantiated:
.PP
.in +4n
.nf
.EX
$ \fB./t_request_key user mtk:key1 "Payload data"\fP
$ \fBgrep \(aq2dddaf50\(aq /proc/keys\fP
2dddaf50 I--Q--- 1 perm 3f010000 1000 1000 user mtk:key1: 12
.fi
.EE
.in
.PP
For another example of the use of this program, see

View File

@ -50,12 +50,12 @@ The
structure has the following form:
.PP
.in +4n
.nf
.EX
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.PP
If

View File

@ -314,12 +314,12 @@ to determine that this (x86)
system has two cores, each with two CPUs:
.PP
.in +4n
.nf
.EX
$ \fBlscpu | grep -i 'core.*:|socket'\fP
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
.fi
.EE
.in
.PP
We then time the operation of the example program for three cases:
@ -328,7 +328,7 @@ both processes running on different CPUs on the same core;
and both processes running on different CPUs on different cores.
.PP
.in +4n
.nf
.EX
$ \fBtime \-p ./a.out 0 0 100000000\fP
real 14.75
user 3.02
@ -341,7 +341,7 @@ $ \fBtime \-p ./a.out 0 3 100000000\fP
real 7.89
user 3.29
sys 12.07
.fi
.EE
.in
.SS Program source
\&

View File

@ -96,7 +96,7 @@ the new scheduling policy and attributes for the specified thread.
This structure has the following form:
.PP
.in +4n
.nf
.EX
struct sched_attr {
u32 size; /* Size of this structure */
u32 sched_policy; /* Policy (SCHED_*) */
@ -110,7 +110,7 @@ struct sched_attr {
u64 sched_deadline;
u64 sched_period;
};
.fi
.EE
.in
.PP
The fields of this structure are as follows:

View File

@ -51,13 +51,13 @@ The scheduling parameters are specified in the
argument, which is a pointer to a structure of the following form:
.PP
.in +4n
.nf
.EX
struct sched_param {
...
int sched_priority;
...
};
.fi
.EE
.in
.PP
In the current implementation, the structure contains only one field,

View File

@ -213,26 +213,26 @@ When adding filters via
points to a filter program:
.PP
.in +4n
.nf
.EX
struct sock_fprog {
unsigned short len; /* Number of BPF instructions */
struct sock_filter *filter; /* Pointer to array of
BPF instructions */
};
.fi
.EE
.in
.PP
Each program must contain one or more BPF instructions:
.PP
.in +4n
.nf
.EX
struct sock_filter { /* Filter block */
__u16 code; /* Actual filter code */
__u8 jt; /* Jump true */
__u8 jf; /* Jump false */
__u32 k; /* Generic multiuse field */
};
.fi
.EE
.in
.PP
When executing the instructions, the BPF program operates on the
@ -247,7 +247,7 @@ addressing mode) as a (read-only)
buffer of the following form:
.PP
.in +4n
.nf
.EX
struct seccomp_data {
int nr; /* System call number */
__u32 arch; /* AUDIT_ARCH_* value
@ -255,7 +255,7 @@ struct seccomp_data {
__u64 instruction_pointer; /* CPU instruction pointer */
__u64 args[6]; /* Up to 6 system call arguments */
};
.fi
.EE
.in
.PP
Because numbering of system calls varies between architectures and
@ -664,14 +664,14 @@ and then construct a shell function that looks up system call
numbers on this architecture:
.PP
.in +4n
.nf
.EX
$ \fBuname -m\fP
x86_64
$ \fBsyscall_nr() {
cat /usr/src/linux/arch/x86/syscalls/syscall_64.tbl | \\
awk '$2 != "x32" && $3 == "'$1'" { print $1 }'
}\fP
.fi
.EE
.in
.PP
When the BPF filter rejects a system call (case [2] above),
@ -680,10 +680,10 @@ specified on the command line.
In the experiments shown here, we'll use error number 99:
.PP
.in +4n
.nf
.EX
$ \fBerrno 99\fP
EADDRNOTAVAIL 99 Cannot assign requested address
.fi
.EE
.in
.PP
In the following example, we attempt to run the command
@ -693,7 +693,7 @@ but the BPF filter rejects the
system call, so that the command is not even executed:
.PP
.in +4n
.nf
.EX
$ \fBsyscall_nr execve\fP
59
$ \fB./a.out\fP
@ -702,7 +702,7 @@ Hint for <arch>: AUDIT_ARCH_I386: 0x40000003
AUDIT_ARCH_X86_64: 0xC000003E
$ \fB./a.out 59 0xC000003E 99 /bin/whoami\fP
execv: Cannot assign requested address
.fi
.EE
.in
.PP
In the next example, the BPF filter rejects the
@ -712,11 +712,11 @@ system call, so that, although it is successfully started, the
command is not able to write output:
.PP
.in +4n
.nf
.EX
$ \fBsyscall_nr write\fP
1
$ \fB./a.out 1 0xC000003E 99 /bin/whoami\fP
.fi
.EE
.in
.PP
In the final example,
@ -725,12 +725,12 @@ the BPF filter rejects a system call that is not used by the
command, so it is able to successfully execute and produce output:
.PP
.in +4n
.nf
.EX
$ \fBsyscall_nr preadv\fP
295
$ \fB./a.out 295 0xC000003E 99 /bin/whoami\fP
cecilia
.fi
.EE
.in
.SS Program source
.EX

View File

@ -262,23 +262,23 @@ The time structures involved are defined in
and look like
.PP
.in +4n
.nf
.EX
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
.fi
.EE
.in
.PP
and
.PP
.in +4n
.nf
.EX
struct timespec {
long tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.PP
(However, see below on the POSIX.1 versions.)
@ -436,12 +436,12 @@ structure are typed as
The POSIX.1 situation is
.PP
.in +4n
.nf
.EX
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
.fi
.EE
.in
.PP
where the structure is defined in
@ -488,7 +488,7 @@ and the event notifications provided by
.BR epoll (7)):
.PP
.in +4n
.nf
.EX
#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP |
POLLERR)
/* Ready for reading */
@ -496,7 +496,7 @@ and the event notifications provided by
/* Ready for writing */
#define POLLEX_SET (POLLPRI)
/* Exceptional condition */
.fi
.EE
.in
.\"
.SS Multithreaded applications

View File

@ -164,12 +164,12 @@ of file descriptors at the time of the call.
The structure \fIstruct timeval\fP is defined as:
.IP
.in +4n
.nf
.EX
struct timeval {
time_t tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
.fi
.EE
.in
.TP
\fIntimeout\fP
@ -182,12 +182,12 @@ but
has nanosecond precision as follows:
.IP
.in +4n
.nf
.EX
struct timespec {
long tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.TP
\fIsigmask\fP

View File

@ -67,7 +67,7 @@ When there are four, the fourth has the type
The \fIcalling program\fP must define this union as follows:
.PP
.in +4n
.nf
.EX
union semun {
int val; /* Value for SETVAL */
struct semid_ds *buf; /* Buffer for IPC_STAT, IPC_SET */
@ -75,7 +75,7 @@ union semun {
struct seminfo *__buf; /* Buffer for IPC_INFO
(Linux-specific) */
};
.fi
.EE
.in
.PP
The
@ -90,7 +90,7 @@ struct semid_ds {
time_t sem_ctime; /* Last change time */
unsigned long sem_nsems; /* No. of semaphores in set */
};
.fi
.EE
.in
.PP
The
@ -100,7 +100,7 @@ structure is defined as follows
.BR IPC_SET ):
.PP
.in +4n
.nf
.EX
struct ipc_perm {
key_t __key; /* Key supplied to semget(2) */
uid_t \fBuid\fP; /* Effective UID of owner */
@ -110,7 +110,7 @@ struct ipc_perm {
unsigned short \fBmode\fP; /* Permissions */
unsigned short __seq; /* Sequence number */
};
.fi
.EE
.in
.PP
Valid values for

View File

@ -59,7 +59,7 @@ Each semaphore in a System\ V semaphore set
has the following associated values:
.PP
.in +4n
.nf
.EX
unsigned short semval; /* semaphore value */
unsigned short semzcnt; /* # waiting for zero */
unsigned short semncnt; /* # waiting for increase */
@ -81,11 +81,11 @@ The elements of this structure are of type
containing the following members:
.PP
.in +4n
.nf
.EX
unsigned short sem_num; /* semaphore number */
short sem_op; /* semaphore operation */
short sem_flg; /* operation flags */
.fi
.EE
.in
.PP
Flags recognized in

View File

@ -273,7 +273,7 @@ struct msghdr {
size_t msg_controllen; /* ancillary data buffer len */
int msg_flags; /* flags (unused) */
};
.fi
.EE
.in
.PP
The

View File

@ -67,12 +67,12 @@ structure is defined in
as:
.PP
.in +4n
.nf
.EX
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of bytes transmitted */
};
.fi
.EE
.in
.PP
The

View File

@ -30,7 +30,7 @@ Both of these system calls take an argument that is a pointer
to a structure of the following type:
.PP
.in +4n
.nf
.EX
struct user_desc {
unsigned int entry_number;
unsigned long base_addr;
@ -42,7 +42,7 @@ struct user_desc {
unsigned int seg_not_present:1;
unsigned int useable:1;
};
.fi
.EE
.in
.PP
.BR get_thread_area ()

View File

@ -237,7 +237,7 @@ and then both processes display the hostnames in their UTS namespaces,
so that we can see that they are different.
.PP
.in +4n
.nf
.EX
$ \fBsu\fP # Need privilege for namespace operations
Password:
# \fB./newuts bizarro &\fP
@ -247,7 +247,7 @@ uts.nodename in child: bizarro
uts.nodename in parent: antero
# \fBuname \-n\fP # Verify hostname in the shell
antero
.fi
.EE
.in
.PP
We then run the program shown below,
@ -256,11 +256,11 @@ Inside that shell, we verify that the hostname is the one
set by the child created by the first program:
.PP
.in +4n
.nf
.EX
# \fB./ns_exec /proc/3550/ns/uts /bin/bash\fP
# \fBuname \-n\fP # Executed in shell started by ns_exec
bizarro
.fi
.EE
.in
.SS Program source
.EX

View File

@ -66,7 +66,7 @@ argument is a pointer to a \fIshmid_ds\fP structure,
defined in \fI<sys/shm.h>\fP as follows:
.PP
.in +4n
.nf
.EX
struct shmid_ds {
struct ipc_perm shm_perm; /* Ownership and permissions */
size_t shm_segsz; /* Size of segment (bytes) */
@ -78,7 +78,7 @@ struct shmid_ds {
shmatt_t shm_nattch; /* No. of current attaches */
...
};
.fi
.EE
.in
.PP
The
@ -88,7 +88,7 @@ structure is defined as follows
.BR IPC_SET ):
.PP
.in +4n
.nf
.EX
struct ipc_perm {
key_t __key; /* Key supplied to shmget(2) */
uid_t \fBuid\fP; /* Effective UID of owner */
@ -99,7 +99,7 @@ struct ipc_perm {
SHM_LOCKED flags */
unsigned short __seq; /* Sequence number */
};
.fi
.EE
.in
.PP
Valid values for
@ -230,7 +230,7 @@ struct shm_info {
unsigned long swap_successes;
/* Unused since Linux 2.4 */
};
.fi
.EE
.in
.TP
.BR SHM_STAT " (Linux-specific)"

View File

@ -128,7 +128,7 @@ Thus, the above two constants are defined as:
.in +4
#define SHM_HUGE_2MB (21 << SHM_HUGE_SHIFT)
#define SHM_HUGE_1GB (30 << SHM_HUGE_SHIFT)
.fi
.EE
.in
.IP
For some additional details,

View File

@ -100,7 +100,7 @@ The
structure is defined as something like:
.PP
.in +4n
.nf
.EX
struct sigaction {
void (*sa_handler)(int);
void (*sa_sigaction)(int, siginfo_t *, void *);
@ -108,7 +108,7 @@ struct sigaction {
int sa_flags;
void (*sa_restorer)(void);
};
.fi
.EE
.in
.PP
On some architectures a union is involved: do not assign to both
@ -273,13 +273,13 @@ field.
This handler takes three arguments, as follows:
.PP
.in +4n
.nf
.EX
void
handler(int sig, siginfo_t *info, void *ucontext)
{
...
}
.fi
.EE
.in
.PP
The
@ -287,7 +287,7 @@ The
data type is a structure with the following fields:
.PP
.in +4n
.nf
.EX
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
@ -330,7 +330,7 @@ siginfo_t {
unsigned int si_arch; /* Architecture of attempted system call
(since Linux 3.5) */
}
.fi
.EE
.in
.PP
.IR si_signo ", " si_errno " and " si_code

View File

@ -90,13 +90,13 @@ The
type used to type the arguments of this function is defined as follows:
.PP
.in +4n
.nf
.EX
typedef struct {
void *ss_sp; /* Base address of stack */
int ss_flags; /* Flags */
size_t ss_size; /* Number of bytes in stack */
} stack_t;
.fi
.EE
.in
.PP
To establish a new alternate signal stack,
@ -246,7 +246,7 @@ The following code segment demonstrates the use of
.BR sigaltstack ():
.PP
.in +4n
.nf
.EX
stack_t ss;
ss.ss_sp = malloc(SIGSTKSZ);
@ -256,7 +256,7 @@ ss.ss_size = SIGSTKSZ;
ss.ss_flags = 0;
if (sigaltstack(&ss, NULL) == \-1)
/* Handle error */;
.fi
.EE
.in
.SH BUGS
In the lead up to the development of the Linux 2.4 kernel,

View File

@ -165,9 +165,9 @@ Without use of such a type, the declaration of
is the somewhat harder to read:
.PP
.in +4n
.nf
.EX
.BI "void ( *" signal "(int " signum ", void (*" handler ")(int)) ) (int);"
.fi
.EE
.in
.SS Portability
The only portable use of

View File

@ -88,12 +88,12 @@ may overrun by a small amount.)
This argument is of the following type:
.PP
.in +4n
.nf
.EX
struct timespec {
long tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
}
.fi
.EE
.in
.PP
If both fields of this structure are specified as 0, a poll is performed:

View File

@ -136,7 +136,7 @@ All of these system calls return a
structure, which contains the following fields:
.PP
.in +4n
.nf
.EX
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* Inode number */
@ -161,7 +161,7 @@ struct stat {
#define st_mtime st_mtim.tv_sec
#define st_ctime st_ctim.tv_sec
};
.fi
.EE
.in
.PP
.IR Note :

View File

@ -46,7 +46,7 @@ is a pointer to a
structure defined approximately as follows:
.PP
.in +4n
.nf
.EX
struct statfs {
__fsword_t f_type; /* Type of filesystem (see below) */
__fsword_t f_bsize; /* Optimal transfer block size */
@ -150,7 +150,7 @@ Filesystem types:
XENIX_SUPER_MAGIC 0x012ff7b4
XFS_SUPER_MAGIC 0x58465342
_XIAFS_SUPER_MAGIC 0x012fd16d
.fi
.EE
.in
.PP
Most of these MAGIC constants are defined in

View File

@ -54,7 +54,7 @@ pointed to by
The returned buffer is a structure of the following type:
.PP
.in +4n
.nf
.EX
struct statx {
__u32 stx_mask; /* Mask of bits indicating
filled fields */
@ -87,18 +87,18 @@ struct statx {
__u32 stx_dev_major; /* Major ID */
__u32 stx_dev_minor; /* Minor ID */
};
.fi
.EE
.in
.PP
The file timestamps are structures of the following type:
.PP
.in +4n
.nf
.EX
struct statx_timestamp {
__s64 tv_sec; /* Seconds since the Epoch (UNIX time) */
__u32 tv_nsec; /* Nanoseconds since tv_sec */
};
.fi
.EE
.in
.PP
(Note that reserved space and padding is omitted.)

View File

@ -197,10 +197,10 @@ Therefore, these architectures define a different
system call that orders the arguments suitably:
.PP
.in +4n
.nf
.EX
.BI "int sync_file_range2(int " fd ", unsigned int " flags ,
.BI " off64_t " offset ", off64_t " nbytes );
.fi
.EE
.in
.PP
The behavior of this system call is otherwise exactly the same as

View File

@ -106,12 +106,12 @@ system call would be invoked as follows on the ARM architecture with the EABI
in little endian mode:
.PP
.in +4n
.nf
.EX
syscall(SYS_readahead, fd, 0,
(unsigned int) (offset & 0xFFFFFFFF),
(unsigned int) (offset >> 32),
count);
.fi
.EE
.in
.PP
Since the offset argument is 64 bits, and the first argument

View File

@ -53,7 +53,7 @@ or the maximum number of open files.
The argument has the form
.PP
.in +4n
.nf
.EX
struct __sysctl_args {
int *name; /* integer vector describing variable */
int nlen; /* length of this vector */
@ -63,7 +63,7 @@ struct __sysctl_args {
void *newval; /* 0 or address of new value */
size_t newlen; /* size of new value */
};
.fi
.EE
.in
.PP
This call does a search in a tree structure, possibly resembling

View File

@ -49,7 +49,7 @@ Until Linux 2.3.16,
returned information in the following structure:
.PP
.in +4n
.nf
.EX
struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
@ -62,7 +62,7 @@ struct sysinfo {
unsigned short procs; /* Number of current processes */
char _f[22]; /* Pads structure to 64 bytes */
};
.fi
.EE
.in
.PP
In the above structure, the sizes of the memory and swap fields
@ -72,7 +72,7 @@ Since Linux 2.3.23 (i386) and Linux 2.3.48
(all architectures) the structure is:
.PP
.in +4n
.nf
.EX
struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
@ -89,7 +89,7 @@ struct sysinfo {
char _f[20\-2*sizeof(long)\-sizeof(int)];
/* Padding to 64 bytes */
};
.fi
.EE
.in
.PP
In the above structure,

View File

@ -140,12 +140,12 @@ system call.
Here is an example of its use:
.PP
.in +4n
.nf
.EX
$ \fBdate |./a.out out.log | cat\fP
Tue Oct 28 10:06:00 CET 2014
$ \fBcat out.log\fP
Tue Oct 28 10:06:00 CET 2014
.fi
.EE
.in
.SS Program source
.EX

View File

@ -343,7 +343,7 @@ Unblocking signal 34
Caught signal 34
sival_ptr = 0xbfb174f4; *sival_ptr = 0x804c008
overrun count = 10004886
.fi
.EE
.in
.SS Program source
\&

View File

@ -62,7 +62,7 @@ The
structure is defined as follows:
.PP
.in +4n
.nf
.EX
struct timespec {
time_t tv_sec; /* Seconds */
long tv_nsec; /* Nanoseconds */
@ -72,7 +72,7 @@ struct itimerspec {
struct timespec it_interval; /* Timer interval */
struct timespec it_value; /* Initial expiration */
};
.fi
.EE
.in
.PP
Each of the substructures of the

View File

@ -164,7 +164,7 @@ struct itimerspec {
struct timespec it_interval; /* Interval for periodic timer */
struct timespec it_value; /* Initial expiration */
};
.fi
.EE
.in
.PP
.I new_value.it_value
@ -497,7 +497,7 @@ a.out 3 1 100
10.000: read: 1; total=8
11.000: read: 1; total=9
.BR "^C " " # type control-C to suspend the program"
.fi
.EE
.in
.SS Program source
\&

View File

@ -411,7 +411,7 @@ $ \fBsudo ./unshare -m /bin/bash\fP
[sudo] password for cecilia:
# \fBreadlink /proc/$$/ns/mnt\fP
mnt:[4026532325]
.fi
.EE
.in
.PP
The differing output of the two

View File

@ -196,7 +196,7 @@ structures, each of which describes a page-fault event
or an event required for the non-cooperative userfaultfd usage:
.PP
.in +4n
.nf
.EX
struct uffd_msg {
__u8 event; /* Type of event */
...
@ -226,7 +226,7 @@ struct uffd_msg {
/* Padding fields omitted */
} __packed;
.fi
.EE
.in
.PP
If multiple events are available and the supplied buffer is large enough,
@ -482,7 +482,7 @@ operation.
The following is an example of what we see when running the program:
.PP
.in +4n
.nf
.EX
$ \fB./userfaultfd_demo 3\fP
Address returned by mmap() = 0x7fd30106c000
@ -512,7 +512,7 @@ Read address 0x7fd30106e00f in main(): C
Read address 0x7fd30106e40f in main(): C
Read address 0x7fd30106e80f in main(): C
Read address 0x7fd30106ec0f in main(): C
.fi
.EE
.in
.SS Program source
\&

View File

@ -58,7 +58,7 @@ daddr_t f_tfree; /* Total free blocks */
ino_t f_tinode; /* Number of free inodes */
char f_fname[6]; /* Filsys name */
char f_fpack[6]; /* Filsys pack name */
.fi
.EE
.in
.PP
The last two fields,

View File

@ -76,12 +76,12 @@ The
structure is:
.PP
.in +4n
.nf
.EX
struct utimbuf {
time_t actime; /* access time */
time_t modtime; /* modification time */
};
.fi
.EE
.in
.PP
The
@ -103,12 +103,12 @@ The
structure is:
.PP
.in +4n
.nf
.EX
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
.fi
.EE
.in
.PP
.IR times [0]

View File

@ -105,7 +105,7 @@ struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
.fi
.EE
.in
.PP
Updated file timestamps are set to the greatest value

View File

@ -63,12 +63,12 @@ structures as defined in
.IR <sys/uio.h> :
.PP
.in +4n
.nf
.EX
struct iovec {
void *iov_base; /* Starting address */
size_t iov_len; /* Number of bytes */
};
.fi
.EE
.in
.PP
The

View File

@ -615,7 +615,7 @@ continued
killed by signal 15
[1]+ Done ./a.out
$
.fi
.EE
.in
.SS Program source
\&

View File

@ -58,7 +58,7 @@ struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
.fi
.EE
.in
.PP
If the adjustment in

View File

@ -48,7 +48,7 @@ The tuning information is provided in the buffer pointed to by the argument
This buffer is a structure of the following form:
.PP
.in +4n
.nf
.EX
struct aioinit {
int aio_threads; /* Maximum number of threads */
int aio_num; /* Number of expected simultaneous
@ -61,7 +61,7 @@ struct aioinit {
terminates (since glibc 2.2) */
int aio_reserved;
};
.fi
.EE
.in
.PP
The following fields are used in the

View File

@ -201,7 +201,7 @@ backtrace() returned 8 addresses
\&./prog(main+0x65) [0x80488fb]
\&/lib/libc.so.6(__libc_start_main+0xdc) [0xb7e38f9c]
\&./prog [0x8048711]
.fi
.EE
.in
.SS Program source
\&

View File

@ -180,7 +180,7 @@ did not correctly handle pathnames with trailing \(aq/\(aq characters,
and generated a segfault if given a NULL argument.
.SH EXAMPLE
.in +4n
.nf
.EX
char *dirc, *basec, *bname, *dname;
char *path = "/etc/passwd";
@ -189,7 +189,7 @@ basec = strdup(path);
dname = dirname(dirc);
bname = basename(basec);
printf("dirname=%s, basename=%s\\n", dname, bname);
.fi
.EE
.in
.SH SEE ALSO
.BR basename (1),

View File

@ -48,10 +48,10 @@ its command-line argument.
The following shell session demonstrates the use of the program:
.PP
.in +4n
.nf
.EX
$ \fB./a.out 0x0123456789abcdef\fP
0x123456789abcdef ==> 0xefcdab8967452301
.fi
.EE
.in
.SS Program source
\&

View File

@ -81,7 +81,7 @@ typedef struct {
size_t (*prefix)(const DBT *key1, const DBT *key2);
int lorder;
} BTREEINFO;
.fi
.EE
.in
.PP
The elements of this structure are as follows:

View File

@ -121,7 +121,7 @@ An example run is the following:
.EX
.RB "$" " ./a.out 1" " # Show CPU clock of init process"
CPU-time clock for PID 1 is 2.213466748 seconds
.fi
.EE
.in
.SS Program source
\&

View File

@ -166,7 +166,7 @@ This code looks for the
option in a received ancillary buffer:
.PP
.in +4n
.nf
.EX
struct msghdr msgh;
struct cmsghdr *cmsg;
int *ttlptr;
@ -187,7 +187,7 @@ for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL;
if (cmsg == NULL) {
/* Error: IP_TTL not enabled or small buffer or I/O error */
}
.fi
.EE
.in
.PP
The code below passes an array of file descriptors over a
@ -195,7 +195,7 @@ UNIX domain socket using
.BR SCM_RIGHTS :
.PP
.in +4n
.nf
.EX
struct msghdr msg = { 0 };
struct cmsghdr *cmsg;
int myfds[NUM_FD]; /* Contains the file descriptors to pass */
@ -221,7 +221,7 @@ cmsg\->cmsg_type = SCM_RIGHTS;
cmsg\->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD);
fdptr = (int *) CMSG_DATA(cmsg); /* Initialize the payload */
memcpy(fdptr, myfds, NUM_FD * sizeof(int));
.fi
.EE
.in
.SH SEE ALSO
.BR recvmsg (2),

View File

@ -155,7 +155,7 @@ pathbuf = malloc(n);
if (pathbuf == NULL)
abort();
confstr(_CS_PATH, pathbuf, n);
.fi
.EE
.in
.SH SEE ALSO
.BR getconf (1),

View File

@ -153,7 +153,7 @@ include file, and contains at
least the following fields:
.PP
.in +4n
.nf
.EX
typedef struct {
DBTYPE type;
int (*close)(const DB *db);
@ -167,7 +167,7 @@ typedef struct {
int (*seq)(const DB *db, DBT *key, DBT *data,
unsigned int flags);
} DB;
.fi
.EE
.in
.PP
These elements describe a database type and a set of functions performing
@ -460,7 +460,7 @@ typedef struct {
void *data;
size_t size;
} DBT;
.fi
.EE
.in
.PP
The elements of the

View File

@ -74,7 +74,7 @@ The
argument is a structure of the following type:
.PP
.in +4n
.nf
.EX
struct dl_phdr_info {
ElfW(Addr) dlpi_addr; /* Base address of object */
const char *dlpi_name; /* (Null-terminated) name of
@ -104,7 +104,7 @@ struct dl_phdr_info {
one and it has been allocated in the calling
thread, otherwise a null pointer */
};
.fi
.EE
.in
.PP
(The
@ -159,7 +159,7 @@ typedef struct {
Elf32_Word p_flags; /* Segment flags */
Elf32_Word p_align; /* Segment alignment */
} Elf32_Phdr;
.fi
.EE
.in
.PP
Note that we can calculate the location of a particular program header,
@ -177,7 +177,7 @@ include the following (see
for further details):
.PP
.in +4n
.nf
.EX
#define PT_LOAD 1 /* Loadable program segment */
#define PT_DYNAMIC 2 /* Dynamic linking information */
#define PT_INTERP 3 /* Program interpreter */
@ -189,7 +189,7 @@ for further details):
#define PT_GNU_STACK 0x6474e551 /* Indicates stack executability */
.\" For PT_GNU_STACK, see http://www.airs.com/blog/archives/518
#define PT_GNU_RELRO 0x6474e552 /* Read-only after relocation */
.fi
.EE
.in
.SH RETURN VALUE
The
@ -254,7 +254,7 @@ The first shared object for which output is displayed
(where the name is an empty string)
is the main program.
.in +4n
.nf
.EX
$ \fB./a.out\fP
Name: "" (9 segments)
0: [ 0x400040; memsz: 1f8] flags: 0x5; PT_PHDR
@ -290,7 +290,7 @@ Name: "/lib64/ld-linux-x86-64.so.2" (7 segments)
4: [0x7f55716acec4; memsz: 604] flags: 0x4; PT_GNU_EH_FRAME
5: [0x7f557168f000; memsz: 0] flags: 0x6; PT_GNU_STACK
6: [0x7f55718afba0; memsz: 460] flags: 0x4; PT_GNU_RELRO
.fi
.EE
.in
.PP
.SS Program source

View File

@ -54,7 +54,7 @@ This information is returned in a
structure:
.PP
.in +4n
.nf
.EX
typedef struct {
const char *dli_fname; /* Pathname of shared object that
contains address */
@ -65,7 +65,7 @@ typedef struct {
void *dli_saddr; /* Exact address of symbol named
in \fIdli_sname\fP */
} Dl_info;
.fi
.EE
.in
.PP
If no symbol matching
@ -99,7 +99,7 @@ defined in
as:
.IP
.in +4n
.nf
.EX
struct link_map {
ElfW(Addr) l_addr; /* Difference between the
address in the ELF file and
@ -114,7 +114,7 @@ struct link_map {
/* Plus additional fields private to the
implementation */
};
.fi
.EE
.in
.TP
.B RTLD_DL_SYMENT
@ -136,7 +136,7 @@ which is defined in
as:
.IP
.in +4n
.nf
.EX
typedef struct {
Elf64_Word st_name; /* Symbol name */
unsigned char st_info; /* Symbol type and binding */
@ -145,7 +145,7 @@ typedef struct {
Elf64_Addr st_value; /* Symbol value */
Elf64_Xword st_size; /* Symbol size */
} Elf64_Sym;
.fi
.EE
.in
.IP
The

View File

@ -80,7 +80,7 @@ structure, defined in
as:
.IP
.in +4n
.nf
.EX
struct link_map {
ElfW(Addr) l_addr; /* Difference between the
address in the ELF file and
@ -95,7 +95,7 @@ struct link_map {
/* Plus additional fields private to the
implementation */
};
.fi
.EE
.in
.TP
.BR RTLD_DI_ORIGIN " (\fIchar *\fP)"
@ -156,7 +156,7 @@ The
structure is defined as follows:
.IP
.in +4n
.nf
.EX
typedef struct {
size_t dls_size; /* Size in bytes of
the whole buffer */
@ -173,14 +173,14 @@ Each of the
elements in the above structure is a structure of the following form:
.IP
.in +4n
.nf
.EX
typedef struct {
char *dls_name; /* Name of library search
path directory */
unsigned int dls_flags; /* Indicates where this
directory came from */
} Dl_serpath;
.fi
.EE
.in
.IP
The
@ -252,11 +252,11 @@ requests to obtain the library search path list for the library.
Here is an example of what we might see when running the program:
.PP
.in +4n
.nf
.EX
$ \fB./a.out /lib64/libm.so.6\fP
dls_serpath[0].dls_name = /lib64
dls_serpath[1].dls_name = /usr/lib64
.fi
.EE
.in
.SS Program source
\&

View File

@ -521,11 +521,11 @@ function, and prints the cosine of 2.0.
The following is an example of building and running the program:
.PP
.in +4n
.nf
.EX
$ \fBcc dlopen_demo.c \-ldl\fP
$ \fB./a.out\fP
\-0.416147
.fi
.EE
.in
.SS Program source
.EX

View File

@ -131,7 +131,7 @@ An example of its use is the following:
.EX
$ \fB./a.out abc\fP
ABC
.fi
.EE
.in
.SS Program source
.EX

View File

@ -102,7 +102,7 @@ struct crypt_data {
int direction;
int initialized;
};
.fi
.EE
.in
.PP
Before calling

View File

@ -83,7 +83,7 @@ First address past:
program text (etext) 0x8048568
initialized data (edata) 0x804a01c
uninitialized data (end) 0x804a024
.fi
.EE
.in
.SS Program source
\&

View File

@ -141,7 +141,7 @@ $ \fB./a.out\fP
x.u32 = 0x44332211
htole32(x.u32) = 0x44332211
htobe32(x.u32) = 0x11223344
.fi
.EE
.in
.SS Program source
\&

View File

@ -151,7 +151,7 @@ if (p == NULL)
fd = open(file_name, O_RDONLY, 0);
if (fd == \-1)
err(1, "%s", file_name);
.fi
.EE
.in
.PP
Display an error message and exit:
@ -160,7 +160,7 @@ Display an error message and exit:
.EX
if (tm.tm_hour < START_TIME)
errx(1, "too early, wait until %s", start_time_string);
.fi
.EE
.in
.PP
Warn of an error:
@ -174,7 +174,7 @@ if (fd == \-1)
fd = open(block_device, O_RDONLY, 0);
if (fd == \-1)
err(1, "%s", block_device);
.fi
.EE
.in
.SH SEE ALSO
.BR error (3),

View File

@ -535,7 +535,7 @@ if (somecall() == \-1) {
printf("somecall() failed\en");
if (errsv == ...) { ... }
}
.fi
.EE
.in
.PP
It was common in traditional C to declare

View File

@ -118,11 +118,11 @@ is defined in
as:
.PP
.in +4n
.nf
.EX
struct ether_addr {
uint8_t ether_addr_octet[6];
}
.fi
.EE
.in
.SH ATTRIBUTES
For an explanation of the terms used in this section, see

View File

@ -67,7 +67,7 @@ must have the same format as
The \fIgroup\fP structure is defined in \fI<grp.h>\fP as follows:
.PP
.in +4n
.nf
.EX
struct group {
char *gr_name; /* group name */
char *gr_passwd; /* group password */
@ -75,7 +75,7 @@ struct group {
char **gr_mem; /* NULL-terminated array of pointers
to names of group members */
};
.fi
.EE
.in
.SH RETURN VALUE
The

View File

@ -69,7 +69,7 @@ must have the same format as
The \fIpasswd\fP structure is defined in \fI<pwd.h>\fP as follows:
.PP
.in +4n
.nf
.EX
struct passwd {
char *pw_name; /* username */
char *pw_passwd; /* user password */
@ -79,7 +79,7 @@ struct passwd {
char *pw_dir; /* home directory */
char *pw_shell; /* shell program */
};
.fi
.EE
.in
.SH RETURN VALUE
The

View File

@ -293,7 +293,7 @@ An example of the output produced by this program is the following:
.EX
.RB "$" " ./a.out \(aq1 23 43\(aq"
size=11; ptr=1 529 1849
.fi
.EE
.in
.SS Program source
\&

View File

@ -124,12 +124,12 @@ SVr4, 4.3BSD, C89.
The program below produces results such as the following:
.PP
.in +4n
.nf
.EX
.RB "$" " ./a.out 2560"
frexp(2560, &e) = 0.625: 0.625 * 2^12 = 2560
.RB "$" " ./a.out \-4"
frexp(\-4, &e) = \-0.5: \-0.5 * 2^3 = \-4
.fi
.EE
.in
.SS Program source
\&

View File

@ -42,14 +42,14 @@ The time is returned in
which is declared as follows:
.PP
.in +4n
.nf
.EX
struct timeb {
time_t time;
unsigned short millitm;
short timezone;
short dstflag;
};
.fi
.EE
.in
.PP
Here \fItime\fP is the number of seconds since the Epoch,

View File

@ -136,7 +136,7 @@ typedef struct _ftsent {
.\" u_short fts_flags; /* private flags for FTSENT structure */
.\" u_short fts_instr; /* fts_set() instructions */
} FTSENT;
.fi
.EE
.in
.PP
These fields are defined as follows:

View File

@ -105,7 +105,7 @@ structure used by
contains the following fields:
.PP
.in +4n
.nf
.EX
struct addrinfo {
int ai_flags;
int ai_family;
@ -116,7 +116,7 @@ struct addrinfo {
char *ai_canonname;
struct addrinfo *ai_next;
};
.fi
.EE
.in
.PP
The

View File

@ -88,14 +88,14 @@ Each request is described by a
structure, defined as follows:
.PP
.in +4n
.nf
.EX
struct gaicb {
const char *ar_name;
const char *ar_service;
const struct addrinfo *ar_request;
struct addrinfo *ar_result;
};
.fi
.EE
.in
.PP
The elements of this structure correspond to the arguments of
@ -344,7 +344,7 @@ $ \fB./a.out ftp.us.kernel.org enoent.linuxfoundation.org gnu.cz\fP
ftp.us.kernel.org: 128.30.2.36
enoent.linuxfoundation.org: Name or service not known
gnu.cz: 87.236.197.13
.fi
.EE
.in
.PP
Here is the program source code
@ -433,7 +433,7 @@ $ \fB./a.out\fP
[00] ftp.us.kernel.org: 216.165.129.139
[01] enoent.linuxfoundation.org: Name or service not known
[02] gnu.cz: 87.236.197.13
.fi
.EE
.in
.PP
The program source is as follows:

View File

@ -237,7 +237,7 @@ structure.
The following shell session demonstrates the operation of the program:
.PP
.in +4n
.nf
.EX
.RB "$" " TFILE=$PWD/tfile"
.RB "$" " echo \(aq%A\(aq > $TFILE " " # Full name of the day of the week"
.RB "$" " echo \(aq%T\(aq >> $TFILE" " # ISO date (YYYY-MM-DD)"
@ -276,7 +276,7 @@ Call 3 ("12:22:33") succeeded:
tm_wday = 0
tm_yday = 250
tm_isdst = 1
.fi
.EE
.in
.SS Program source
\&

View File

@ -47,7 +47,7 @@ The
is defined by:
.PP
.in +4n
.nf
.EX
struct fstab {
char *fs_spec; /* block device name */
char *fs_file; /* mount point */
@ -57,7 +57,7 @@ struct fstab {
int fs_freq; /* dump frequency, in days */
int fs_passno; /* pass number on parallel dump */
};
.fi
.EE
.in
.PP
Here the field

View File

@ -99,7 +99,7 @@ after all processing has been performed.
The \fIgroup\fP structure is defined in \fI<grp.h>\fP as follows:
.PP
.in +4n
.nf
.EX
struct group {
char *gr_name; /* group name */
char *gr_passwd; /* group password */
@ -107,7 +107,7 @@ struct group {
char **gr_mem; /* NULL-terminated array of pointers
to names of group members */
};
.fi
.EE
.in
.PP
For more information about the fields of this structure, see

View File

@ -70,7 +70,7 @@ The \fIgroup\fP structure is defined in
as follows:
.PP
.in +4n
.nf
.EX
struct group {
char *gr_name; /* group name */
char *gr_passwd; /* group password */
@ -78,7 +78,7 @@ struct group {
char **gr_mem; /* NULL-terminated array of pointers
to names of group members */
};
.fi
.EE
.in
.PP
For more information about the fields of this structure, see
@ -152,19 +152,19 @@ the POSIX version of functions like
Other systems use the prototype
.PP
.in +4n
.nf
.EX
struct group *getgrent_r(struct group *grp, char *buf,
int buflen);
.fi
.EE
.in
.PP
or, better,
.PP
.in +4n
.nf
.EX
int getgrent_r(struct group *grp, char *buf, int buflen,
FILE **gr_fp);
.fi
.EE
.in
.SH NOTES
The function

Some files were not shown because too many files have changed in this diff Show More