Hello Greg,

On Wed, Nov 21, 2018 at 09:32:54AM -0500, Greg Troxel wrote:
> Currently, one has to have a kernel module just for coda.  This used to
> be the only way it could have been done, but is now boutique.  If every
> filesystem needed its own special module, the overall situation would be

(Don't most file systems need their specific kernel modules? Good or not
but isn't this the status quo?)

> untenable.  Given coda's small user base, this module is a maintenace
> burden on operating systems.

Alas, you are right. As small module as it is, it is still a burden.

> NetBSD has just discussed whether to
> remove coda kernel support, as it has almost no users.  For now, it is
> staying.

Oh! I depend on Coda being available on NetBSD. Hope it continues to.

> Now, almost all filesystems that have user-space implementations --
> perhaps everything but coda -- use FUSE

As far as I can see few of file systems have requirements similar to
Coda. One filesystem with a similar design and a user-space cache manager
(AFS) happens to use a dedicated and complex kernel module.

> I realize there are two perceived issues.  One issue is an efficiency
> concern, but I feel that basic functionality and portability is being
> sacrificed for efficiency,

If it were only a question of efficiency, I would certainly support going
the more portable way.

> and a filesystem I can't run everywhere
> effectively has zero performance because it doesn't meet basic
> requirements and thus can't be used.  However, supporting FUSE, and not
> having the kernel module work are separate issues, and it's entirely
> possible to have a FUSE method that is portable and a kernel module that
> is perhaps somewhat faster.

I am afraid that FUSE is not as portable as it could be desired,
especially if the high-level interface would be insufficient.

> The second issue is about pioctl and the extra signaling path, but I see
> no reason that can't work with magic filenames and ioctl.

This is imho what really should be fixed, FUSE or not.

With all due and enormous respect to the early developers, this
communication channel is flaky, both in design (ioctl is a really bad
tool, given that we handle a pure IPC/RPC between user processes and
venus; the only role of the kernel is to help process authentication,
not having to be aware of the data to be passed) and as a result also
flaky in the implementation.

All of the kernels where we have Coda today provide means for an
authenticated local socket connection, unfortunately not in the same
way, but this could be abstracted in user space, not in the kernel as
it is now. This can fully and much more flexibly replace pioctl.

There are also other, possibly more portable possibilities, like using the
present and full-featured rpc2 framework over a local network connection
(as long as we can safely establish a relation between dedicated rpc2
secrets and local uids).

> Without FUSE, I think coda will continue to exist in the margins and has
> no real hope of mainstream use.  Certainly I am unlikely to start using
> it again in this state.   So I ask that you consider FUSE support as an
> important priority.

Frankly I doubt whether FUSE would make a big difference. We have already
kernel support for Coda in Linux, NetBSD, FreeBSD. Which platform would
you look forward to, which has a usable FUSE but a different kernel than
one of the above?

Nevertheless, it looks we both desire a certain first step,
to replace the pioctl with a more though-out design.

This would not necessarily imply any changes in the existing kernel
part, just skip pioctl. Then a year or two later pioctl could be
safely purged from the kernels.

If this opens the door for using FUSE - the better!

Regards,
Rune