Re: [PATCH 1/1] Document the new fanotify initialization flag FAN_REPORT_PIDFD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > @@ -188,6 +200,27 @@ struct fanotify_event_info_fid {
> > >  .EE
> > >  .in
> > >  .PP
> > > +In the instance that the fanotify group has been initialized with
> > > +.BR FAN_REPORT_PIDFD ,
> > > +the listening application should expect to receive a single
> > > +information record object as detailed below alongside the generic
> > > +.I fanotify_event_metadata structure:
> > > +.PP
> > > +.in +4n
> > > +.EX
> > > +struct fanotify_event_info_header {
> > > +    __u8 info_type;
> > > +    __u8 pad;
> > > +    __u16 len;
> > > +};
> >
> > This structure was just listed a few lines up.
> > There is no need to re-list it here.
>
> ACK.
>
> > > +
> > > +struct fanotify_event_info_pidfd {
> > > +        struct fanotify_event_info_header hdr;
> > > +        __s32 pidfd;
> > > +};
> > > +.EE
> > > +.in
> > > +.PP
> > >  For performance reasons, it is recommended to use a large
> > >  buffer size (for example, 4096 bytes),
> > >  so that multiple events can be retrieved by a single
> > > @@ -510,6 +543,64 @@ and the file handle is followed by a null terminated string that identifies the
> > >  name of a directory entry in that directory, or '.' to identify the directory
> > >  object itself.
> > >  .PP
> > > +The fields of the
> > > +.I fanotify_event_info_pidfd
> > > +structure are as follows:
> > > +.TP
> > > +.I hdr
> > > +This is a structure of type
> > > +.IR fanotify_event_info_header .
> > > +Exactly like the one that is provided in a
> > > +.I fanotify_event_info_fid
> > > +structure, it is a generic header that contains information used to
> > > +describe an additional information record object that is attached to
> > > +an event.
> > > +In the instance that
> > > +.BR FAN_REPORT_PIDFD
> > > +is supplied during fanotify group initialization, a single information
> > > +record object is expected to be attached alongside the generic
> > > +metadata event with its
> > > +.I info_type
> > > +field set to the value of
> > > +.BR FAN_EVENT_INFO_TYPE_PIDFD .
> > > +The
> > > +.I fanotify_event_info_header
> > > +structure also contains a
> > > +.I len
> > > +field.
> > > +The value of the
> > > +.I len
> > > +field is the total size of the
> > > +.I fanotify_event_info_pidfd
> > > +structure, which also includes
> > > +.IR fanotify_event_info_header .
> >
> > It would be a shame if we needed to repeat the same text for every new info_type
> > that we add. There should be no duplicate documentation of the
> > fanotify_event_info_header fields. Perhaps we need to describe those fields
> > before documenting fanotify_event_info_fid fields instead of inline in the
> > documentation of hdr field.
>
> Right, I see where you're coming from and I do generally agree. If we
> continue repeating the same pattern for each bonus event that is based
> on fanotify_event_info_header, then we'll end up unnecessarily
> polluting the documentation.
>
> Would you like me to try shuffle things around in a patch that
> precedes this one?
>

Yes, please do. Either prep patch or in same patch is fine by me.

Thanks,
Amir.



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux