Thanks Greg and Jan,

I appreciate your suggestions ad explanations.

On Tue, Jul 10, 2007 at 08:27:23PM -0400, Greg Troxel wrote:
>   I guess that only a minor change in the includes is needed
>   to be able to cross-compile the client on ia32 to work on amd64.
> 
> This sounds broken.  I think you should either build it native on amd64,
> or build it for i386, against the standard i386 includes.  Having it
> built for i386 but with some includes that are different from
> i386-on-amd64 sounds like a path to madness and futher inconsistencies.

That's why I tried to explain the rationale. From my perspective
it sounds broken to maintain a separate development environment
for the sake of extremely few programs, without any functional gain.

>   Examination of the code around the mount() call did not reveal
>   why it would/should fail.
>   The struct passed by the call consists of two ints, which seems
>   to have the same representation in both 32- and 64-bit mode.
> 
> So does venus compiled native in 64-bit mode work?  What does the mount
> call look like in this case?

It looks the same, but comes from a process running in different mode,
via a different 64-bit syscall ABI - the kernel otherwise has the 32-bit ABI
fully functional.

On Tue, Jul 10, 2007 at 10:05:18PM -0400, Jan Harkes wrote:
> 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.

The need for reencoding is due to the interface being defined in terms
of architecture-dependent data structures. I see that redefining
the interface in an architecture-independent way would break compatibility
with the current implementation. On the other side, as long as both
"peers" like venus-clog or venus-repair are compiled from the same code,
it should work - if the kernel really passes data as binary blobs.

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

As far as I can see it _should_ work as long as userspace is homogenous
(both venus and repair having a common idea of the data) given that the kernel
passes binary data back and forth?

Then again I wonder why venus failed at the mount() syscall...
A { int, int } structure looks the same in both modes,
the rest of the arguments are char pointers which should be treated
properly by the kernel due to its 32-bit ABI. It can be an independent
pure Linux-amd64 issue.

It feels otherwise frustrating to be unable to run the same code
using an _available_ ABI, having to recompile for a specific ABI instead.

x86 <-> amd64 is not the only example. Linux ABI is available on
several *BSD kernels, what is wrong with providing a single client userspace
for all those systems? Our Coda client is self-contained and does not
depend on any additional libraries, why do we have to maintain 5 instanses
of it - while one x86-Linux instance is capable of running on all 5 platforms
unmodified?..

Thanks for the discussion, 
I guess a fix is impossible without approval and help from the core developers
and Jan has a lot of more important stuff to take care of.

See you,
Rune