<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> ><br>
> > Introduce a key in xdata "force-open" in open fop and if that<br>
> > key is set, make open-behind to not to delay open.<br>
> ><br>
> > But the problem is syncop_open () does not send any dictionary (it<br>
> > will be NULL). We can make open-behind<br>
> > check whether xdata is NULL and if so, consider that open call be<br>
> > generated internally (not from application) and wind it to the<br>
> > below xlator.<br>
> ><br>
> ><br>
> > Hmm.. I am not too sure whether we can rely on the interpretation that<br>
> > xdata being NULL means to force open in open-behind. There definitely<br>
> > are/will be other use-cases of syncop-open where some might<br>
> > inadvertently leave xdata NULL. It always helps in terms of<br>
> > understandability, to be explicit on what we want to do. Can't you<br>
> > create an xdata in fuse fd migration code and pass that down to<br>
> > syncop-open?<br>
> Whoever calls syncop_open does not send the xdata as the arugement at<br>
> all. It will be like this.<br>
> ret = syncop_open (new_subvol, &loc, flags, newfd);<br>
><br>
> The syncop framework itself sends the xdata as NULL while winding the<br>
> call (making syncop framework allocate a new dict before winding and<br>
> send it as an argument also wont work in this case, as fuse wont be able<br>
> to set any new key).<br>
<br>
</div></div>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?<br>
<br>
Others,<br>
Do you've any comments or reservations on this?<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Amar</div></div></div></div>