On Mon, Mar 11, 2013 at 10:11:46AM -0400, Greg Troxel wrote:
> > for Coda. Ulocoda is available for every user on every computer without
> > any regard to whether its administrator may care, that's the difference.
> 
> I think whether one is concerned about this vs library changes is a
> matter of local concerns.  I am not concerned with needing to have FUSE
> installed.  Also, I think at least on NetBSD one can run a FUSE
> filesystem unprivileged with usermount=1 (and nosuid,noexec).

Note, this is true iff the superuser cared to set up this and/or with
noexec - which is taking away crucial functionality (suid on global file
systems is nonsense of course).

> > Library hackery is not much of a hackery if it is done in the library
> > in contrast to preloading an interceptor. Library-based access can be
> > deployed everywhere as a normal user - neither a dedicated kernel module
> > nor FUSE allow this.
> 
> It still doesn't work for static binaries, and it doesn't make system
> calls work correctly.

This works well for static binaries, as long as you build them against
right library :) About the correctness of the system calls, what do you
have in mind? I am happy being non-Posix-ly-correct in many cases
when Posix is inadequate.

> I would just as soon have a reasonably-efficient FUSE method and drop
> the native kernel module, and then work to add to FUSE whatever is
> missing to make it as efficient as the native interface.  There is

Is it possible to skip FUSE overhead of intercepting read/write syscalls?

> Fair enough about python, but in practice that's likely to be a
> theoretrical annoyance.  On my system the venus binary is 790K, plus
> another 425K of coda-only libraries.  But still, that's less than 1.4MB
> of python.

For me this is a very practical annoyance, as our Coda installer
weighs about 1.5M, including _all_ dependencies of course.
Adding python and its dependencies would grow the size several
times even with a thorough effort to skip as much as possible.

> So one produces a variant of the system libc that intercepts open() and
> also operations that take a fd?  And either install that, or LD_PRELOAD

Not necessarily. You do not ever install anything which is available in Dapty,
you just use the stuff available there, including the standard libraries.

> it into some programs?  Does open have a step-by-step implementation of
> namei() that's normally in-kernel?

I am not convinced that namei() has to be reimplemented step by step,
as it is just a certain kernel's approach to how to implement the semantics.

>  Is there a design document that explains this?

There is the source - unfortunately hardly other documentation that I am
aware of.

> Have you benchmarked impacts to the system performance when *not* using coda?

You mean how much the interception itself costs for accessing files
not under /coda ? I have not. I guess this will have to wait until I
get it working on Linux.

> > By the way, Ulocoda ported to Linux should be very much usable on NetBSD
> > too, thanks to LinuxABI. (Even for native NetBSD applications, given
> > mere a NetBSD library layer to talk to the daemons).
> 
> I don't follow this.  How is a regular NetBSD program going to link with
> a linux libc and run in linux mode?

I meant that the terra and venus daemons and the Linux ABI interception
layer can be (bit for bit) the same as for Linux. Linux-ABI programs would
just work, too. NetBSD-ABI programs would have to link to a NetBSD-ABI
interception layer, otherwise remaning agnostic about the ABI which the
daemons use.

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

Regards,
Rune