Hi Alex,
> Which means only one thing - changing that API will affect very few
> things.
>
> Let's keep the kernel side sane. We don't have to mess with multiplexors
> and even if we decide to use them, we will be better off by having decoder
> outside of AFS proper. Again, take a look at interaction between userland
> and knfsd. Right now we have a sane interface (IO on nfsctl files) and
> we have a wrapper (sys_nfsctl) that does decode/open/write/read/close.
As you suggested on IRC, almost all pioctls can be emulated by either:
(1) doing a decode/mount/open/write/read/close on a file on a special
internal filesystem if an inode is not required,
or:
(2) translating the call to get/set/lget/lsetxattr calls if an inode is
required.
However, there's always an exception. One of the pioctls requires three
things:
(a) a dentry and inode,
(b) an input buffer with a filename in it,
(c) an output buffer for holding a fair amount of data.
This can't be done easily with (1) because of (a), and it can't be done
atomically as (2) because two separate calls would have to be made for (b) and
(c) (and the netfs would have to retain some sort of state).
How about, instead, for pioctl calls that require an inode, the AFS
multiplexor in the kernel invents a temporary file structure, points it at the
dentry and calls its open, ioctl and release calls on inode->f_op?
Or perhaps you'd consider adding an extra inode operation?
struct inode_operations {
...
int (*inodectl) (struct dentry *, unsigned int, unsigned long);
};
David