X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=src%2Fguestfs.pod;h=9cf66f3c6d88aa259102b089457666c1fc047a4c;hb=8d8dc4c10700ee43bd026469665f5a16f6d2cbf5;hp=a8e530f0a3fad4b41c4fe685ad100d357106d850;hpb=472722a72df89895bb11a1244eafa7915b1af116;p=libguestfs.git

diff --git a/src/guestfs.pod b/src/guestfs.pod
index a8e530f..9cf66f3 100644
--- a/src/guestfs.pod
+++ b/src/guestfs.pod
@@ -14,7 +14,6 @@ guestfs - Library for accessing and modifying virtual machine images
  guestfs_mount (g, "/dev/sda1", "/");
  guestfs_touch (g, "/hello");
  guestfs_umount (g, "/");
- guestfs_sync (g);
  guestfs_close (g);
 
  cc prog.c -o prog -lguestfs
@@ -100,11 +99,10 @@ this:
   * disk image.
   */
  guestfs_touch (g, "/hello");
- 
- /* You only need to call guestfs_sync if you have made
-  * changes to the guest image.  (But if you've made changes
-  * then you *must* sync).  See also: guestfs_umount and
-  * guestfs_umount_all calls.
+
+ /* This is only needed for libguestfs < 1.5.24.  Since then
+  * it is done automatically when you close the handle.  See
+  * discussion of autosync in this page.
   */
  guestfs_sync (g);
  
@@ -117,7 +115,8 @@ functions that return integers return C<-1> on error, and all
 functions that return pointers return C<NULL> on error.  See section
 L</ERROR HANDLING> below for how to handle errors, and consult the
 documentation for each function call below to see precisely how they
-return error indications.
+return error indications.  See L<guestfs-examples(3)> for fully worked
+examples.
 
 =head2 DISK IMAGES
 
@@ -676,8 +675,7 @@ For documentation see L<guestfs-python(3)>.
 
 =item B<Ruby>
 
-Use the Guestfs module.  There is no Ruby-specific documentation, but
-you can find examples written in Ruby in the libguestfs source.
+For documentation see L<guestfs-ruby(3)>.
 
 =item B<shell scripts>
 
@@ -1856,6 +1854,14 @@ The header contains the procedure number (C<guestfs_proc>) which is
 how the receiver knows what type of args structure to expect, or none
 at all.
 
+For functions that take optional arguments, the optional arguments are
+encoded in the C<guestfs_I<foo>_args> structure in the same way as
+ordinary arguments.  A bitmask in the header indicates which optional
+arguments are meaningful.  The bitmask is also checked to see if it
+contains bits set which the daemon does not know about (eg. if more
+optional arguments were added in a later version of the library), and
+this causes the call to be rejected.
+
 The reply message for ordinary functions is:
 
  total length (header + ret,
@@ -2085,6 +2091,7 @@ enough.
 L<guestfs-examples(3)>,
 L<guestfs-ocaml(3)>,
 L<guestfs-python(3)>,
+L<guestfs-ruby(3)>,
 L<guestfish(1)>,
 L<guestmount(1)>,
 L<virt-cat(1)>,