From Fedora Project Wiki

No edit summary
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 12: Line 12:
** Reliable vs. non-reliable delivery: cannot allow non-privileged processes to have arbitrarily long event queues.
** 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.
* Support directory events by passing an fd to the directory.
** Allow users to get a watch descriptor (as with inotify) instead of a file descriptor if desired. (Controversial.)
* 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.