Since syncops are synchronous counterparts of asynchronous fops, I think we can add an xdata as the argument. How about adding an xdata argument to syncops just the way each fop does?> >
> > Introduce a key in xdata "force-open" in open fop and if that
> > key is set, make open-behind to not to delay open.
> >
> > But the problem is syncop_open () does not send any dictionary (it
> > will be NULL). We can make open-behind
> > check whether xdata is NULL and if so, consider that open call be
> > generated internally (not from application) and wind it to the
> > below xlator.
> >
> >
> > Hmm.. I am not too sure whether we can rely on the interpretation that
> > xdata being NULL means to force open in open-behind. There definitely
> > are/will be other use-cases of syncop-open where some might
> > inadvertently leave xdata NULL. It always helps in terms of
> > understandability, to be explicit on what we want to do. Can't you
> > create an xdata in fuse fd migration code and pass that down to
> > syncop-open?
> Whoever calls syncop_open does not send the xdata as the arugement at
> all. It will be like this.
> ret = syncop_open (new_subvol, &loc, flags, newfd);
>
> The syncop framework itself sends the xdata as NULL while winding the
> call (making syncop framework allocate a new dict before winding and
> send it as an argument also wont work in this case, as fuse wont be able
> to set any new key).
Others,
Do you've any comments or reservations on this?
I too think adding (xdata_req, &xdata_rsp) argument to all the syncops is a good idea. That way it will be more closer to the xlator->fops counterparts.
Regards,
Amar
