Hi Amir, On Sun, Mar 30, 2025 at 09:53:36PM +0200, Amir Goldstein wrote: > > I prefer them in two patches. You can send them in the same patch set, > > though. > > ok > > I pushed the two patches to > https://github.com/amir73il/man-pages/commits/fan_deny_errno > > Let me know if you want me to re-post them Yes, please. > > > This change to the documentation of fanotify permission event response > > > is independent of the previous patches I posted to document the new > > > FAN_PRE_ACCESS event (also v6.14) and the fanotify_init(2) flag > > > FAN_REPORT_FD_ERROR (v6.13). > > > > > > There is another fanotify feature in v6.14 (mount events). > > > I will try to catch up on documenting that one as well. > > > > > > Thanks, > > > Amir. > > > > > > man/man7/fanotify.7 | 60 ++++++++++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 59 insertions(+), 1 deletion(-) > > > > > > diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7 > > > index 6f3a9496e..c7b53901a 100644 > > > --- a/man/man7/fanotify.7 > > > +++ b/man/man7/fanotify.7 > > > @@ -820,7 +820,7 @@ This is the file descriptor from the structure > > > .TP > > > .I response > > > This field indicates whether or not the permission is to be granted. > > > -Its value must be either > > > +Its value must contain either the flag > > > > This seems unrelated. Please keep it out of the patches. If you want > > to do it, please have a third trivial patch with "wfix" in the subject. > > what does wfix stand for? wording fix $ cat CONTRIBUTING.d/patches/subject | sed -n '/Trivial subject/,+12p'; Trivial subject For trivial patches, you can use subject tags: ffix Formatting fix. tfix Typo fix. wfix Minor wording fix. srcfix Change to manual page source that doesn't affect the output. Example: [PATCH v1] tcp.7: tfix > this is not a typo fix, this is a semantic fix. > > It is not true that the value of response is either FAN_ALLOW or FAN_DENY > those are flags in a bitset and the correct statement is that exactly > one of them needs to be set. I understand now. Then, I think it's more important to have this in a separate patch, to make sure we document the fix in a commit message. > > > +macro: > > > +.BR EPERM , > > > +.BR EIO , > > > +.BR EBUSY , > > > +.BR ETXTBSY , > > > +.BR EAGAIN , > > > +.BR ENOSPC , > > > +.BR EDQUOT . > > > > Should we have a manual page for FAN_DENY_ERRNO()? (I think we should.) > > I don't understand how it's supposed to work from this paragraph. > > > > > #define FAN_DENY_ERRNO(err) (FAN_DENY | (((err) & 0xff) << 24)) > > combined FAN_DENY with a specific error, but I see no > reason to expose the internals of this macro Ahhh, thanks. > > This does not deserve a man page of its own IMO. > > If you have a suggested for better formatting, please suggest it How about an example of using it? I think that'd be more useful than a lot of text. > > > +Extra response records start with a common header: > > > +.P > > > +.in +4n > > > +.EX > > > +struct fanotify_response_info_header { > > > + __u8 type; > > > + __u8 pad; > > > + __u16 len; > > > +}; > > > +.EE > > > +.in > > > +.P > > > +The value of > > > +.I type > > > > I'd say '.type' instead of 'type'. I know there's no consistency about > > it, but I'm going to globally fix that eventually. Let's do it good for > > new documentation. The '.' allows one to easily know that we're talking > > about a struct or union member. > > > > Sounds like a good change to me. > > pushed requested fixes to github. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
