Hi Greg,

On Sun, Mar 10, 2013 at 04:02:32PM -0400, Greg Troxel wrote:
> It would be really nice if this could be hooked into FUSE, to avoid
> library hackery.  It would seem to be that the upcalls into the FUSE
> handler are more or less equivalent to the system call intercepts, so I
> don't see why this would be super hard.

It would be nice to have a FUSE-based implementation but it is far from
equivalent to Ulocoda. FUSE depends on the local superuser to be set up
for Coda. Ulocoda is available for every user on every computer without
any regard to whether its administrator may care, that's the difference.

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.

For comparison, Dapty runs (for many years now) with tweaked standard
libraries, to correct their design problems like rpath :)

> In NetBSD, the coda kernel module works correctly, I believe.  But it is
> somewhat difficult to maintain.  There are so few coda users and (aren't
> good automated regression tests) that I can see how an OS would not keep
> it working.  It's only because of Brett and me that it works ok on
> NetbSD.

The native kernel module has an advantage of being slightly more efficient
and working with "unprepared" binaries, say closed source and statically
linked. I guess availability of Ulocoda on multiple platforms may help
the awareness about Coda and hence even kernel module maintenance.

Porting Ulocoda to Linux is on my TODO, wouldn't it be nice to make a
common effort, tacking NetBSD too? One piece of work which is worth to
do and which should be shareable between platforms is a rewrite of terra
in a language with a compact runtime. For the moment the language is python,
which is quite a heavy prerequisite for a basic thing like a file system
(compare a python installation size to 50KB of the Coda kernel module).

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

Cheers,
Rune