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.