Jan Kara :
> On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote:
>> As for "who (user/process/...) did what", the fanotify API is flawed
>> in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run
>> process is long gone by the time we receive the eve
Filip Štědronský :
> there are basically two classes of uses for a fantotify-like
> interface:
>
> (1) Keeping an up-to-date representation of the file system. For this,
> superblock watches are clearly what you want.
>
> [...]
>
> All those factors speak greatly in favour of superbloc
Amir Goldstein :
> On the Oct 10 posting you asked me about the use case and it was hard
> to explain the use case with only part of the work done.
>
> The issue, which this work sets to solve, is the poor scalability of
> recursive inotify watches.
On my [employer's] part, the fanotify API suffe
If I call fanotify_mark(... FAN_MARK_ADD | FAN_MARK_MOUNT ...), I get
notifications on all files on the file system.
Except I don't.
If a process has mounted directories on the file system in a different
namespace, the global namespace experiences file system events but no
fanotify events are ge
the explicit
rearming would be in the clock event device (the periodic notifications
can probably be optimized effectively).
You are right. By calling set_next_event() in every callback I can
implement what I want (provided that the API guarantees that the
absolute time can be in the past).
Marko
--
Thomas Gleixner <[EMAIL PROTECTED]>:
> On Thu, 2007-03-01 at 18:34 -0800, Marko Rauhamaa wrote:
> > It would appear the new clockevent API has a one-nanosecond
> > resolution. It certainly looks sufficiently fine-grained, but I'm
> > afraid it's too coarse
)
For our needs, we have built our own "clockevent" system that has a
nominal one-femtosecond precision. The nanosecond resolution would be
sufficient if there was a way to "nudge" the next interrupt by a
nanosecond from the interrupt handler.
Marko
--
Marko Rauhamaa mai
7 matches
Mail list logo
