u-codalist-9wcu_at_aetey.se writes:

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

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

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

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

Sure, many of my systems run builds with some changes to the source.

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

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
nothing that special about coda that merits a special VFS
implementation.  (The specialness in write-disconnected operation is
significant, but orthogonal.)

The feature of working with unmodified binaries is about using the VFS
interface, rather than the native coda module; FUSE would have the same
properties.

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

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.

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
it into some programs?  Does open have a step-by-step implementation of
namei() that's normally in-kernel?  Is there a design document that
explains this?

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

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