On 6/30/25, 9:06 AM, "Amir Goldstein" <amir73il@xxxxxxxxx <mailto:amir73il@xxxxxxxxx>> wrote: > On Mon, Jun 30, 2025 at 4:50 PM Jan Kara <jack@xxxxxxx> wrote: > > > > Hi! > > > > I agree expanding fanotify_event_metadata painful. After all that's the > > reason why we've invented the additional info records in the first place :). > > So I agree with putting the id either in a separate info record or overload > > something in fanotify_event_metadata. > > > > On Sun 29-06-25 08:50:05, Amir Goldstein wrote: > > > I may have mentioned this before, but I'll bring it up again. > > > If we want to overload event->fd with response id I would consider > > > allocating response_id with idr_alloc_cyclic() that starts at 256 > > > and then set event->fd = -response_id. > > > We want to skip the range -1..-255 because it is used to report > > > fd open errors with FAN_REPORT_FD_ERROR. > > > > I kind of like this. It looks elegant. The only reason I'm hesitating is > > that as you mentioned with persistent notifications we'll likely need > > 64-bit type for identifying event. But OTOH requirements there are unclear > > and I can imagine even userspace assigning the ID. In the worst case we > > could add info record for this persistent event id. > > Yes, those persistent id's are inherently different from the response key, > so I am not really worried about duplicity. > > > So ok, let's do it as you suggest. > > Cool. > > I don't think that we even need an explicit FAN_REPORT_EVENT_ID, > because it is enough to say that (fid_mode != 0) always means that > event->fd cannot be >= 0 (like it does today), but with pre-content events > event->fd can be a key < -255? > > Ibrahim, > > Feel free to post the patches from my branch, if you want > post the event->fd = -response_id implementation. > > I also plan to post them myself when I complete the pre-dir-content patches. Sounds good. I will pull in the FAN_CLASS_PRE_CONTENT | FAN_REPORT_FID branch and resubmit this patch now that we have consensus on the approach here.
