LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

fanotify.7: Minor fixes 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-04-25 08:05:16 +02:00
parent f75d27e6b0
commit 7ea227bdde
1 changed files with 13 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
man7/fanotify.7
View File

@ -30,7 +30,7 @@ The
API provides notification and interception of filesystem events.
Use cases include virus scanning and hierarchical storage management.
Currently, only a limited set of events is supported.
In particular there is no support for create, delete, and move events.
In particular, there is no support for create, delete, and move events.
Additional capabilities compared to the
.BR inotify (7)
@ -51,15 +51,17 @@ and
creates and initializes an fanotify notification group and returns a file
descriptor referring to it.
.PP
An fanotify notification group is an internal object of the kernel which holds
An fanotify notification group is a kernel-internal object that holds
a list of files, directories, and mount points for which events shall be
created.
.PP
For each entry in an fanotify notification group, two bit masks exist.
One mask (the mark mask) defines file activities for which an event shall be
created.
Another mask (the ignore mask) defines activities for which no event shall be
generated.
For each entry in an fanotify notification group, two bit masks exist: the
.I mark
mask and the
.I ignore
mask.
The mark mask defines file activities for which an event shall be created.
The ignore mask defines activities for which no event shall be generated.
Having these two types of masks permits a mount point or directory to be
marked for receiving events, while at the same time ignoring events for
specific objects under that mount point or directory.
@ -132,7 +134,7 @@ The return value of
.BR read (2)
is the length of the filled buffer, or \-1 in case of an error.
After a successful
.BR read(2),
.BR read (2),
the read buffer contains one or more of the following structures:
.in +4n
@ -153,11 +155,11 @@ struct fanotify_event_metadata {
.I event_len
This is the length of the data for the current event and the offset to the next
event in the buffer.
In the current implementation the value of
In the current implementation, the value of
.I event_len
is always
.BR FAN_EVENT_METADATA_LEN .
In principal the API design would allow to return variable length structures.
In principle, the API design would allow to return variable-length structures.
Therefore, and for performance reasons, it is recommended to use a larger
buffer size when reading, for example 4096 bytes.
.TP
@ -277,7 +279,7 @@ to the next metadata structure using the length indicated in the
.I event_len
field of the metadata structure and reduces the remaining length of the
buffer
.IT len .
.IR len .
.PP
For permission events, the application must
.BR write (2)