On Thu, Feb 22, 2007 at 11:01:24AM +0100, u+codalist-p4pg_at_chalmers.se wrote:
> For different reasons it would be handy to have a Venus variation
> not using any special kernel facilities, and a corresponding library
> talking to such Venus and implementing more or less the functionality
> of the kernel module, in form of entry points like our_coda_open().

Actually this idea isn't that far off, since I've also been thinking
about how we could test venus without requiring root priviledges, i.e.
run it from the build directory without installing kernel modules etc.
On the application side this could be implemented by a LD_PRELOAD
library wrapper that intercepts open/close and directory operations.

> One point where I see a problem is a mechanism for passing file descriptors
> between processes and the cache manager. Some form of IPC is necessary, if
> one does not want to transform Venus to a shared library.
> The only portable solution seems to be passing path names of the container
> files. There will be certainly some nasty race conditions, but hopefully
> it can be done, at least as long as Venus and cache are dedicated per user.

Well, venus already supports a CODA_OPEN_BY_PATH upcall which is used on
the Windows platform and except for an initial ioctl all interaction
with the kernel device node only involves normal read and write
operations which could just as easily be done against a pipe or unix
domain socket. However open by path has some disadvantages for a library
solution because every application would need full read/write access to
the container files. On unix systems it may be better to use fd passing
which is possible when we use a unix domain connection between the
library and venus. And on unix we already have such a connection which
is used by codacon.

The only remaining issue is that we can't totally trust the application
when it reports it closed the container file. With the kernel module we
know for certain that the last reference was dropped. So when we reuse a
container file we just truncate it. If we pass the fd we have to
truncate, unlink and create a new container.

> Would you estimate whether it is feasible to implement such version of
> Venus and a corresponding library? Any idea about how much work would
> it need?

Very feasable, the library would connect to the codacon port and then
send some command which identifies the user (token) and pass the fd off
to the part of venus where incoming kernel messages are handled. The
incoming messages have to get patched up so that the uid is correct,
when the reply is a CODA_OPEN_BY_FD the filedescriptor has to be pulled
out of the reply message and passed separately over the socket.

For the rest, all of the heavy lifting should be in the library which
will probably be about as much work as a typical kernel module
(~3500-5000 LOC).

Venus will need some additional tweaks like the unlink/create steps
whenever a container file is recycled and it is should continue startup
even when we can't open the kernel device or mount /coda.

Jan