Messages in this thread | | | Date | Wed, 30 Apr 2003 14:07:00 -0400 | Subject | Re: [PATCH] add a stub by which a module can bind to the AFS syscall | From | 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |