On Sun, Sep 25, 2011 at 7:02 PM, Andrew Deason <[email protected]> wrote: > On Sun, 25 Sep 2011 10:31:10 +0100 > Simon Wilkinson <[email protected]> wrote:
> > 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. it shouldn't be. it's probably a few defines. > 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. it' usable, but really it's wretched. i don't think we want to go that way. > 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 > -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
