Coda File System

Re: Coda development roadmap

From: <>
Date: Wed, 6 Aug 2014 13:59:13 +0200
On Wed, Aug 06, 2014 at 07:39:02AM -0400, Greg Troxel wrote:
> writes:
> > "[incompatible mount operation]... holding back my usage of NetBSD.
> > The same limitation forces me currently to compile the client separately
> > for 32- and 64-bit kernels.
> > Of course the unification change will become feasible only when the pioctls
> > are "shortcut" past the kernel module"

> On NetBSD, syscalls are emulated with types from the other architecture
> and operating system, and this generally works.  Are you finding that
> the Linux venus makes a syscall that doesn't work right?  It could be
> that the emulation of Linux mount(2) is buggy or missing.

I do not think mount() is implemented. It does not look properly
translatable, mount() in Linux and *BSD take very different arguments.

> > " Venus would only use the "portable" system calls - iff the pioctl
> > IPC interface is platform-independent at run time, not only at compile
> > time. AFAIK it is not. I do not think pioctl() can be expected to be
> > emulated by different implementations of Linux ABI."
> A Linux binary just isn't portable, unless other systems properly
> emulate the system calls.

By "portable" I mean syscalls with similar semantics and arguments on
different systems, like read() but not like mount(). ioctl() is somewhere
in between, driver-specific ioctl()s are obviously non-portable while
general-purpose ones may be.

> (All that said, dropping pioctl sounds good.)

Glad you feel this too. The functionality of pioctls seems vital to have
but it would be nice to implement it without involving ioctl().

For one thing, I do not expect the "linuxulator" layer to support any
Coda-specific ioctls but there may be other situations where this can
become a portability obstacle.

Expressing the same functionality via more general system calls would
make it more easily usable in different environments.

Received on 2014-08-06 07:59:37