HACKING

   1 PLEASE LOOK AT THE TOP OF EACH FILE BEFORE EDITING TO SEE WHETHER IT
   2 IS AUTOMATICALLY GENERATED OR NOT.
   3
   4 Adding a new action
   5 ----------------------------------------------------------------------
   6
   7 All action functions are generated automatically, so there are only
   8 two files you need to edit:
   9
  10 (1) generator/generator_actions.ml: Add your new action, parameters,
  11 description, etc. to the big list at the top of this file.
  12
  13 (2) Edit/create a C file in daemon/ subdirectory which implements your
  14 'do_action' function.  Take a look at one of the numerous examples
  15 there.
  16
  17 Formatting
  18 ----------------------------------------------------------------------
  19
  20 Try to use GNU / Emacs default formatting, following the convention
  21 used elsewhere in the source.
  22
  23 Please make sure that the code compiles without warnings.
  24
  25 Please test any changes.
  26
  27 Useful targets:
  28   make syntax-check    Checks the syntax of the C code.
  29   make check           Runs the test suite.
  30
  31 Enable warnings, and fix any you find:
  32   ./configure --enable-gcc-warnings
  33
  34 Code indentation
  35 ----------------------------------------------------------------------
  36 Our C source code generally adheres to some basic code-formatting
  37 conventions.  The existing code base is not totally consistent on this
  38 front, but we do prefer that contributed code be formatted similarly.
  39 In short, use spaces-not-TABs for indentation, use 2 spaces for each
  40 indentation level, and other than that, follow the K&R style.
  41
  42 If you use Emacs, add the following to one of one of your start-up files
  43 (e.g., ~/.emacs), to help ensure that you get indentation right:
  44
  45   ;;; In libguestfs, indent with spaces everywhere (not TABs).
  46   ;;; Exceptions: Makefile and ChangeLog modes.
  47   (add-hook 'find-file-hook
  48       '(lambda () (if (and buffer-file-name
  49                            (string-match "/libguestfs\\>" (buffer-file-name))
  50                            (not (string-equal mode-name "Change Log"))
  51                            (not (string-equal mode-name "Makefile")))
  52                       (setq indent-tabs-mode nil))))
  53
  54   ;;; When editing C sources in libguestfs, use this style.
  55   (defun libguestfs-c-mode ()
  56     "C mode with adjusted defaults for use with libguestfs."
  57     (interactive)
  58     (c-set-style "K&R")
  59     (setq c-indent-level 2)
  60     (setq c-basic-offset 2))
  61   (add-hook 'c-mode-hook
  62             '(lambda () (if (string-match "/libguestfs\\>" (buffer-file-name))
  63                             (libguestfs-c-mode))))
  64
  65 Directories
  66 ----------------------------------------------------------------------
  67
  68 appliance/
  69         The qemu appliance, build scripts and so on.
  70
  71 capitests/
  72         Automated tests of the C API.  See "Tests" below.
  73
  74 cat/
  75         The 'virt-cat', 'virt-filesystems' and 'virt-ls' commands and
  76         documentation.
  77
  78 contrib/
  79         Outside contributions, experimental parts.
  80
  81 csharp/
  82         Experimental C# bindings.
  83
  84 daemon/
  85         The daemon that runs inside the guest and carries out actions.
  86
  87 df/
  88         'virt-df' command and documentation.
  89
  90 examples/
  91         The examples.
  92
  93 fish/
  94         Guestfish (the command-line program / shell)
  95
  96 fuse/
  97         FUSE (userspace filesystem) built on top of libguestfs.
  98
  99 generator/
 100         The crucially important generator, used to automatically
 101         generate large amounts of boilerplate C code for things like
 102         RPC and bindings.
 103
 104 haskell/
 105         Haskell bindings.
 106
 107 hivex/ [removed in 1.0.85]
 108        This used to contain the hivex library for reading and
 109        writing Windows Registry binary hive files.  This is now
 110        available as a separate upstream project.
 111
 112 images/
 113         Some guest images to test against.  These are gzipped to save
 114         space.  You have to unzip them before use.
 115
 116         Also contains some files used by the test suite.
 117
 118 inspector/
 119         Virtual machine image inspector (virt-inspector).
 120
 121 java/
 122         Java bindings.
 123
 124 m4/
 125         M4 macros used by autoconf.
 126
 127 ocaml/
 128         OCaml bindings.
 129
 130 php/
 131         PHP bindings.
 132
 133 po/
 134         Translations of simple gettext strings.  For translations of
 135         longer documents, see po-docs/.
 136
 137 po-docs/
 138         The build infrastructure and PO files for translations of
 139         manpages and POD files.  Eventually this will be combined
 140         with the po/ directory, but that is rather complicated.
 141
 142 perl/
 143         Perl bindings.
 144
 145 python/
 146         Python bindings.
 147
 148 regressions/
 149         Regression tests.
 150
 151 rescue/
 152         'virt-rescue' command and documentation.
 153
 154 ruby/
 155         Ruby bindings.
 156
 157 tools/
 158         Command line tools written in Perl (virt-resize and more).
 159
 160 src/
 161         Source code to the C library.
 162
 163 test-tool/
 164         Interactive qemu/kernel test tool.
 165
 166 Tests
 167 ----------------------------------------------------------------------
 168
 169 You can supply zero or as many tests as you want per API call.
 170
 171 The test environment has 4 block devices:
 172   /dev/sda   500MB   General block device for testing.
 173   /dev/sdb    50MB   /dev/sdb1 is an ext2 filesystem used for testing
 174                      filesystem write operations.
 175   /dev/sdc    10MB   Used in a few tests where 2 block devices are needed.
 176   /dev/sdd     -     ISO with fixed content (see images/test.iso).
 177
 178 To be able to run the tests in a reasonable amount of time, the
 179 virtual machine and block devices are reused between tests.  So don't
 180 try testing kill_subprocess :-x  Between each test we blockdev-setrw,
 181 umount-all, lvm-remove-all.
 182
 183 Each test starts with an initial scenario, selected using one of the
 184 'Init*' expressions, described in generator/generator_types.ml.  These
 185 initialize the disks in a particular way as described.  You should not
 186 assume anything about the previous contents of other disks that are
 187 not initialized.
 188
 189 You can add a prerequisite clause to any individual test.  This is a
 190 run-time check, which, if it fails, causes the test to be skipped.
 191 Useful if testing a command which might not work on all variations of
 192 libguestfs builds.  A test that has prerequisite of 'Always' is run
 193 unconditionally.
 194
 195 In addition, packagers can skip individual tests by setting the
 196 environment variables: eg:
 197
 198   SKIP_TEST_<CMD>_<NUM>=1  SKIP_TEST_COMMAND_3=1  (skips test #3 of command)
 199   SKIP_TEST_<CMD>=1        SKIP_TEST_ZEROFREE=1   (skips all zerofree tests)
 200
 201 and packagers can run only certain tests by setting eg:
 202
 203   TEST_ONLY="vfs_type zerofree"
 204
 205 See capitests/tests.c for more details of how these environment
 206 variables work.
 207
 208 Debugging
 209 ----------------------------------------------------------------------
 210
 211 It's a good idea to use guestfish to try out new commands.
 212
 213 Debugging the daemon is a problem because it runs inside a minimal
 214 qemu environment.  However you can print messages from the daemon, and
 215 they will show up if you use 'guestfish -v'.
 216
 217 Patches
 218 ----------------------------------------------------------------------
 219
 220 Submit patches to the mailing list:
 221 http://www.redhat.com/mailman/listinfo/libguestfs
 222 and CC to rjones@redhat.com
 223
 224 I18N
 225 ----------------------------------------------------------------------
 226
 227 We support i18n (gettext anyhow) in the library.
 228
 229 However many messages come from the daemon, and we don't translate
 230 those at the moment.  One reason is that the appliance generally has
 231 all locale files removed from it, because they take up a lot of space.
 232 So we'd have to readd some of those, as well as copying our PO files
 233 into the appliance.
 234
 235 Debugging messages are never translated, since they are intended for
 236 the programmers.
 237
 238 Extended printf
 239 ----------------------------------------------------------------------
 240
 241 In the daemon code we have created custom printf formatters %Q and %R,
 242 which are used to do shell quoting.
 243
 244 %Q => Simple shell quoted string.  Any spaces or other shell characters
 245       are escaped for you.
 246
 247 %R => Same as %Q except the string is treated as a path which is prefixed
 248       by the sysroot.
 249
 250 eg.
 251
 252 asprintf (&cmd, "cat %R", path);
 253 ==> "cat /sysroot/some\ path\ with\ spaces"
 254
 255 Note: Do NOT use these when you are passing parameters to the
 256 command{,r,v,rv}() functions.  These parameters do NOT need to be
 257 quoted because they are not passed via the shell (instead, straight to
 258 exec).  You probably want to use the sysroot_path() function however.