Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > What are the insane pioctl semantics you want? There's a file type beyond file, dir and symlink that AFS supports: mountpoint. It appears as a directory with no lookup op in Linux - though it does support readlink. When a client walks over it, it causes an automount of the volume named by the content of the mountpoint "file" on that point. NFS and CIFS have similar things. AFS allows the user to create them and remove them: http://docs.openafs.org/Reference/1/fs_mkmount.html http://docs.openafs.org/Reference/1/fs_rmmount.html provided the server grants permission to do so. OpenAFS, Coda, etc. do this by means of a pair of pioctl() functions (at least, I think Coda does - it ships the pioctl parameters off to userspace to handle, so the handling is not actually in the kernel). > If you can't even open a file on the filesystem, you damn well > shouldn't be able to to "pioctl" on it. > > And if you *can* open a file on the filesystem, why can't you just use > ioctl on it? Directory, not file. You can do mkdir (requiring write and execute), for example, in a directory you cannot open (which would require read). If you cannot open it, you cannot do ioctl on it. open(O_PATH) doesn't help because that doesn't let you do ioctl. David
