From Fedora Project Wiki

No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
Things that need to be fixed:
Things that need to be fixed:


* Ignore masks, so that events on files can be ignored until the files are modified
* Ignore masks, so that events on files can be ignored until the files are modified.
* Reliable vs. non-reliable delivery
* Support for access decisions (by privileged processes).
* Support for access decisions
* Per mount point notification (general subtree notification seems too hard).
* Per mount point notification (general subtree notification seems too hard)
** Clarify how mount point marks should propagate to new mounts from parent mounts, when creating a new bind mount, and to existing bind mounts.
** Clarify how mount point marks should propagate to new mounts from parent mounts, when creating a new bind mount, and to existing bind mounts.
* Include uid, not just pid
* Include uid, not just pid.


Probably for the next round:
Probably for the next round:
* Add a flag to turn off event merging (or make merging less aggressive) so that events will happen "in order"?
* Add a flag to turn off event merging (or make merging less aggressive) so that events will happen "in order"?
* Support non-root users (will require permission checks)
* Support non-root processes (will require permission checks).
* Support directory events by passing an fd to the directory
** Reliable vs. non-reliable delivery: cannot allow non-privileged processes to have arbitrarily long event queues.
** Allow users to get a wd instead of an fd if desired (please explain!)
* Support directory events by passing an fd to the directory.
* Think about mark propagation across directories.
* Allow users to get a watch descriptor (as with inotify) instead of a file descriptor if desired. (Controversial.)
* inotify or denotify don't generate events for deleted inodes. Deleted inodes may still be accessed via open file descriptors though, so it may make sense to continue generating fanotify events.

Latest revision as of 17:34, 26 October 2009

Things that need to be fixed:

  • Ignore masks, so that events on files can be ignored until the files are modified.
  • Support for access decisions (by privileged processes).
  • Per mount point notification (general subtree notification seems too hard).
    • Clarify how mount point marks should propagate to new mounts from parent mounts, when creating a new bind mount, and to existing bind mounts.
  • Include uid, not just pid.

Probably for the next round:

  • Add a flag to turn off event merging (or make merging less aggressive) so that events will happen "in order"?
  • Support non-root processes (will require permission checks).
    • Reliable vs. non-reliable delivery: cannot allow non-privileged processes to have arbitrarily long event queues.
  • Support directory events by passing an fd to the directory.
  • Think about mark propagation across directories.
  • Allow users to get a watch descriptor (as with inotify) instead of a file descriptor if desired. (Controversial.)
  • inotify or denotify don't generate events for deleted inodes. Deleted inodes may still be accessed via open file descriptors though, so it may make sense to continue generating fanotify events.