(Illustration by Gaich Muramatsu)
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. JanReceived on 2014-08-05 12:09:29