X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=src%2Fguestfs.pod;h=06c3530f20f56503843f9cc06f729e5b5e80d04c;hb=refs%2Ftags%2F1.13.12;hp=db9d8f066c28cab951faea62f35e59eb73bb46e4;hpb=d025e91f6751505c70b7b5f492ee72c67e274ecf;p=libguestfs.git diff --git a/src/guestfs.pod b/src/guestfs.pod index db9d8f0..06c3530 100644 --- a/src/guestfs.pod +++ b/src/guestfs.pod @@ -1344,8 +1344,6 @@ been printed to C before the program exits. For other programs the caller will almost certainly want to install an alternate error handler or do error handling in-line like this: - g = guestfs_create (); - /* This disables the default behaviour of printing errors on stderr. */ guestfs_set_error_handler (g, NULL, NULL); @@ -1354,9 +1352,12 @@ alternate error handler or do error handling in-line like this: /* Examine the error message and print it etc. */ char *msg = guestfs_last_error (g); int errnum = guestfs_last_errno (g); - fprintf (stderr, "%s\n", msg); + fprintf (stderr, "%s", msg); + if (errnum != 0) + fprintf (stderr, ": %s", strerror (errnum)); + fprintf (stderr, "\n"); /* ... */ - } + } Out of memory errors are handled differently. The default action is to call L. If this is undesirable, then you can set a @@ -1452,8 +1453,8 @@ Returns the current error handler callback. =head2 guestfs_set_out_of_memory_handler typedef void (*guestfs_abort_cb) (void); - int guestfs_set_out_of_memory_handler (guestfs_h *g, - guestfs_abort_cb); + void guestfs_set_out_of_memory_handler (guestfs_h *g, + guestfs_abort_cb); The callback C will be called if there is an out of memory situation. I. @@ -1832,6 +1833,21 @@ If no callback is registered: the messages are sent to stderr. You can override the printing of trace messages to stderr by setting up a callback. +=item GUESTFS_EVENT_ENTER +(payload type: function name) + +The callback function is called whenever a libguestfs function +is entered. + +The payload is a string which contains the name of the function +that we are entering (not including C prefix). + +Note that libguestfs functions can call themselves, so you may +see many events from a single call. A few libguestfs functions +do not generate this event. + +If no callback is registered: the event is ignored. + =back =head3 guestfs_set_event_callback @@ -2227,6 +2243,99 @@ callback to receive these messages. =head1 INTERNALS +=head2 APPLIANCE BOOT PROCESS + +This process has evolved and continues to evolve. The description +here corresponds only to the current version of libguestfs and is +provided for information only. + +In order to follow the stages involved below, enable libguestfs +debugging (set the environment variable C). + +=over 4 + +=item Create the appliance + +C is invoked to create the kernel, a +small initrd and the appliance. + +The appliance is cached in CUIDE> (or in +another directory if C is set). + +For a complete description of how the appliance is created and cached, +read the L and L man +pages. + +=item Start qemu and boot the kernel + +qemu is invoked to boot the kernel. + +=item Run the initrd + +C builds a small initrd. The initrd is +not the appliance. The purpose of the initrd is to load enough kernel +modules in order that the appliance itself can be mounted and started. + +The initrd is a cpio archive called +CUIDE/initrd>. + +When the initrd has started you will see messages showing that kernel +modules are being loaded, similar to this: + + febootstrap: ext2 mini initrd starting up + febootstrap: mounting /sys + febootstrap: internal insmod libcrc32c.ko + febootstrap: internal insmod crc32c-intel.ko + +=item Find and mount the appliance device + +The appliance is a sparse file containing an ext2 filesystem which +contains a familiar (although reduced in size) Linux operating system. +It would normally be called CUIDE/root>. + +The regular disks being inspected by libguestfs are the first +devices exposed by qemu (eg. as C). + +The last disk added to qemu is the appliance itself (eg. C +if there was only one regular disk). + +Thus the final job of the initrd is to locate the appliance disk, +mount it, and switch root into the appliance, and run C from +the appliance. + +If this works successfully you will see messages such as: + + febootstrap: picked /sys/block/vdb/dev as root device + febootstrap: creating /dev/root as block special 252:16 + febootstrap: mounting new root on /root + febootstrap: chroot + Starting /init script ... + +Note that C indicates that the appliance's +init script is now running. + +=item Initialize the appliance + +The appliance itself now initializes itself. This involves starting +certain processes like C, possibly printing some debug +information, and finally running the daemon (C). + +=item The daemon + +Finally the daemon (C) runs inside the appliance. If it +runs you should see: + + verbose daemon enabled + +The daemon expects to see a named virtio-serial port exposed by qemu +and connected on the other end to the library. + +The daemon connects to this port (and hence to the library) and sends +a four byte message C, which initiates the +communication protocol (see below). + +=back + =head2 COMMUNICATION PROTOCOL Don't rely on using this protocol directly. This section documents @@ -2817,6 +2926,11 @@ about the stable branch policy. =item * +Check C works on at least Fedora, Debian and +Ubuntu. + +=item * + Finalize RELEASE-NOTES. =item * @@ -2961,6 +3075,16 @@ be reached in practice. See the source code for more information. =over 4 +=item FEBOOTSTRAP_KERNEL + +=item FEBOOTSTRAP_MODULES + +These two environment variables allow the kernel that libguestfs uses +in the appliance to be selected. If C<$FEBOOTSTRAP_KERNEL> is not +set, then the most recent host kernel is chosen. For more information +about kernel selection, see L. This +feature is only available in febootstrap E 3.8. + =item LIBGUESTFS_APPEND Pass additional options to the guest kernel. @@ -3036,6 +3160,7 @@ L, L, L, L, +L, L, L.