Re: [Libguestfs] Proposed changes for OpenStack
On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
I still don't see why we need the guestfish event callbacks.
because ...
>The guestfish change is only for us to do testing.
[...]
This is an extension of the libguestfs api in a direction which is
best served by a different tool. I've failed to convince you of this
argument several times before though, so I'll try a different tack
;)
The reason this isn't going to work is that a FUSE filesystem
requires a process to exist which can respond to filesystem events
as they occur. This means that you would have to additionally add
functions for managing FUSE events, at the very least calling the
event handler. The API user would have to integrate these calls into
their event loop. If they didn't have an event loop, they'd have to
create one. This isn't the simplicity you're looking for.
Alternatively, they could fork. The problem is, if you do that you
either need to create a separate appliance (the performance overhead
you're trying to avoid), or create an interface to an existing
appliance over which commands from multiple sources can be
serialised (my suggestion).
I haven't written any code yet so I don't know for certain that it
will work. With that in mind, the architecture is as follows:
guestfs_mount_local doesn't return until the filesystem is unmounted.
The thread running guestfs_mount_local is the one which is processing
FUSE requests. In nuts and bolts terms, guestfs_mount_local calls
fuse_main with certain flags to stop it from forking into the
background (or more likely it'll call some of the lower level libfuse
APIs that fuse_main calls). No event loop integration is needed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora