[CRIU] [PATCH 03/18] fsnotify: Extend protobuf format to keep notification type and specific parameters

[Pavel Emelyanov]

On 01/11/2013 08:58 PM, Cyrill Gorcunov wrote:
> 
> fanotify requires additional parameters to be stored so we need
> to extend protobuf
> 
>  - each file entry will have a @type of the notification it hosts
> 
>  - additional parameters for fanotify_init call (global flags
>    and event flags) will be stored in optional @faglob entry
> 
>  - the watch descriptor (or mark in terms of kernel) now host
>    the @type of the notification it represent and mark flags
>    @mflags needed for fanotify objects (initially I've been
>    reusing @wd field for that but Pavel pointed that better
>    to not create mess in a sake of saving couple of bytes
>    in image)
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  protobuf/fsnotify.proto | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 

> +/*
> + * There are a couple of tricks implied to distinguish if fsnotify
> + * marks set on inode or mount point: the mount points do not
> + * have i_ino, ignored_mask, f_handle, the mount points
> + * have @type set to FANOTIFY. wd for inotify points to real
> + * file descriptor number.
> + */

I don't understand this comment. Please, describe how each field below
is used for inotify and fanotify wd-s.

message inotify_wd_entry {
        required uint32         id              = 1;
        required uint64         i_ino           = 2;
        required uint32         mask            = 3;
        required uint32         ignored_mask    = 4;
        required uint32         s_dev           = 5;
        required uint32         wd              = 6;
        required fh_entry       f_handle        = 7;
+	optional fsnotify_type	type		= 8;
+	optional uint32		mflags		= 9;
}