From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Eric Paris <eparis@redhat.com>, Scott Hassan <hassan@dotfunk.com>,
Jan Kara <jack@suse.cz>, "agruen@linbit.com" <agruen@linbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stefan@buettcher.org" <stefan@buettcher.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 4/4] fanotify: Expose the file changes to the user
Date: Fri, 26 Nov 2010 10:11:54 +0000 [thread overview]
Message-ID: <201011261011.55266.tvrtko.ursulin@sophos.com> (raw)
In-Reply-To: <20101122003357.13674.30341.stgit@zaytsev.su>
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.
next prev parent reply other threads:[~2010-11-26 10:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
2010-11-26 7:01 ` Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 3/4] fsnotify: Handle the file change ranges Alexey Zaytsev
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
2010-11-26 10:11 ` Tvrtko Ursulin [this message]
2010-11-26 11:21 ` Alexey Zaytsev
2010-11-26 11:41 ` Tvrtko Ursulin
2010-11-26 12:11 ` Alexey Zaytsev
2010-11-29 16:14 ` Eric Paris
2010-11-29 16:51 ` Alexey Zaytsev
2010-11-29 18:14 ` Eric Paris
2010-11-29 17:11 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011261011.55266.tvrtko.ursulin@sophos.com \
--to=tvrtko.ursulin@sophos.com \
--cc=agruen@linbit.com \
--cc=alexey.zaytsev@gmail.com \
--cc=eparis@redhat.com \
--cc=hassan@dotfunk.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan@buettcher.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).