On Tue, Aug 05, 2014 at 07:54:07AM -0400, Jan Harkes wrote:
> For pioctls it depends, most of them can probably exposed as extended
> attributes, for instance to set acls, or query object location,
> CML/volume information etc.. Another option is to create a /proc like
> virtual filesystem, but there it is harder to associate actions with
> particular objects so it is mostly useful for high level switches,

I like this idea of a virtual fs, say, available for doing operations like

 read_outdata < \
  /coda/.CONTROL/<pioctl_operation>/<indata_in_some_format>[/<more_if_needed>]

which would nicely move all of pioctl traffic into the upcall interface
(would MAXPATHLEN size be enough for pioctl data?).

This would be compatible both with the existing kernel modules and
with FUSE capabilities.

Rune