On Tue, Aug 05, 2014 at 03:45:31PM +0200, u-codalist-z149_at_aetey.se wrote:
> 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>]

When I mentioned a /proc like virtual filesystem I assumed everyone
understood that I was talking about it having files that were primarily
intended for human consumption with 'normal' filenames and typically
content limited to ascii characters only.

I don't know what your crazy obsession with pioctl is about, I told you
before the only kernel code you would save is a:

    copy_from_user();  /* copy request from user/cfs */
    queue_for_venus(); /* pass request to venus */ 
    copy_to_user();    /* pass response back to user/cfs */ 

A total of, I believe it was, 123 bytes of compiled code which includes
the bounds checks and validation and the other details I'm not showing
here. The rest of the code is already needed to pass the typical
mkdir/chown/open/etc. calls to the Coda client.

> which would nicely move all of pioctl traffic into the upcall interface

It already _is_ in the upcall interface. A pioctl in userspace maps a
path in Coda to a file identifier and then makes an ioctl in /coda which
is passed to venus as an upcall. The reason we do the userspace
path->fid mapping is because regular ioctls don't work on directories.

The ugly parts of pioctl are the binary blobs that are passed back and
forth as requests and replies. But you are not solving that either, you
just seem to hate having those 123 extra bytes in the kernel.

Oh, and indata in some format is an ugly binary blob, so it has '\0' and
'/' characters which you cannot pass as part of a path name, and
non-ascii ones which you probably don't want to pass. So you'd need
hexadecimal or base64 encoding.

> (would MAXPATHLEN size be enough for pioctl data?).

Actually MAXNAMLEN and it is in theory not enough because the pioctl api
allows for up to 4096 binary bytes of payload. Not sure how much cfs
calls realistically use though.

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

The existing kernel module has a pioctl interface already and there is
currently no FUSE interface at all. I don't think anybody has even
looked at if its threading expectations would even work with Coda's
userspace threading.

Jan