On Mon, Mar 11, 2013 at 12:44:50PM -0400, Greg Troxel wrote:
> What I really meant is that there is an existing design, where library
> routines are thin wrappers on system calls.  The library intercept
> scheme changes that design, and I'm concerned about unintended
> consequences (in general, not that I'm articulating them).

I see. At the very least it seems to work in a sufficient number of
cases to make it practically useful.

> Does the library scheme end up with direct access to container files
> From the process?

Yes of course as the venus is basically unchanged - it hands over a local
file [descriptor] at open(). (The changes relevant for Ulocoda can and IMHO
should be applied to upstream, they do not sacrifice anything and
I guess make the design more consequent e.g. why the kernel module
should participate in authentication tokens passing to/from venus??).

> I think what is bothersome is very individual.

Indeed.

> What I meant is that given "open" and e.g. an absolute path, one has to
> be able to traverse the name and know when one is crossing from the
> regular vfs system to the intercepted-coda system (and possibly back,
> via symlinks).  Normally (on BSD) this traversal is done by namei inside
> of the open system call.  So it seems obvious that the open() library
> routine (wrapping open(2)) has to do this kind of processing without
> just passing the path to the kernel.

Yes naturally it does this kind of processing (quite certainly loses in
certain cases, I guess, but I know that Christer has put a serious effort
in making it behave).

> > (I prefer Linux-ABI when possible as it is stable over different Linux and
> > *BSD kernels, while a certain *BSD ABI is not guaranteed to be supported
> > on a newer *BSD kernel, depending on the actual host setup).
> 
> True and I see your point in general.  (But if you include the kernel
> compat options, NetBSD does very well at running old binaries.)

Yes I know - but my special area of interest is running binaries on any
host with minimal (or no) assumptions about its administration.  Then a
user can migrate between computers and still have her full environment
everywhere - without any extra effort. This can work even without a
common ABI but such a stable one as Linux offers is extremely helpful
when applicable.

> I haven't tried to look at the code yet, but I'm hopeful that the
> mechanisms to do fileops from the library to a venus can be reused to
> have a simple FUSE daemon that uses the same library-like calls to
> venus.

A FUSE interface would be certainly _very_ useful, opening Coda for
many platforms (Ulocoda would do this too, but it has its own limitations).

Regards,
Rune