Re: fanotify: the fscking all notification system

[Jan Engelhardt]

On Monday 2009-06-29 22:08, Eric Paris wrote:
>
>struct fanotify_event_metadata {
>        __u32 event_len;
>        __s32 fd;
>        __u32 mask;
>        __u32 f_flags;
>        pid_t pid;
>        pid_t tgid;
>        __u64 cookie;
>}  __attribute__((packed));

Why pid_t and not s32 like the other fields are?

>3) call getsockattr on the socket to get back data about events that
>took place and to get fd's opened in your context
>[..].
>This provides information about the event including the type, the
>location of the new fd that was opened pointing to the object in
>question, and it provides information about the process which triggered
>the event.

Now the question would be whether getsockattr (meant getsockopt?)
returns data about one event or multiple events.

Why is not read() used? Sure, it is not as easy, but if you require
the size argument to read() being at least sizeof(event_metadata),
things should fit, should not they?
Using getsockopt feels like an ioctl - and they for one are
more or less discouraged in light of netlink for example.

>fanotify has two basic 'modes' directed and global.  fanotify directed
>works much like inotify in that userspace marks inodes it is interested
>in and gets events from those inodes.  fanotify global instead indicates
>that it wants everything on the system and then individually marks
>inodes that it doesn't care about.

So indexers and such only need a single fd for getting notifications
about touched files? Sounds great.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/