mirror of https://github.com/mkerrisk/man-pages
ioctl_userfaultfd.2: srcfix: Improve FIXMEs
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
b4023444af
commit
53b95540ac
|
@ -71,7 +71,7 @@ The remaining operations are
|
|||
operations.
|
||||
These operations enable the calling application to resolve page-fault
|
||||
events in a consistent way.
|
||||
.\" FIXME What does "consistent" mean?
|
||||
.\" FIXME Above: What does "consistent" mean?
|
||||
.\"
|
||||
.SS UFFDIO_API
|
||||
(Since Linux 4.3.)
|
||||
|
@ -98,7 +98,7 @@ field denotes the API version requested by the application.
|
|||
Before the call, the
|
||||
.I features
|
||||
field must be initialized to zero.
|
||||
.\" FIXME Why must the 'features' field be initialized to zero?
|
||||
.\" FIXME Above: Why must the 'features' field be initialized to zero?
|
||||
|
||||
The kernel verifies that it can support the requested API version,
|
||||
and sets the
|
||||
|
@ -115,7 +115,7 @@ The returned
|
|||
.I ioctls
|
||||
field can contain the following bits:
|
||||
.\" FIXME This user-space API seems not fully polished. Why are there
|
||||
.\" not constants defined for each of the bit-mask values listed here?
|
||||
.\" not constants defined for each of the bit-mask values listed below?
|
||||
.TP
|
||||
.B 1 << _UFFDIO_API
|
||||
The
|
||||
|
@ -131,7 +131,7 @@ operation is supported.
|
|||
The
|
||||
.B UFFDIO_UNREGISTER
|
||||
operation is supported.
|
||||
.\" FIXME Is the above description of the 'ioctls' field correct.
|
||||
.\" FIXME Is the above description of the 'ioctls' field correct?
|
||||
.\" Does more need to be said?
|
||||
.\"
|
||||
.PP
|
||||
|
@ -156,8 +156,8 @@ The API version requested in the
|
|||
field is not supported by this kernel, or the
|
||||
.I features
|
||||
field was not zero.
|
||||
.\" FIXME In this error case, the returned 'uffdio_api' structure
|
||||
.\" zeroed out. Why is this done?
|
||||
.\" FIXME In the above error case, the returned 'uffdio_api' structure
|
||||
.\" zeroed out. Why is this done? This should be explained in the manual page.
|
||||
.\"
|
||||
.SS UFFDIO_REGISTER
|
||||
(Since Linux 4.3.)
|
||||
|
@ -249,7 +249,7 @@ is zero; or these fields are otherwise invalid.
|
|||
.TP
|
||||
.B EINVAL
|
||||
There as an incompatible mapping in the specified address range.
|
||||
.\" FIXME What does "incompatible" mean?
|
||||
.\" FIXME Above: What does "incompatible" mean?
|
||||
.\"
|
||||
.SS UFFDIO_UNREGISTER
|
||||
(Since Linux 4.3.)
|
||||
|
@ -280,7 +280,7 @@ field was zero; or these fields were otherwise invalid.
|
|||
.TP
|
||||
.B EINVAL
|
||||
There as an incompatible mapping in the specified address range.
|
||||
.\" FIXME What does "incompatible" mean?
|
||||
.\" FIXME Above: What does "incompatible" mean?
|
||||
.TP
|
||||
.B EINVAL
|
||||
There was no mapping in the specified address range.
|
||||
|
@ -324,7 +324,8 @@ field is used by the kernel to return the number of bytes
|
|||
that was actually copied, or an error (a negated
|
||||
.IR errno -style
|
||||
value).
|
||||
.\" FIXME Why is the 'copy' field used to return error values?
|
||||
.\" FIXME Above: Why is the 'copy' field used to return error values?
|
||||
.\" This should be explained in the manual page.
|
||||
If the value returned in
|
||||
.I copy
|
||||
doesn't match the value that was specified in
|
||||
|
@ -411,6 +412,7 @@ that was actually zeroed,
|
|||
or an error in the same manner as
|
||||
.BR UFFDIO_COPY .
|
||||
.\" FIXME Why is the 'zeropage' field used to return error values?
|
||||
.\" This should be explained in the manual page.
|
||||
If the value returned in the
|
||||
.I zeropage
|
||||
field doesn't match the value that was specified in
|
||||
|
@ -464,7 +466,7 @@ The
|
|||
argument is a pointer to a
|
||||
.I uffdio_range
|
||||
structure (shown above) that specifies the address range.
|
||||
.\" FIXME: Need more detail here. How is this operation used?
|
||||
.\" FIXME: Need more detail here. How is the UFFDIO_WAKE operation used?
|
||||
|
||||
This
|
||||
.BR ioctl (2)
|
||||
|
|
Loading…
Reference in New Issue