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

[Pavel Emelyanov]

On 12/11/2012 01:33 AM, Cyrill Gorcunov wrote:
> 
> fanotify requires additional parameters to be stored
> 
>  - each file entry will have the @type of 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 notification it represent, and here, to reuse
>    exitsting format and disk space, some members of it will
>    be treated a bit differently for fanotify objects
> 
>     - @wd will represent additional mark flags (actually I
>       think of renaming this member to wd_mflags, but this
>       better to be done later once everything else calms
>       down)
> 
>     - @sdev remains meaning device on which mark lays on,
>       but since kernel format provides us that named mount
>       identificator, we do additional processing and retrieve
>       and save real @sdev in this field
> 
> This is a big picture, the real processing addressed in furter
> patches.
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  protobuf/fsnotify.proto | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> +
> +	optional fsnotify_type	type		= 5;
> +	optional fanotify_glob	faglob		= 6;

Do we _really_ need two fields for that? Why not

if_fanotify(FsnotifyFileEntry *e)
{
	return e->faglob != NULL;
}

?