On Wed, Jul 14, 2021 at 03:09:56PM +0300, Amir Goldstein wrote:
> On Wed, Jul 14, 2021 at 4:16 AM Matthew Bobrowski <repnop@xxxxxxxxxx> wrote:
> > On Mon, Jul 12, 2021 at 09:08:18PM +0300, Amir Goldstein wrote:
> > > On Mon, Jul 12, 2021 at 7:26 PM Jan Kara <jack@xxxxxxx> wrote:
> > > > On Mon 12-07-21 16:00:54, Amir Goldstein wrote:
> > > > Just a brainstorming idea: How about creating new event FAN_RENAME that
> > > > would report two DFIDs (if it is cross directory rename)?
> > >
> > > I like the idea, but it would have to be two DFID_NAME is case of
> > > FAN_REPORT_DFID_NAME and also for same parent rename
> > > to be consistent.
> >
> > I don't have much to add to this conversation, but I'm just curious here.
> >
> > If we do require two separate DFID_NAME record objects in the case of cross
> > directory rename operations, how does an event listener distinguish the
> > difference between which is which i.e. moved_{from/to}? To me, this
> > implies that the event listener is expected to rely on specific
> > supplemental information object ordering, which to my knowledge is a
> > contract that we had always wanted to avoid drawing.
> >
>
> I think the records should not rely on ordering, but on self describing types,
> such as FAN_EVENT_INFO_TYPE_DFID_NAME_{FROM,TO}
> but I am trying to think of better names.
Right, having such information types would work nicely IMO. I had something
like that in mind, but I just wanted to make sure that we weren't building
some reliance on the ordering of these information records as we recently
discussed not doing exactly that.
As far as the naming goes, FAN_EVENT_INFO_TYPE_DFID_NAME_{FROM,TO} is a
little bit of a mouth full IMO, but at this stage I haven't thought of any
better alternatives.
> I am still debating with myself between adding a new event type
> (FAN_RENAME), adding a new report flag (FAN_REPORT_TARGET_FID)
> that adds info records to existing MOVE_ events or some combination.
Well, if we went with adding a new event FAN_RENAME and specifying that
resulted in the generation of additional
FAN_EVENT_INFO_TYPE_DFID_NAME_{FROM,TO} information record types for an
event, wouldn't it be weird as it doesn't follow the conventional mechanism
of a listener asking for additional information records? As in,
traditionally we'd intialize the notification group with a flag and then
that flag controls whether or not one is permitted to receive events of a
particular type that may or may not include information records?
Maybe a combination approach is needed in this instance, but this doesn't
necessarily simplify things when attempting to document the API semantics
IMO.
> My goal is to minimize the man page size and complexity.
Either approach, I think they'll be significant documentation changes that
are needed. :)
/M
