[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <201011261011.55266.tvrtko.ursulin@sophos.com>
Date: Fri, 26 Nov 2010 10:11:54 +0000
From: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
To: Alexey Zaytsev <alexey.zaytsev@...il.com>
CC: Eric Paris <eparis@...hat.com>, Scott Hassan <hassan@...funk.com>,
Jan Kara <jack@...e.cz>,
"agruen@...bit.com" <agruen@...bit.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stefan@...ttcher.org" <stefan@...ttcher.org>,
Al Viro <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 4/4] fanotify: Expose the file changes to the user
On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> +struct fanotify_opt_hdr {
> + __u8 type;
> + __u8 reserved;
> + __u16 len;
> + /* Payload goes here. */
> +};
> +
> +#define FANOTIFY_METADATA_VERSION 3
>
> struct fanotify_event_metadata {
> - __u16 event_len;
> + __u16 event_len; /* Including the options */
> __u8 vers;
> - __u8 reserved;
> + __u8 options_offset; /* Aka header length */
> __s32 fd;
> __aligned_u64 mask;
> __s32 pid;
> + /* Options go here. */
> };
I am not 100% comfortable with having 16 bits length fields because I am just
not sure there is a measurable performance difference versus just going with
32 bits.
Also, options_offset is, if I understood it correctly, basically the lenght of
fanotify_event_metadata. As such, isn't that field redundant since the lenght
is implied from the protocol version?
For which it follows that maybe no changes to fanotify_event_metadata are
needed to grow the protocol in the future. We have the version and total
lenght. All that is required is that we never change width and position of
version and lenght field and we should be fine. Later we can define option
structures each of which will "point" to the next and thats it, no?
Tvrtko
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists