Returning to how to improve/replace pioctl().

Why not combine the two proposed approaches:

On Mon, May 16, 2016 at 02:38:22PM -0400, Jan Harkes wrote:
> I think the virtual file system would be the cleaner and better solution
> because we already have to present a file system interface to the user
> anyway, considering that is the main purpose of a file system.

On Tue, May 17, 2016 at 10:53:56AM +0200, u-myfx_at_aetey.se wrote:
> > > An alternative solution might be using RPC2, locally.

We might let venus keep a table of secrets "per active uid" and offer
these in virtual files like /coda/.pioctlsecret/<numeric_uid> where
everyone with the matching effective uid could read and get the (at need
randomly generated) corresponding secret. The magic directory can be/look
--x--x--x, so that it will not leak any information.

For extensibility this can be otherwise "/coda/.magic/secret<numeric_uid>",
"/coda/.magic/<numeric_uid>/pioctlsecret" or something else leaving
space for additional objects which might become desirable in the future.

Then clog/cfs/repair would be able to use rpc2 to talk to venus, all code
needed to handle data passing is already present in rpc2.

This would keep this virtual file system very simple,
get rid of the ad-hoc packing/unpacking code around pioctl,
avoid the involvement of the kernel in the "pioctl"-operations,
as a result also simplify the kernel module and make it smaller.

I appreciate if Jan (or anyone) would comment on this idea.

Regards,
Rune