From Fedora Project Wiki

No edit summary
No edit summary
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Things that need to be fixed:
Things that need to be fixed:


* support non-root users
* 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).
* subtree notification
* Per mount point notification (general subtree notification seems too hard).
* allow users to get a wd instead of an fd if desired
** 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.

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.