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@xxxxxxxxxxxxxxx> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > --- > > 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@xxxxxxxx> SUSE Labs, CR
