From mboxrd@z Thu Jan  1 00:00:00 1970
From: Petr Vorel <petr.vorel@gmail.com>
Date: Wed, 6 Nov 2019 19:44:32 +0100
Subject: [LTP] [PATCH 2/2] fanotify: Rename fanotify_event_info_fid
 struct
In-Reply-To: <1570001833.10536641.1572959481303.JavaMail.zimbra@redhat.com>
References: <20191105005341.19033-1-petr.vorel@gmail.com>
 <20191105005341.19033-3-petr.vorel@gmail.com>
 <1570001833.10536641.1572959481303.JavaMail.zimbra@redhat.com>
Message-ID: <20191106184432.GB25671@x230>
List-Id: <ltp.lists.linux.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ltp@lists.linux.it

Hi Jan,

> ----- Original Message -----
> > --- a/testcases/kernel/syscalls/fanotify/fanotify.h
> > +++ b/testcases/kernel/syscalls/fanotify/fanotify.h
> > @@ -133,17 +133,15 @@ struct fanotify_event_info_header {
> >  	uint8_t pad;
> >  	uint16_t len;
> >  };
> > +#endif /* ! FAN_REPORT_FID */

> >  #ifdef HAVE_NAME_TO_HANDLE_AT
> > -struct fanotify_event_info_fid {
> > +struct lapi_fanotify_event_info_fid {
> >  	struct fanotify_event_info_header hdr;
> >  	__kernel_fsid_t fsid;
> >  	unsigned char handle[0];
> >  };

> I think I see what you mean by "mixing glibc/lapi/kernel types".
> This structure could be combination of various types and now it's
> used even if sys/fanotify.h provides one.

> As alternative idea, we could add some accessor macro for that 'val' field.
> On musl macro would return '__val', and elsewhere 'val'.

Sure, I can do the detection, probably with autotools detection
(although that macro could be defined without it, but current state can change).

Kind regards,
Petr