diff options
| author | Alejandro Colomar <alx@kernel.org> | 2023-03-17 17:08:01 +0100 |
|---|---|---|
| committer | Alejandro Colomar <alx@kernel.org> | 2023-03-30 15:14:55 +0200 |
| commit | 4131356cdab8d37fc395ca5466a0401c8573380c (patch) | |
| tree | 8c4c6f1c3172358b735b481cbbfdd9cc04b00ed9 /man2/open.2 | |
| parent | fd00f831b52d61a91d59cb3b46182869145d9700 (diff) | |
| download | man-pages-4131356cdab8.tar.gz | |
man*/, man-pages.7: VERSIONS, STANDARDS, HISTORY: Reorganize sections
- Add a new HISTORY section that covers the history of an API, both
regarding implementations and regarding old standards. This was
previously covered in VERSIONS, and in some cases in STANDARDS.
- Repurpose VERSIONS to cover differing implementations in _current_
systems.
- STANDARDS is reduced to only cover current versions of standards.
That basically means only C11 (C99 has been superseeded by C11; C17
is just a bugfix of C11, so not really a new version), and
POSIX.1-2008 (*-2001 was superseeded by *-2008; *-2017 was just a
bugfix for *-2008). The section also mentions for example 'Linux',
'GNU' or 'BSD' when a non-standard API is Linux- or GNU-only or if
it's (de-facto) standard in the BSDs.
- In some cases content that should go into one of these sections was
in NOTES. Move it from there to where it corresponds.
- In the SYNOPSIS, I added [[deprecated]] in some functions that I
found are deprecated by the relevant standards.
- A few other related changes...
Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Diffstat (limited to 'man2/open.2')
| -rw-r--r-- | man2/open.2 | 268 |
1 files changed, 132 insertions, 136 deletions
diff --git a/man2/open.2 b/man2/open.2 index aefcae1e60..d9386c48fb 100644 --- a/man2/open.2 +++ b/man2/open.2 @@ -1285,19 +1285,133 @@ flag was specified, and an incompatible lease was held on the file (see .BR fcntl (2)). .SH VERSIONS +The (undefined) effect of +.B O_RDONLY | O_TRUNC +varies among implementations. +On many systems the file is actually truncated. +.\" Linux 2.0, 2.5: truncate +.\" Solaris 5.7, 5.8: truncate +.\" Irix 6.5: truncate +.\" Tru64 5.1B: truncate +.\" HP-UX 11.22: truncate +.\" FreeBSD 4.7: truncate +.SS Synchronized I/O +The POSIX.1-2008 "synchronized I/O" option +specifies different variants of synchronized I/O, +and specifies the +.BR open () +flags +.BR O_SYNC , +.BR O_DSYNC , +and +.B O_RSYNC +for controlling the behavior. +Regardless of whether an implementation supports this option, +it must at least support the use of +.B O_SYNC +for regular files. +.PP +Linux implements +.B O_SYNC +and +.BR O_DSYNC , +but not +.BR O_RSYNC . +Somewhat incorrectly, glibc defines +.B O_RSYNC +to have the same value as +.BR O_SYNC . +.RB ( O_RSYNC +is defined in the Linux header file +.I <asm/fcntl.h> +on HP PA-RISC, but it is not used.) +.PP +.B O_SYNC +provides synchronized I/O +.I file +integrity completion, +meaning write operations will flush data and all associated metadata +to the underlying hardware. +.B O_DSYNC +provides synchronized I/O +.I data +integrity completion, +meaning write operations will flush data +to the underlying hardware, +but will only flush metadata updates that are required +to allow a subsequent read operation to complete successfully. +Data integrity completion can reduce the number of disk operations +that are required for applications that don't need the guarantees +of file integrity completion. +.PP +To understand the difference between the two types of completion, +consider two pieces of file metadata: +the file last modification timestamp +.RI ( st_mtime ) +and the file length. +All write operations will update the last file modification timestamp, +but only writes that add data to the end of the +file will change the file length. +The last modification timestamp is not needed to ensure that +a read completes successfully, but the file length is. +Thus, +.B O_DSYNC +would only guarantee to flush updates to the file length metadata +(whereas +.B O_SYNC +would also always flush the last modification timestamp metadata). +.PP +Before Linux 2.6.33, Linux implemented only the +.B O_SYNC +flag for +.BR open (). +However, when that flag was specified, +most filesystems actually provided the equivalent of synchronized I/O +.I data +integrity completion (i.e., +.B O_SYNC +was actually implemented as the equivalent of +.BR O_DSYNC ). +.PP +Since Linux 2.6.33, proper +.B O_SYNC +support is provided. +However, to ensure backward binary compatibility, +.B O_DSYNC +was defined with the same value as the historical +.BR O_SYNC , +and +.B O_SYNC +was defined as a new (two-bit) flag value that includes the +.B O_DSYNC +flag value. +This ensures that applications compiled against +new headers get at least +.B O_DSYNC +semantics before Linux 2.6.33. +.\" +.SS C library/kernel differences +Since glibc 2.26, +the glibc wrapper function for +.BR open () +employs the .BR openat () -was added in Linux 2.6.16; -library support was added in glibc 2.4. +system call, rather than the kernel's +.BR open () +system call. +For certain architectures, this is also true before glibc 2.26. +.\" .SH STANDARDS -.BR open (), +.TP +.BR open () +.TQ .BR creat () -SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008. -.PP -.BR openat (): +.TQ +.BR openat () POSIX.1-2008. .PP .BR openat2 (2) -is Linux-specific. +Linux. .PP The .BR O_DIRECT , @@ -1324,17 +1438,17 @@ with a value greater than or equal to 200809L or with a value greater than or equal to 700. In glibc 2.11 and earlier, one obtains the definitions by defining .BR _GNU_SOURCE . -.PP -As noted in -.BR feature_test_macros (7), -feature test macros such as -.BR _POSIX_C_SOURCE , -.BR _XOPEN_SOURCE , -and -.B _GNU_SOURCE -must be defined before including -.I any -header files. +.SH HISTORY +.TP +.BR open () +.TQ +.BR creat () +SVr4, 4.3BSD, POSIX.1-2001. +.TP +.BR openat () +POSIX.1-2008. +Linux 2.6.16, +glibc 2.4. .SH NOTES Under Linux, the .B O_NONBLOCK @@ -1345,17 +1459,6 @@ this may be used to open a device in order to get a file descriptor for use with .BR ioctl (2). .PP -The (undefined) effect of -.B O_RDONLY | O_TRUNC -varies among implementations. -On many systems the file is actually truncated. -.\" Linux 2.0, 2.5: truncate -.\" Solaris 5.7, 5.8: truncate -.\" Irix 6.5: truncate -.\" Tru64 5.1B: truncate -.\" HP-UX 11.22: truncate -.\" FreeBSD 4.7: truncate -.PP Note that .BR open () can open device special files, but @@ -1442,113 +1545,6 @@ operation to test whether two file descriptors (in the same process or in two different processes) refer to the same open file description. .\" -.\" -.SS Synchronized I/O -The POSIX.1-2008 "synchronized I/O" option -specifies different variants of synchronized I/O, -and specifies the -.BR open () -flags -.BR O_SYNC , -.BR O_DSYNC , -and -.B O_RSYNC -for controlling the behavior. -Regardless of whether an implementation supports this option, -it must at least support the use of -.B O_SYNC -for regular files. -.PP -Linux implements -.B O_SYNC -and -.BR O_DSYNC , -but not -.BR O_RSYNC . -Somewhat incorrectly, glibc defines -.B O_RSYNC -to have the same value as -.BR O_SYNC . -.RB ( O_RSYNC -is defined in the Linux header file -.I <asm/fcntl.h> -on HP PA-RISC, but it is not used.) -.PP -.B O_SYNC -provides synchronized I/O -.I file -integrity completion, -meaning write operations will flush data and all associated metadata -to the underlying hardware. -.B O_DSYNC -provides synchronized I/O -.I data -integrity completion, -meaning write operations will flush data -to the underlying hardware, -but will only flush metadata updates that are required -to allow a subsequent read operation to complete successfully. -Data integrity completion can reduce the number of disk operations -that are required for applications that don't need the guarantees -of file integrity completion. -.PP -To understand the difference between the two types of completion, -consider two pieces of file metadata: -the file last modification timestamp -.RI ( st_mtime ) -and the file length. -All write operations will update the last file modification timestamp, -but only writes that add data to the end of the -file will change the file length. -The last modification timestamp is not needed to ensure that -a read completes successfully, but the file length is. -Thus, -.B O_DSYNC -would only guarantee to flush updates to the file length metadata -(whereas -.B O_SYNC -would also always flush the last modification timestamp metadata). -.PP -Before Linux 2.6.33, Linux implemented only the -.B O_SYNC -flag for -.BR open (). -However, when that flag was specified, -most filesystems actually provided the equivalent of synchronized I/O -.I data -integrity completion (i.e., -.B O_SYNC -was actually implemented as the equivalent of -.BR O_DSYNC ). -.PP -Since Linux 2.6.33, proper -.B O_SYNC -support is provided. -However, to ensure backward binary compatibility, -.B O_DSYNC -was defined with the same value as the historical -.BR O_SYNC , -and -.B O_SYNC -was defined as a new (two-bit) flag value that includes the -.B O_DSYNC -flag value. -This ensures that applications compiled against -new headers get at least -.B O_DSYNC -semantics before Linux 2.6.33. -.\" -.SS C library/kernel differences -Since glibc 2.26, -the glibc wrapper function for -.BR open () -employs the -.BR openat () -system call, rather than the kernel's -.BR open () -system call. -For certain architectures, this is also true before glibc 2.26. -.\" .SS NFS There are many infelicities in the protocol underlying NFS, affecting amongst others |