On Sun, Jul 08, 2007 at 06:48:48PM +0200, u+codalist-p4pg_at_chalmers.se wrote:
> I would appreciate tips for where incompatibilities are between
> a 32-bit venus and a 64-bit Linux kernel.

Pretty much everywhere. Venus and the kernel exchange C structs
whose layout (padding/alignment) is defined by the ABI which is quite
different between 32-bit and 64-bit.

The main upcall and downcall datastructures may be somewhat ok, over
time their datatypes and definitions got specific enough to avoid most
common problems, but the real problems are in the ioctls (or pioctls),
which really pack almost arbitrary data. The only way to fix that is to
introduce a 32-bit compatibility ioctl that is capable of translating
between the two worlds.

However, unlike most in-kernel users of ioctls, Coda's ioctls are
between programs like cfs and clog on the one side and venus on the
other. So you would have to not only deal with various possible
combinations of 32- and 64-bit versions of cfs/clog/venus. But to be
able to translate the kernel has to know exactly what data is being
passed along inside these ioctls. Currently the kernel can just treat it
as a binary blob, but if it has to translate it needs to know how to
decode and re-encode information that it really has no business knowing
about.

> As the kernel supports the usual 32-bit ABI, I can start a venus
> process, but it fails at a try to mount /coda.

There are quite a few calls going back and forth.

> In a similar way, a 32-bit clog fails to contact a running (64-bit) venus
> to deliver the fetched token.

That is one of those ioctls, clog tries to pass the Coda token it got to
venus by calling an ioctl on /coda/.CONTROL. To make this work the
kernel would have to know this is a SETTOKEN ioctl, it would have to
extract all the fields which are packed according to the 32-bit ABI and
then repack it according to the 64-bit struct layout.

There are about 45-50 different ioctls in vproc_pioctl.cc, most of them
are used by cfs and repair.

Jan