Documentation/filesystems/inotify.rst

1 .. SPDX-License-Identifier: GPL-2.0
4 Inotify - A Powerful yet Simple File Change Notification System
13 	- Deleted obsoleted interface, just refer to manpages for user interface.
29    What is the design decision behind using an-fd-per-instance as opposed to
30    an fd-per-watch?
33    An fd-per-watch quickly consumes more file descriptors than are allowed,
35    select()-able.  Yes, root can bump the per-process fd limit and yes, users
38    spaces is thus sensible.  The current design is what user-space developers
41    thousand times is silly.  If we can implement user-space's preferences
42    cleanly--and we can, the idr layer makes stuff like this trivial--then we
46    item to block on, which is mapped to a single queue of events.  The single
47    fd returns all watch events and also any potential out-of-band data.  If
50    - There would be no way to get event ordering.  Events on file foo and
52      which happened first.  A single queue trivially gives you ordering.  Such
56    - We'd have to maintain n fd's and n internal queues with state,
58      queue is the data structure that makes sense.
60    - User-space developers prefer the current API.  The Beagle guys, for
64    - No way to get out of band data.
66    - 1024 is still too low.  ;-)
73    juggle more than one queue and thus more than one associated fd.  There
74    need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
75    process can easily want more than one queue.
81    The poor user-space interface is the second biggest problem with dnotify.
84    file descriptor-based one that allows basic file I/O and poll/select.