[OpenAFS-devel] Re: Fuse and testsuite

[Andrew Deason]

On Sun, 25 Sep 2011 10:31:10 +0100
Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:

> To perform fs commands, there needs to be a way of issuing path ioctls
> to the cache manager. On Linux this is already done by using ioctls
> against a "special" file in /proc. For my money, the easiest way of
> doing this for fuse would be to also allow a special file that lives
> within the AFS namespace, and issue ioctls on that.

I seem to recall ioctls are a little harder to do in fuse, due to their
unstructured nature. xattrs may be a little easier on the fuse side and
can avoid adding special files, but it will require some thought for
data marshalling. To get one of these mechanisms to work, you want to
eventually end up calling call_syscall() in libuafs. Probably what
should be done is adding a function to the libuafs API which just calls
call_syscall() (I don't think call_syscall is considered "public", since
it's not in the header file, and that name is way too generic; make
something with a uafs_ prefix).

You can also go the route that Derrick suggested where we use the
existing rmtsys mechanism (which is usually used to forward pioctls to
another machine). That is, you have a special pseudo-file
/foo/afs/.something, the contents of which are something like
localhost:1234, which is the address and port of the rmtsys daemon to
connect to. Then utilities open /foo/afs/.something, and forward pioctls
to the indicated rmtsys daemon (this is done in e.g. pioctl() in
sys/rmtsysc.c; we call lpioctl for local pioctls and fall through for
the remote calls). I think this method may be the easiest way forward
conceptually, and has the least amount of code to add if rmtsysd for
libuafs already works. I don't think rmtsysd does already work for
libuafs, but maybe making it function is not much work.

I don't think any of those ways to do this have any serious problems,
though, so at least in my personal opinion, whichever one you want to do
or manage to get working is fine.

> Then, fs just needs a command line switch to say which AFS root it
> should be targeting.

We can _also_ do this, but for the common case I really think this needs
to be in an env var, or somehow auto-detectable. Needing to type an
extra arg to get any utilities to work is just unusable.

Also, to get authentication working, just get the pioctls working. aklog
just sets credentials via a pioctl, so once it can work with them, it
shouldn't need anything else special. I think libuafs (or another
library) really needs an API that allows setting credentials more easily
(so you don't need to issue the pioctl manually in whatever
libuafs-using application you're using), but for the purposes of the
fuse client it's not necessary.

-- 
Andrew Deason
adeason@sinenomine.net