Coda File System

Re: venus-kernel interface

From: Jan Harkes <>
Date: Wed, 29 Sep 2004 15:35:53 -0400
On Wed, Sep 29, 2004 at 04:35:00PM +0200, Ivan Popov wrote:
> On Wed, Sep 29, 2004 at 09:37:17AM -0400, Jan Harkes wrote:
> > Some small differences, mostly in the OPEN upcall. BSD's want a
> > device/inode number pair, Linux expects an open filedescriptor, while
> > Windows needs the pathname to access the container file.
> Ah, I see. It can be tricky to merge even the *ixish ones.

Maybe *BSD can move to the model where it is given an open
filedescriptor. The only tricky part is that this descriptor will need
to be mapped to whatever the kernel uses (struct file *) in the context
of the venus application, i.e. while still handling the reply to the
upcall before handing the result back to the blocked user application.

At that point, either grab a refcount and keep the file struct around
until the application closes the Coda object or take the device/inode
numbers and use the existing code. We needed to keep the file around in
Linux because the journalling filesystems would otherwise not keep track
of the changes made to the file contents, journalling was performed when
the higher level file object is closed, not when the low-level inode
gets released.

> > > The client does not. Clog could not talk to (native) Venus on FreeBSD,
> > > and (linux-abi) Venus can not mount /coda.
> > 
> > Clog uses ioctls on a special file in /coda, so I don't expect it to
> > work until you can at least mount the tree, but there shouldn't be many
> The native Venus was running well, but the linux-abi clog was unable to
> communicate with it.

Interesting since the pioctl code in coda-src/kerndep is identical for
both Linux and *BSD, so this would be a failure of the linux-abi. I
guess it tries to translate ioctls, but doesn't know about the Coda ones
or we happen to collide with some existing ioctl numbers and confuse the
translation code.

Received on 2004-09-29 15:37:01