On Sun, 25 Sep 2011 10:31:10 +0100 Simon Wilkinson <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
