On Mon, Nov 06, 2006 at 10:38:50AM -0500, Jan Harkes wrote:
> My guess is that the end of coda_fbsd_clone needs an additional,
> 
>     mnt->dev = *dev;
> 
> I'm building a kernel with this change, but since I am running in a VM it
> is taking a while. It does look like this is the most likely cause of
> the problem.

This fixes the crash, however it doesn't fix Coda on FreeBSD-6.1. Now
I'm faced with a failing mount, which was probably broken by the
omount->nmount change,

 Revision 1.55 / (download) - annotate - [select for diffs], Mon Dec 6 19:46:02 2004 UTC (23 months ago) by phk

 Convert coda to nmount.

 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/coda/coda_vfsops.c.diff?r1=1.54&r2=1.55

If I'm reading the patch correctly this may require a userspace change
so that we pass "from=/dev/cfs0" instead of just "/dev/cfs0", but I'm
not sure.

Looking a bit further even when the mount problem is fixed, Coda still
won't work because of,

 Revision 1.24 / (download) - annotate - [select for diffs], Tue Mar 15
 12:39:30 2005 UTC (19 months, 3 weeks ago) by phk

 Disable two users of findcdev.  They do the wrong thing now and will
 need to be fixed.  In both cases the API should be reengineered to do
 something (more) sensible.

 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/coda/coda_venus.c.diff?r1=1.23&r2=1.24

Looks like venus_open got replaced with EOPNOTSUPP, so we won't be able
to actually open any files. I guess this is because the dev_t -> device
mapping was removed, so we can't actually pass down a device/inode
number pair for the container file. On Linux I made a similar change a
long time ago where we pass an open file descriptor to the cachefile to
support filesystems that do not use a device (ramfs/tmpfs only live in
the page cache) and journalling filesystems that do not log changes to a
file if it is accessed through the low level inode instead of the higher
level file structure.

This can probably be fixed by replacing the CODA_OPEN upcall with
CODA_OPEN_BYFD and then mapping the open file descriptor (which is only
valid in venus's context) to an internal file structure that can be used
in the context of the application that requested the open. But I'm
really just starting to look at all this, and it will probably take a
while as I am not really up to speed with freebsd kernel internals.

Jan