diff options
author | Richard Jones <rjones@redhat.com> | 2010-09-09 13:51:52 +0100 |
---|---|---|
committer | Richard Jones <rjones@redhat.com> | 2010-09-09 13:51:52 +0100 |
commit | 6d9f8f5c140c3116fb0292fcf73f560812c7d5fb (patch) | |
tree | 132d5f6391eaf289eedd6b677f36f3509e488a0d /src/guestfs.pod | |
parent | f3c05da4f9c226c18476eb135dfcb5875d65bf63 (diff) | |
download | libguestfs-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.pod | 23 |
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 |