Removed trailing white space at end of lines

This commit is contained in:
Michael Kerrisk 2007-07-08 12:39:24 +00:00
parent 9ec940751d
commit e0bf91271f
17 changed files with 73 additions and 73 deletions

View File

@ -231,13 +231,13 @@ main(int argc, char *argv[])
}
uid = pwd\->pw_uid;
}
}
if (chown(argv[2], uid, \-1) == \-1) {
perror("chown");
exit(EXIT_FAILURE);
} /* if */
exit(EXIT_SUCCESS);
} /* main */
.fi

View File

@ -99,7 +99,7 @@ and its associated backing store.
Currently,
.\" 2.6.18-rc5
only shmfs/tmpfs supports this; other filesystems return file with the
error
error
.BR ENOSYS .
.\" Databases want to use this feature to drop a section of their
.\" bufferpool (shared memory segments) - without writing back to

View File

@ -59,7 +59,7 @@ setpgid, getpgid, setpgrp, getpgrp \- set/get process group
.sp
.BR "int setpgrp(void);" " /* System V version */"
.br
.BI "int setpgrp(pid_t " pid ", pid_t " pgid );
.BI "int setpgrp(pid_t " pid ", pid_t " pgid );
/* BSD version */
.sp
.in -4n
@ -108,7 +108,7 @@ is used to move a process from one process
group to another (as is done by some shells when creating pipelines),
both process groups must be part of the same session (see
.BR setsid (2)
and
and
.BR credentials (7)).
In this case,
the \fIpgid\fP specifies an existing process group to be joined and the

View File

@ -125,7 +125,7 @@ structure that will be supplied to the receiving process's
signal handler or returned by the receiving process's
.BR sigtimedwait (2)
call.
Inside the glibc
Inside the glibc
.BR sigqueue ()
wrapper, this argument,
.IR info ,

View File

@ -70,12 +70,12 @@ constant:
.B SPU_RAWIO
Allow mapping of some of the hardware registers of the SPU into user
space.
This flag requires the
This flag requires the
.B CAP_SYS_RAWIO
capability.
.PP
The new directory and files are created in the SPUFS with the
permissions set by the
permissions set by the
.I mode
argument minus those set in the process's
.BR umask (2).
@ -160,7 +160,7 @@ Note however, that
.BR spu_create ()
is meant to be used from libraries that implement a more abstract
interface to SPUs, not to be used from regular applications.
See
See
.I http://www.bsc.es/projects/deepcomputing/linuxoncell/
for the recommended libraries.
.SH BUGS

View File

@ -33,26 +33,26 @@ spu_run \- execute an spu context
", unsigned int *" event ");"
.fi
.SH DESCRIPTION
The
The
.BR spu_run ()
system call is used on PowerPC machines that implement the
Cell Broadband Engine Architecture in order to access Synergistic
system call is used on PowerPC machines that implement the
Cell Broadband Engine Architecture in order to access Synergistic
Processor Units (SPUs).
The
.I fd
argument is a file descriptor returned by
argument is a file descriptor returned by
.BR spu_create (2)
that addresses a specific SPU context.
When the context gets
scheduled to a physical SPU, it starts execution at the instruction
pointer passed in
pointer passed in
.IR npc .
Execution of SPU code happens synchronously, meaning that
Execution of SPU code happens synchronously, meaning that
.BR spu_run ()
does not return while the SPU is still running.
If there is a need
to execute SPU code in parallel with other code on either the
to execute SPU code in parallel with other code on either the
main CPU or other SPUs, a new thread of execution must be created
first, using the
.BR pthread_create (3)
@ -115,7 +115,7 @@ register.
On error it returns \-1 and sets
.I errno
to one of the error codes listed below.
The
The
.I spu_status
register value is a bit mask of status codes and
optionally a 14-bit code returned from the stop-and-signal
@ -203,7 +203,7 @@ Note however, that
.BR spu_run ()
is meant to be used from libraries that implement a more abstract
interface to SPUs, not to be used from regular applications.
See
See
.I http://www.bsc.es/projects/deepcomputing/linuxoncell/
for the recommended libraries.
.SH BUGS

View File

@ -446,7 +446,7 @@ behavior of old binaries does not change.
The glibc
.BR stat ()
wrapper function hides these details from applications,
ensuring that new applications linked against
ensuring that new applications linked against
the current library automatically use the current implementation,
and that binary compatibility is not broken for older binaries.
Similar remarks apply for
@ -455,12 +455,12 @@ and
.BR lstat (2).
.\"
.\" A note from Andries Brouwer, July 2007
.\"
.\" > Is the story not rather more complicated for some calls like
.\"
.\" > Is the story not rather more complicated for some calls like
.\" > stat(2)?
.\"
.\"
.\" Yes and no, mostly no. See /usr/include/sys/stat.h .
.\"
.\"
.\" The idea is here not so much that syscalls change, but that
.\" the definitions of struct stat and of the types dev_t and mode_t change.
.\" This means that libc (even if it does not call the kernel
@ -472,14 +472,14 @@ and
.\" uses. Each (almost each) occurrence of stat() is replaced by
.\" an occurrence of xstat() where the first parameter of xstat()
.\" is this version number _STAT_VER.
.\"
.\"
.\" Now, also the definitions used by the kernel change.
.\" But glibc copes with this in the standard way, and the
.\" struct stat as returned by the kernel is repacked into
.\" the struct stat as expected by the application.
.\" Thus, _STAT_VER and this setup cater for the application-libc
.\" interface, rather than the libc-kernel interface.
.\"
.\"
.\" (Note that the details depend on gcc being used as c compiler.)
.SH EXAMPLE
The following program calls

View File

@ -71,11 +71,11 @@ Note the following points:
Where no kernel version is indicated,
the system call appeared in kernel 2.0 or earlier.
.\" kernel 1.2 was started from a branch of 1.0.6
.\"
.\"
.\" Was kernel 2.0 started from a branch of 1.2.10?
.\" At least from the timestamps of the tarballs of
.\" of 1.2.10 and 1.3.0, that's how it looks, but in
.\" fact the diff doesn't seem very clear, the
.\" fact the diff doesn't seem very clear, the
.\" 1.3.0 .tar.bz is much bigger (2.0 MB) than the
.\" 1.2.10 .tar.bz2 (1.8 MB), and AEB points out the
.\" timestamps of some files in 1.3.0 seem to be older
@ -533,7 +533,7 @@ and similarly System V IPC calls are multiplexed through
Note the following points:
.IP * 3
Although slots are reserved for them in the system call table,
the following system calls are not implemented in the standard kernel:
the following system calls are not implemented in the standard kernel:
.BR afs_syscall (2), \" __NR_afs_syscall is 53 on Linux 2.6.22/i386
.BR break (2), \" __NR_break is 17 on Linux 2.6.22/i386
.BR ftime (2), \" __NR_ftime is 35 on Linux 2.6.22/i386
@ -567,7 +567,7 @@ The slot for
.BR phys (2)
is in use since kernel 2.1.116 for
.BR umount (2);
.BR phys (2)
.BR phys (2)
will never be implemented.
.IP *
The
@ -741,10 +741,10 @@ and similarly
.\" .IR sys_llseek ()
.\" and
.\" .IR sys_sysctl ().
.\"
.\"
.\" In kernel 2.1.81,
.\" .BR lchown (2)
.\" and
.\" and
.\" .BR chown (2)
.\" were swapped; that is,
.\" .BR lchown (2)

View File

@ -141,7 +141,7 @@ the third also uses 65 but adds the \fIdomainname\fP field.
The glibc
.BR uname ()
wrapper function hides these details from applications,
ensuring that new applications linked against
ensuring that new applications linked against
the current library automatically use the current implementation,
and that binary compatibility is not broken for older binaries.
.SH "SEE ALSO"

View File

@ -49,7 +49,7 @@ Feature Test Macro Requirements for glibc (see
.sp
.ad l
.BR copysign (),
.BR copysignf (),
.BR copysignf (),
.BR copysignl ():
_SVID_SOURCE || _BSD_SOURCE || _XOPEN_SOURCE\ >=\ 600 || _ISOC99_SOURCE; or
.I cc\ -std=c99

View File

@ -45,7 +45,7 @@ Feature Test Macro Requirements for glibc (see
.in
.sp
.BR getlogin_r ():
_REENTRANT || _POSIX_C_SOURCE\ >=\ 199506L
_REENTRANT || _POSIX_C_SOURCE\ >=\ 199506L
.br
.BR cuserid ():
_XOPEN_SOURCE

View File

@ -23,7 +23,7 @@ Feature Test Macro Requirements for glibc (see
.in
.sp
.BR nan (),
.BR nanf (),
.BR nanf (),
.BR nanl ():
_XOPEN_SOURCE\ >=\ 600 || _ISOC99_SOURCE; or
.I cc\ -std=c99

View File

@ -64,7 +64,7 @@ _SVID_SOURCE || _BSD_SOURCE || _XOPEN_SOURCE\ >=\ 500 || _ISOC99_SOURCE; or
.I cc\ -std=c99
.br
.BR drem (),
.BR dremf (),
.BR dremf (),
.BR dreml ():
_SVID_SOURCE || _BSD_SOURCE
.ad b

View File

@ -23,7 +23,7 @@ Feature Test Macro Requirements for glibc (see
.sp
.ad l
.BR significand (),
.BR significandf (),
.BR significandf (),
.BR significandl ():
_SVID_SOURCE || _BSD_SOURCE
.ad b

View File

@ -77,7 +77,7 @@ from
\fIeither\fP of the following macro
definitions must be made before including any header files:
.RS
.nf
.nf
#define _BSD_SOURCE
#define _XOPEN_SOURCE 500 /* or any value > 500 */
@ -87,7 +87,7 @@ definitions must be made before including any header files:
Alternatively, equivalent definitions can be included in the
compilation command:
.RS
.nf
.nf
cc -D_BSD_SOURCE
cc -D_XOPEN_SOURCE=500 # Or any value > 500
@ -113,7 +113,7 @@ feature test macro requirements (this example from
.fi
.RE
.PP
This format is employed in cases where only a single
This format is employed in cases where only a single
feature test macro can be used to expose the function
declaration, and that macro is not defined by default.
.SS Feature test macros understood by glibc
@ -374,18 +374,18 @@ is defined with one of the following values:
.RS 6
.IP \(bu 3
2,
if
if
.BR XOPEN_SOURCE
is defined with a value less than 500;
.IP \(bu
199506L,
if
if
.BR XOPEN_SOURCE
is defined with a value greater than or equal to 500 and less than 600;
or
.IP \(bu
200112L (199506L in glibc versions before 2.4),
if
if
.BR XOPEN_SOURCE
is undefined, or
is defined with a value greater than or equal to 600.

View File

@ -241,7 +241,7 @@ POSIX.1-2001 requires that an implementation support at least
The Linux kernel supports a range of 32 different real-time
signals, numbered 33 to 64.
However, the glibc POSIX threads implementation internally uses
two (for NPTL) or three (for LinuxThreads) real-time signals
two (for NPTL) or three (for LinuxThreads) real-time signals
(see
.BR pthreads (7)),
and adjusts the value of
@ -255,7 +255,7 @@ programs should
.IR "never refer to real-time signals using hard-coded numbers" ,
but instead should always refer to real-time signals using the notation
.BR SIGRTMIN +n,
and include suitable (run-time) checks that
and include suitable (run-time) checks that
.BR SIGRTMIN +n
does not exceed
.BR SIGRTMAX .

View File

@ -35,7 +35,7 @@ Processor Units (SPUs).
The file system provides a name space similar to POSIX shared
memory or message queues.
Users that have write permissions
on the file system can use
on the file system can use
.BR spu_create (2)
to establish SPU contexts under the spufs root directory.
@ -79,7 +79,7 @@ All files support the
and
.BR stat (2)
family of operations, but for the latter call,
the only fields of the returned
the only fields of the returned
.I stat
structure that contain reliable information are
.IR st_mode ,
@ -110,9 +110,9 @@ file are:
.RS
.TP
.BR read "(2), " pread "(2), " write "(2), " pwrite "(2), " lseek (2)
These operate as usual, with the exception that
These operate as usual, with the exception that
.BR seek "(2), " write (2)
and
and
.BR pwrite (2)
are not supported beyond the end of the file.
The file size
@ -134,10 +134,10 @@ The first SPU-to-CPU communication mailbox.
This file
is read-only and can be read in units of 32 bits.
The file can only be used in non-blocking mode and not
even
even
.BR poll (2)
will block on it.
The only possible operation on an open
The only possible operation on an open
.I mbox
file is:
.RS
@ -167,7 +167,7 @@ This file is similar to the first mailbox file, but can be read
in blocking I/O mode, thus
.BR poll (2)
and similar system calls can be used to monitor this file.
The possible operations on an open
The possible operations on an open
.I ibox
file are:
.RS
@ -198,7 +198,7 @@ When data has been read successfully, four bytes are placed in
the data buffer and the value four is returned.
.TP
.BR poll (2)
Poll on the
Poll on the
.I ibox
file returns
.I "(POLLIN | POLLRDNORM)"
@ -213,7 +213,7 @@ If the mailbox is full,
will block and
.BR poll (2)
can be used to wait for it to become empty again.
The possible operations on an open
The possible operations on an open
.I wbox
file are:
.RS
@ -241,11 +241,11 @@ descriptor has been opened without
.BR O_NONBLOCK ,
the call will
block until the SPU reads from its PPE mailbox channel.
When data has been written successfully,
When data has been written successfully,
the system call returns four as its function result.
.TP
.BR poll (2)
A poll on the
A poll on the
.I wbox
file returns
.I "(POLLOUT | POLLWRNORM)"
@ -254,14 +254,14 @@ whenever space is available for writing.
.TP
.BR /mbox_stat ", " /ibox_stat ", " /wbox_stat
These are read-only files that contain the length of the current
queue of each mailbox, i.e., how many words can be read from
queue of each mailbox, i.e., how many words can be read from
.IR mbox " or " ibox
or how many words can be written to
.I wbox
.I wbox
without blocking.
The files can be read only in four-byte units and return
a big-endian binary integer number.
The possible operations on an open
The possible operations on an open
.I *box_stat
file are:
.RS
@ -283,7 +283,7 @@ and
or written to (for
.IR wbox_stat )
the respective mailbox without blocking or getting an
.BR EAGAIN
.BR EAGAIN
error.
.RE
.TP
@ -326,29 +326,29 @@ The possible operations on one of these files are:
.BR read (2)
When the
.I count
supplied to the
supplied to the
.BR read (2)
call is shorter than the required length for the register
value plus a newline character, subsequent reads from the same
file descriptor will complete the string, regardless
of changes to the register by a running SPU task.
When a complete string has been read, all subsequent read operations
will return zero bytes and a new file descriptor needs to be opened
will return zero bytes and a new file descriptor needs to be opened
to read a new value.
.TP
.BR write (2)
A
A
.BR write (2)
operation on the file sets the register to the
operation on the file sets the register to the
value given in the string.
The string is parsed from the beginning
The string is parsed from the beginning
until the first non-numeric character or the end of the buffer.
Subsequent writes to the same file descriptor overwrite the
Subsequent writes to the same file descriptor overwrite the
previous setting.
.RE
.TP
.B /fpcr
This file provides access to the Floating Point Status and
This file provides access to the Floating Point Status and
Control Register as a four-byte file.
The operations on the
.I fpcr
@ -393,7 +393,7 @@ The value written to the signal files can
be read from the SPU through a channel read or from
host user space through the file.
After the value has been read by the SPU, it is reset to zero.
The possible operations on an open
The possible operations on an open
.I signal1
or
.I signal2
@ -423,10 +423,10 @@ returns \-1 and sets
to
.BR EINVAL .
Otherwise, a four-byte value is copied from the data buffer,
updating the value of the specified signal notification
updating the value of the specified signal notification
register.
The signal notification register will either be replaced with
the input data or will be updated to the bitwise OR operation
The signal notification register will either be replaced with
the input data or will be updated to the bitwise OR operation
of the old value and the input data, depending on the contents
of the
.IR signal1_type
@ -447,7 +447,7 @@ In mode 0 (overwrite), the hardware replaces the contents
of the signal channel with the data that is written to it.
In mode 1 (logical OR), the hardware accumulates the bits
that are subsequently written to it.
The possible operations on an open
The possible operations on an open
.I signal1_type
or
.I signal2_type
@ -465,7 +465,7 @@ will return zero bytes and a new file descriptor needs to be opened
to read the value again.
.TP
.BR write (2)
A
A
.BR write (2)
operation on the file sets the register to the
value given in the string.