linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	nixiaoming@huawei.com, linux-fsdevel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] fanotify: self describing event metadata
Date: Mon, 8 Oct 2018 13:54:40 +0200	[thread overview]
Message-ID: <20181008115440.GB21682@quack2.suse.cz> (raw)
In-Reply-To: <20181008101229.7923-1-amir73il@gmail.com>

Hi Amir,

On Mon 08-10-18 13:12:29, Amir Goldstein wrote:
> Use the 'reserved' u8 field in event metadata to describe event
> optional information.
> 
> When event->pid is thread id, set the flag FAN_EVENT_INFO_TID in
> event->flags.
> 
> Rename the init flag that is used to request reporting thread id
> in event to FAN_REPORT_TID.
> 
> This change is semantic, because in the only case that user requests
> FAN_REPORT_TID and fanotify is not able to meet that request,
> event->pid will be zero anyway.
> 
> However, for future event info requests, it is better to be explicit
> about whether fanotify was able to meet the request, similar to how
> statx() API behaves.
> 
> Cc: <linux-api@vger.kernel.org>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
> 
> Jan,
> 
> While working on reporting file handles, I realized that the API would
> be more solid if the event info flags are bi-directional similar to
> statx().

That makes some sense but I'd really like to see how you apply this to
other things because e.g. with PID vs TGID I don't really see the need for
any flags. It might be interesting to have PID vs TGID flag there for
consistency once we really start to send them for other things but I don't
see a need to rush it now. Plus we are at rc7 already so we are out of
time for changes going to the coming merge window.

> Even if you disapprove of the way this patch modifies the event foramt,
> or if you would like to take more time to consider that, I would still
> like to rename the fanotify_init flag to FAN_REPORT_TID, becasue I think
> the name is better describing. See example man page with new name [1].

I agree the name is somewhat better. I did the renaming.

> I realize that the reserved/flags union is a bit ugly, but I think it
> will be less painful than introducing event metadata format v4 at this
> time.
> 
> What do you thing?

Why would be a new metadata format problem? You will quickly run out of
bits in that u8 anyways...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2018-10-08 19:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 10:12 [PATCH] fanotify: self describing event metadata Amir Goldstein
2018-10-08 11:54 ` Jan Kara [this message]
2018-10-08 15:40   ` Amir Goldstein
2018-10-09  7:29   ` Marko Rauhamaa

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=20181008115440.GB21682@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nixiaoming@huawei.com \
    /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).