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.

> > 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.

> OS specific differences (Windows is another story). The mount process is
> quite different between the BSDs and Linux.

I know, I thought about tweaking it so that I could compile in linux-abi
with say with a runtime option to use BSD mount sequence...

Hmm, it can work, after some tweaking, it should be possible to
produce a working venus and tools, which could talk both Linux-ish
and BSD-ish kernel protocols... Looks funny, but actually it can 
be easier to maintain, not only a common source, but a common binary
for 4 different OS. The overhead should not be too big.
It is VM address space allocation which can hinder that, but if we could
choose an rvm placement suitable for all... or choose it at runtime...

> > At any rate, we should have a binary definition of the protocol - imho.
> 
> Or a text based protocol. It might be less efficient, but a lot more

I meant "defined in terms of bytes and bits" not in terms of C structures
which can differ enormously in size, byte order and alignment.

> portable (and easier to debug). In any case, I'm not yet sure of the
> real value of a 32-bit userspace on a 64-bit kernel, it is probably

It's nice to be able to use the same userspace on different kernels,
so the protocol might be made compatible between 32 and 64 (or the same).
Ok, we can live with different kernel protocols, as we do now.
May be it is not worth the effort to merge them.
Still, a common ground is easier to maintain.

> better to get userspace cleaned up so that we can build a working 64-bit
> binary.

Of course. May be that will make the rvm scalability problem irrelevant...
:)

See you!
--
Ivan