All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@sophos.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: Mon, 29 Nov 2010 13:14:33 -0500	[thread overview]
Message-ID: <1291054473.3248.24.camel@localhost.localdomain> (raw)
In-Reply-To: <AANLkTikHyYZYfX7sg=edsC6uykM8gje+JsBUxpbYZ1q1@mail.gmail.com>

On Mon, 2010-11-29 at 19:51 +0300, Alexey Zaytsev wrote:

[rewriting history!]
> struct fanotify_event_metadata {
>        __u32 event_len; /* Including the options */
>        __u8 vers;
>        __u8 options_offset; /* Aka header length */
>        __u16 reserved;
>        __aligned_u64 mask;
>        __s32 fd;
>        __s32 pid;
>        /* Options go here. */
> };

> and let's make both vers and options_offset u8, just in case we need the
> other 2 bytes in the future:

So the last discussion is around vers and options_offset.

Alexy:				Tvrtko:
__u8 vers;			__u16 vers;
__u8 options_offset;		__u16 options_offset;
__u16 unused;

The only type of long option that first comes to mind is a filename.   A
filename could easily blow out the __u8 options_offset.  I probably
shouldn't put that in the event_metadata since it wouldn't be fixed
length and it wouldn't allow fixed offset extention of the
event_metadata, so maybe I shouldn't worry about it.  I'm trying to
think of reasons why __u8 isn't adequate other than my usual "just make
it bigger than we ever need"

You'll notice I'm using __u64 for the mask, even though we don't come
close to filling up an __u32 at this point.

Even though I can't think of a likely reason __u8 is bad I think I like
the 'Tvrtko' option better.  I think we should do a compromise:

Eric:
__u8 vers;
__u8 unused;
__u16 options_offset;

If we ever overload vers we can expand into another field.  Would could
change unused into vers2 and define the version as vers + vers2;  vers2
could even exist somewhere else in the metadata.  That can be done once
we get to version 254 while maintaining backwards compat beyond 255.  If
we ever overflow options_offset we are screwed since old userspace
wouldn't know how to handle things.

So, if you want to send me a patch that implements the above (along with
the obvious version bump to 3, I'll queue it up for this merge window
even though we have an ABI compatible solution.

-Eric


  reply	other threads:[~2010-11-29 18:19 UTC|newest]

Thread overview: 15+ 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-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
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 [this message]
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=1291054473.3248.24.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=agruen@linbit.com \
    --cc=alexey.zaytsev@gmail.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=tvrtko.ursulin@sophos.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.