From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-yb1-f196.google.com ([209.85.219.196]:40297 "EHLO
        mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726788AbeLBD5G (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Sat, 1 Dec 2018 22:57:06 -0500
MIME-Version: 1.0
References: <20181125134352.21499-1-amir73il@gmail.com> <20181125134352.21499-5-amir73il@gmail.com>
 <20181128152730.GI15604@quack2.suse.cz> <CAOQ4uxgNB9pAdj6U6WrzxyD22G+AGh-bG+B3BD5bvFF6m=n-gA@mail.gmail.com>
 <20181128174328.GM15604@quack2.suse.cz> <CAOQ4uxijmXgEUZDjvzMfZgeccpnFf1UDU9sMJDuZKpwyZmNW_Q@mail.gmail.com>
 <20181129075117.GB31087@quack2.suse.cz> <CAOQ4uxj7q85sa6O+jSguOeEWJW2BYw0Ku7vCVcOqCZn4py2onA@mail.gmail.com>
 <20181129101652.GI31087@quack2.suse.cz> <CAOQ4uxib+Vi5mvkFspB0wGa_YjiR4p99n4dV3BtXjnYToSfCwQ@mail.gmail.com>
In-Reply-To: <CAOQ4uxib+Vi5mvkFspB0wGa_YjiR4p99n4dV3BtXjnYToSfCwQ@mail.gmail.com>
From: Amir Goldstein <amir73il@gmail.com>
Date: Sat, 1 Dec 2018 18:43:59 +0200
Message-ID: <CAOQ4uxjFNuBDA4MpNWVPuAo-wJJtrvdsG8YhXvmzktv3nnmQqw@mail.gmail.com>
Subject: Re: [PATCH v3 04/13] fanotify: define the structures to report a
 unique file identifier
To: Jan Kara <jack@suse.cz>
Cc: Matthew Bobrowski <mbobrowski@mbobrowski.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-api@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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.