Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

[David Howells]

Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> > What about opening the mountpoint (which HAS to be available) and then
> > calling an ioctl() on that?
> 
> It's very hard to "open the mountpoint" in user space. How would you even 
> do it? Remember: we're not living in the 1980's any more, and disco is 
> dead. ABBA may have made a comeback, but static mountpoints are long gone, 
> and won't be coming back.

I think what Andreas means is open the directory at the root of the mounted
tree, i.e. "/afs" for AFS, and then do an ioctl() on that that emulates
pioctl().

This is similar to what Coda does (see fs/coda/pioctl.c) except that that uses
a special file hidden in the root dir of the Coda mount (see coda_lookup() in
fs/coda/dir.c) that doesn't appear to readdir.

This is also similar to what OpenAFS does if it can't alter the syscall table -
it creates a proc file (/proc/fs/openafs/afs_ioctl) and issues ioctls on that,
to emulate pioctl().

In both cases, the pioctl emulator calls user_path() or similar from the
module, and then calls the appropriate handler directly.

> So you'd need to open the file itself. Which might be a symlink or a 
> device node, depending on the exact semantics of pioctl.

Indeed.  I was also hoping to use them to control caching of AFS, NFS and CIFS
files, where you might want to point at a file and say "put that in the cache"
or "eject that from the cache" or "keep that out of the cache".  However,
that's only possible with certain types of file where the file is opened
directly and an ioctl() done on it instead of a pioctl().  As you point out,
for symlinks it's tricky and for device files it's definitely wrong.

I'll acknowledge that it *could* perhaps be done with [l]setxattr() using
special attributes - however these things aren't necessarily attributes of the
file, but rather attributes of the system, so is setxattr() semantically
correct?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/