Amir Goldstein <[email protected]> wrote:

> Well I am sure that ring buffer for fanotify events would be useful, so
> seeing that David is proposing a generic notification mechanism, I wanted
> to know how that mechanism could best share infrastructure with fsnotify.
>
> But apart from that I foresee the questions from users about why the
> mount notification API and filesystem events API do not have better
> integration.
>
> The way I see it, the notification queue can serve several classes
> of notifications and fsnotify could be one of those classes
> (at least FAN_CLASS_NOTIF fits nicely to the model).

It could be done; the main thing that concerns me is that the buffer is of
limited capacity.

However, I could take this:

        struct fanotify_event_metadata {
                __u32 event_len;
                __u8 vers;
                __u8 reserved;
                __u16 metadata_len;
                __aligned_u64 mask;
                __s32 fd;
                __s32 pid;
        };

and map it to:

        struct fanotify_notification {
                struct watch_notification watch; /* WATCH_TYPE_FANOTIFY */
                __aligned_u64   mask;
                __u16           metadata_len;
                __u8            vers;
                __u8            reserved;
                __u32           reserved2;
                __s32           fd;
                __s32           pid;
        };

and some of the watch::info bit could be used:

        n->watch.info & WATCH_INFO_OVERRUN      watch queue overran
        n->watch.info & WATCH_INFO_LENGTH       event_len
        n->watch.info & WATCH_INFO_RECURSIVE    FAN_EVENT_ON_CHILD
        n->watch.info & WATCH_INFO_FLAG_0       FAN_*_PERM
        n->watch.info & WATCH_INFO_FLAG_1       FAN_Q_OVERFLOW
        n->watch.info & WATCH_INFO_FLAG_2       FAN_ON_DIR
        n->subtype                              ffs(n->mask)

Ideally, I'd dispense with metadata_len, vers, reserved* and set the version
when setting the watch.

        fanotify_watch(int watchfd, unsigned int flags, u64 *mask,
                       int dirfd, const char *pathname, unsigned int at_flags);

We might also want to extend the watch_filter to allow you to, say, filter on
the first __u64 after the watch member so that you could filter on specific
events:

        struct watch_notification_type_filter {
                __u32   type;
                __u32   info_filter;
                __u32   info_mask;
                __u32   subtype_filter[8];
                __u64   payload_mask[1];
                __u64   payload_set[1];
        };

So, in this case, it would require:

        n->mask & wf->payload_mask[0] == wf->payload_set[0]

to be true to record the message.

David

Reply via email to