Re: Adding an "acceptable" interface to the Linux kernel for AFS

[David Howells <dhowells@warthog.cambridge.redhat.com>]

> > I'm wondering how attached OpenAFS is to this interface? Can OpenAFS be
> > altered to use the following access points instead:
> 
> Generally I think this interface will work.

It would be nice, though, not to have to worry about differentiating between
pioctls that take a path and those that don't inside of the core kernel.

> >  (1) setpag(pag_t pag)
> 
> If you don't specify a pag it should allocate you one, and for
> non-priviledged users this should be the only allowed mode.

Thinking about it, this shouldn't take an argument at all, and should just put
its caller into a completely new PAG with a unique ID.

> I assume:
> fs is a text representation of whose filesystem you're doing this for?
> ("openafs", "arla", etc)
> domain is what's typically referred to as an afs cell

Yes. After all, you might need the key to be available before you can mount.

This may be useful for samba too... The mount command for samba typically
requires authentication data to be passed as options (workgroup, username,
password).

> I'd also like to see a priviledged "unsetpag()", e.g. I no longer wish to be
> in a pag.

"I" being the calling process? That can be done. I could just define that it
is permissible for the PAG pointer to be NULL. This makes support for the init
process easier, as I don't have to compile in a PAG for it.

> Currently it's possible to set a token when you have no pag, and these
> become associated with the uid that set them. (The pag number is not the uid;
> Instead any process without a pag but with a uid that has tokens associated
> with it gets those tokens.) As long as the above don't bind tightly to a pag,
> sure.

So you'd have a list of tokens associated with the user too?

I suppose I could give both the PAG and the user lists, and search the PAG
first, then the user, but what detemines the user? The PAG, the opener of a
file or the current process?

> As to pioctl, will it be able to handle things where path cannot be stat'd
> in advance? For instance, the prefetching hint (VIOCPREFETCH), if you
> could stat it, it wouldn't be a prefetch. Another concern there would be
> dangling mount points (a mount point you still have to a volume that's
> been deleted) when calling VIOC_AFS_DELETE_MT_PT or VIOC_AFS_STAT_MT_PT.

The latter pair of pioctls you've mentioned both require the directory holding
the mount point to be locally available as a kernel inode, and both of them
require the path to that directory to be supplied as the path argument to
pioctl rather than the path of the mountpoint, so I don't see that there'd be
a problem there.

I don't have documentation on VIOCPREFETCH, but if it's anything like the
other two, then it shouldn't be a problem either.

> To the extent we can we'd avoid relying on this (8), but I think we'll need
> it for now.
> 
> >  (8) fsctl(const char *fs, const char *cmd, struct fsctl_buf)
> >

It may be possible to do this through the sysfs filesystem in 2.5 instead.

David