summaryrefslogtreecommitdiffstats
path: root/src/guestfs.pod
diff options
context:
space:
mode:
authorRichard Jones <rjones@redhat.com>2010-09-09 13:51:52 +0100
committerRichard Jones <rjones@redhat.com>2010-09-09 13:51:52 +0100
commit6d9f8f5c140c3116fb0292fcf73f560812c7d5fb (patch)
tree132d5f6391eaf289eedd6b677f36f3509e488a0d /src/guestfs.pod
parentf3c05da4f9c226c18476eb135dfcb5875d65bf63 (diff)
downloadlibguestfs-6d9f8f5c140c3116fb0292fcf73f560812c7d5fb.tar.gz
libguestfs-6d9f8f5c140c3116fb0292fcf73f560812c7d5fb.tar.xz
libguestfs-6d9f8f5c140c3116fb0292fcf73f560812c7d5fb.zip
guestfs: Remove traces of documentation for non-existent 'low-level API'
Diffstat (limited to 'src/guestfs.pod')
-rw-r--r--src/guestfs.pod23
1 files changed, 10 insertions, 13 deletions
diff --git a/src/guestfs.pod b/src/guestfs.pod
index 28496742..423dc10e 100644
--- a/src/guestfs.pod
+++ b/src/guestfs.pod
@@ -1109,24 +1109,21 @@ causes the state to transition back to CONFIG.
Configuration commands for qemu such as L</guestfs_add_drive> can only
be issued when in the CONFIG state.
-The high-level API offers two calls that go from CONFIG through
-LAUNCHING to READY. L</guestfs_launch> blocks until the child process
-is READY to accept commands (or until some failure or timeout).
+The API offers one call that goes from CONFIG through LAUNCHING to
+READY. L</guestfs_launch> blocks until the child process is READY to
+accept commands (or until some failure or timeout).
L</guestfs_launch> internally moves the state from CONFIG to LAUNCHING
while it is running.
-High-level API actions such as L</guestfs_mount> can only be issued
-when in the READY state. These high-level API calls block waiting for
-the command to be carried out (ie. the state to transition to BUSY and
-then back to READY). But using the low-level event API, you get
-non-blocking versions. (But you can still only carry out one
-operation per handle at a time - that is a limitation of the
-communications protocol we use).
+API actions such as L</guestfs_mount> can only be issued when in the
+READY state. These API calls block waiting for the command to be
+carried out (ie. the state to transition to BUSY and then back to
+READY). There are no non-blocking versions, and no way to issue more
+than one command per handle at the same time.
Finally, the child process sends asynchronous messages back to the
-main program, such as kernel log messages. Mostly these are ignored
-by the high-level API, but using the low-level event API you can
-register to receive these messages.
+main program, such as kernel log messages. You can register a
+callback to receive these messages.
=head2 SETTING CALLBACKS TO HANDLE EVENTS