Re: [PATCH] add a stub by which a module can bind to the AFS syscall

[Jan Harkes]

On Wed, Apr 30, 2003 at 04:30:20PM +0100, David Howells wrote:
> The four calls implemented by Linux are:
> 
>  (*) int setpag(void)
> 
>      Set Process Authentication Group number. This could easily be moved into
>      the kernel proper, with the PAG being stored in or depending from the
>      task structure somehow.
> 
>      This would then obviate the need for OpenAFS to mangle the setgroups and
>      getgroups syscalls.

Has been proposed many times in the context of Coda. Perhaps now that
there are 2 filesystems in the tree that want something like this we can
afford the extra int in the task structure. More likely we'll just have
to wait patiently for a credentials cache, or task ornaments, or
something might be possible with the LSM framework.

>  (*) int pioctl(const char *path, int cmd, void *arg, int followsymlink)
> 
>      Al Viro's favourite:-) Do ioctl() on a file refered to by pathname. Can't
>      be emulated by open/ioctl/close because:
> 
>      (a) it can operate directly on symbolic links.
>      (b) some of its functions don't require a file and don't fail if one
> 	 can't be opened.

Coda has the same abomination, but we use an ioctl on a special file in
the root of the Coda tree (/coda/.CONTROL). The advantage of this is
that if we have multiple clients and mountpoints we know which client is
supposed to handle the pioctl.

>  (*) int afs_call(...)
>  (*) int afs_icl(...)

We don't have anything like that, and most likely just stuffed them
into the pioctl multiplexor.

> There are six more which linux doesn't actually support, even though the
> multiplexor does:
> 
>  (*) icreate
>  (*) iopen
>  (*) idec
>  (*) iinc
>  (*) iread
>  (*) iwrite
> 
>      Deal with file by inode number.

You don't want to do that anyways, it will only work reliably on a few
filesystems. ReiserFS can possibly have inode collisions which are
resolved based on the parent directory inode. ext3 only journals writes
when a filehandle is closed, so opening by inode, writing to it and
closing it doesn't trigger a journal update. ramfs and tmpfs really
don't have any usable underlying inodes that can be opened with a
device/inode number pair because there is no 'device'.

Jan