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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:35 EST