<br><br><div class="gmail_quote">On Thu, May 10, 2012 at 6:58 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, 10 May 2012 15:55:55 +1000<br>
"Ian Latter" <<a href="mailto:ian.latter@midnightcode.org">ian.latter@midnightcode.org</a>> wrote:<br>
<br>
> So, I guess;<br>
> 1) Are all Fuse/FS ops handled by Gluster?<br>
> 2) Where can I find a complete list of the<br>
> Gluster fops, and not just those that have<br>
> been used in existing modules?<br>
<br>
</div>GlusterFS operations for a translator are all defined in an xlator_fops<br>
structure. When building translators, it can also be convenient to<br>
look at the default_xxx and default_xxx_cbk functions for each fop you<br>
implement. Also, I forgot to mention in my comments on your "hide"<br>
translator that you can often use the default_xxx_cbk callback when you<br>
call STACK_WIND, instead of having to define your own trivial one.<br>
<br>
FUSE operations are listed by the fuse_opcode enum. You can check for<br>
yourself how closely this matches our list. They do have a few ops of<br>
their own, we have a few of their own, and a few of theirs actually map<br>
to our xlator_cbks instead of xlator_fops. The points of<br>
non-correspondence seem to be interrupt, bmap, poll and ioctl. Maybe<br>
Csaba can elaborate on what we do (or plan to do) about these.<br>
<div class="im"><br></div></blockquote><div><br>We might support interrupt sometime. Bmap - probably never. Poll, maybe. Ioctl - depeneds on what type of ioctl and requirement.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 3) Is it safe to path match on loc_t? (i.e. is<br>
> it fully resolved such that I won't find<br>
> /etc/././././passwd)? This I could test ..<br>
<br>
</div>Name/path resolution is an area that has changed pretty recently, so<br>
I'll let Avati or Amar field that one.<br></blockquote><div><br>The ".." interpretation is done by the client side VFS. Internal path construction does not use ".." and are always normalized. There are new situations where we now support non-absolute paths, but those are for GFID based addressing and ".." does not come into picture there.<br>
<br>Avati <br></div></div>