mirror of https://github.com/mkerrisk/man-pages
fuse.4: Remove FUSE_* constant values
No need to show the values of the FUSE_* constants, I believe. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
2949f098a3
commit
ac3c78bdde
20
man4/fuse.4
20
man4/fuse.4
|
@ -116,7 +116,7 @@ so not all messages are documented.
|
|||
For each message, first the struct sent by the kernel is given,
|
||||
followed by a description of the semantics of the message.
|
||||
.TP
|
||||
.BR FUSE_INIT " ( 25 )"
|
||||
.BR FUSE_INIT
|
||||
|
||||
.in +4n
|
||||
.nf
|
||||
|
@ -176,7 +176,7 @@ The negotiated minor version is considered to be the minimum
|
|||
of the minor versions provided by the daemon and the kernel and
|
||||
both parties should use the protocol corresponding to said minor version.
|
||||
.TP
|
||||
.BR FUSE_GETATTR " ( 3 )"
|
||||
.BR FUSE_GETATTR
|
||||
.\" FIXME It looks like this is for implementing a stat(2) type of
|
||||
.\" operation. There needs to be a sentence here describing what
|
||||
.\" this option does.
|
||||
|
@ -234,7 +234,7 @@ describe the attributes of the required file.
|
|||
For the interpretation of these fields, see
|
||||
.BR stat (2).
|
||||
.TP
|
||||
.BR FUSE_ACCESS " ( 34 )"
|
||||
.BR FUSE_ACCESS
|
||||
|
||||
.in +4n
|
||||
.nf
|
||||
|
@ -254,7 +254,7 @@ may be indicated, by setting such field to
|
|||
.\" FIXME What does "such field" mean? The 'error' field?
|
||||
.BR \-EACCES ).
|
||||
.TP
|
||||
.BR FUSE_OPEN " ( 14 ) and " FUSE_OPENDIR " ( 34 )"
|
||||
.BR FUSE_OPEN " and " FUSE_OPENDIR
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_open_in {
|
||||
|
@ -307,7 +307,7 @@ Don't invalidate the data cache on open.
|
|||
The file is not seekable.
|
||||
.RE
|
||||
.TP
|
||||
.BR FUSE_READ " ( 15 ) and " FUSE_READDIR " ( 28 )"
|
||||
.BR FUSE_READ " and " FUSE_READDIR
|
||||
.in +4n
|
||||
.nf
|
||||
|
||||
|
@ -333,7 +333,7 @@ bytes of the file or directory, starting at
|
|||
The bytes should be returned directly following the out header,
|
||||
with no further special out structure.
|
||||
.TP
|
||||
.BR FUSE_INTERRUPT " ( 36 )"
|
||||
.BR FUSE_INTERRUPT
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_interrupt_in {
|
||||
|
@ -356,7 +356,7 @@ request will be issued for a given operation.
|
|||
After issuing said operation,
|
||||
the kernel will wait uninterruptibly for completion of the indicated request.
|
||||
.TP
|
||||
.BR FUSE_LOOKUP " ( 1 )"
|
||||
.BR FUSE_LOOKUP
|
||||
Directly following the header is a filename to be looked up in the directory
|
||||
indicated by
|
||||
.IR header\->nodeid .
|
||||
|
@ -387,7 +387,7 @@ The interpretation of timeouts and
|
|||
is as for
|
||||
.BR FUSE_GETATTR .
|
||||
.TP
|
||||
.BR FUSE_FLUSH " ( 36 )"
|
||||
.BR FUSE_FLUSH
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_flush_in {
|
||||
|
@ -405,7 +405,7 @@ No reply data is expected.
|
|||
However, an empty reply message
|
||||
still needs to be issued once the flush operation is complete.
|
||||
.TP
|
||||
.BR FUSE_RELEASE " ( 18 ) and " FUSE_RELEASEDIR " ( 29 )"
|
||||
.BR FUSE_RELEASE " and " FUSE_RELEASEDIR
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_release_in {
|
||||
|
@ -430,7 +430,7 @@ There is no reply data associated with this request,
|
|||
but a reply still needs to be issued once the request has
|
||||
been completely processed.
|
||||
.TP
|
||||
.BR FUSE_STATFS " ( 17 )"
|
||||
.BR FUSE_STATFS
|
||||
This operation implements
|
||||
.BR statfs (2)
|
||||
for this filesystem.
|
||||
|
|
Loading…
Reference in New Issue