From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Bobrowski <mbobrowski@mbobrowski.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-api@vger.kernel.org
Subject: Re: [PATCH v3 04/13] fanotify: define the structures to report a unique file identifier
Date: Sat, 1 Dec 2018 18:43:59 +0200 [thread overview]
Message-ID: <CAOQ4uxjFNuBDA4MpNWVPuAo-wJJtrvdsG8YhXvmzktv3nnmQqw@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxib+Vi5mvkFspB0wGa_YjiR4p99n4dV3BtXjnYToSfCwQ@mail.gmail.com>
On Fri, Nov 30, 2018 at 5:32 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> > > struct fanotify_event_info_fid {
> > > struct fanotify_event_info_header hdr;
> > > ....
> > >
> > > Seems more appropriate name than the shorter fanotify_event_fid name
> > > that you suggested.
> >
> > Fine by me.
>
> FYI, at the moment the uapi struct looks like this:
>
> struct fanotify_event_info_header {
> __u8 info_type;
> __u8 pad;
> __u16 len;
> };
>
> struct fanotify_event_info_fid {
> struct fanotify_event_info_header hdr;
> __kernel_fsid_t fsid;
> struct file_handle fh;
> };
>
I changed my mind about using struct file_handle.
The current v4 struct is defined:
struct fanotify_event_info_fid {
struct fanotify_event_info_header hdr;
__kernel_fsid_t fsid;
/*
* Following is an opaque struct file_handle that can be passed as
* an argument to open_by_handle_at(2).
*/
unsigned char handle[0];
};
It's true that name_to_handle_at(2) users need to know about the
layout of struct file_handle to pass the buffer size.
But the users of fanotify FAN_REPORT_FID and the users of
open_by_handle_at(2) can treat the handle as an opaque blob.
> >
> > > It bothers me a bit not to use struct file_handle in the definition,
> > > but I don't with to start moving struct file_handle into uapi.
> > > I am a bit lost trying to understand which uapi include file I need
> > > to include in fanotify.h if I want to use it. fcntl.h?
> >
I gave up trying to move struct file_handle to uapi headers, because
it is already defined in glibc fcntl-linux.h and I couldn't find a way
out of this mess, nor did I find a good reason to pursue this for the
current patch set.
...
>
> I pushed the reworked fanotify_dirent [2] branch and I am quite content
> with the result.
> For comparison, also pushed fanotify_fid-v3 [3] and fanotify_fid-v4 [4],
> which correspond to the last patch you posted review on (cached fsid).
>
> [2] https://github.com/amir73il/inotify-tools/commits/fanotify_dirent
> [3] https://github.com/amir73il/inotify-tools/commits/fanotify_fid-v3
> [4] https://github.com/amir73il/inotify-tools/commits/fanotify_fid-v4
>
Re-pushed those branches without changes to uapi/linux/fs.h.
Thanks,
Amir.
next prev parent reply other threads:[~2018-12-02 3:57 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-25 13:43 [PATCH v3 00/13] fanotify: add support for more event types Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 01/13] fsnotify: annotate directory entry modification events Amir Goldstein
2018-11-28 12:59 ` Jan Kara
2018-11-28 14:39 ` Amir Goldstein
2018-11-28 14:43 ` Jan Kara
2018-11-28 15:01 ` Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 02/13] fsnotify: send all event types to super block marks Amir Goldstein
2018-11-28 14:26 ` Jan Kara
2018-11-25 13:43 ` [PATCH v3 03/13] fanotify: rename struct fanotify_{,perm_}event_info Amir Goldstein
2018-11-28 14:29 ` Jan Kara
2018-11-25 13:43 ` [PATCH v3 04/13] fanotify: define the structures to report a unique file identifier Amir Goldstein
2018-11-28 15:27 ` Jan Kara
2018-11-28 16:24 ` Amir Goldstein
2018-11-28 17:43 ` Jan Kara
2018-11-28 18:34 ` Amir Goldstein
2018-11-29 7:51 ` Jan Kara
2018-11-29 8:16 ` Amir Goldstein
2018-11-29 10:16 ` Jan Kara
2018-11-29 11:10 ` Amir Goldstein
2018-11-30 15:32 ` Amir Goldstein
2018-12-01 16:43 ` Amir Goldstein [this message]
2018-11-25 13:43 ` [PATCH v3 05/13] fanotify: classify events that hold a " Amir Goldstein
2018-11-28 15:33 ` Jan Kara
2018-11-28 15:44 ` Jan Kara
2018-11-28 15:52 ` Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 06/13] fanotify: encode file identifier for FAN_REPORT_FID Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 07/13] fanotify: copy event fid info to user Amir Goldstein
2018-11-29 9:00 ` Jan Kara
[not found] ` <CAOQ4uxjcb=UqQiw0XcpDfetK28bM4tOYdvgxPwhkjgE2mxpt=g@mail.gmail.com>
2018-11-29 9:49 ` Jan Kara
2018-11-25 13:43 ` [PATCH v3 08/13] fanotify: enable FAN_REPORT_FID init flag Amir Goldstein
2018-11-29 9:46 ` Jan Kara
2018-11-29 10:52 ` Jan Kara
2018-11-29 11:03 ` Amir Goldstein
2018-11-29 13:08 ` Jan Kara
2018-11-25 13:43 ` [PATCH v3 09/13] fanotify: cache fsid in fsnotify_mark_connector Amir Goldstein
2018-11-29 10:48 ` Jan Kara
2018-11-29 11:42 ` Amir Goldstein
2018-11-29 13:11 ` Jan Kara
2018-11-25 13:43 ` [PATCH v3 10/13] fanotify: check FS_ISDIR flag instead of d_is_dir() Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 11/13] fanotify: support events with data type FSNOTIFY_EVENT_INODE Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 12/13] fanotify: add support for create/attrib/move/delete events Amir Goldstein
2018-11-25 13:43 ` [PATCH v3 13/13] fanotify: report FAN_ONDIR to listener with FAN_REPORT_FID Amir Goldstein
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=CAOQ4uxjFNuBDA4MpNWVPuAo-wJJtrvdsG8YhXvmzktv3nnmQqw@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
/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).