.\" Automatically generated by Podwrapper::Man 1.40.2 (Pod::Simple 3.35)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "guestfs-hacking 1"
.TH guestfs-hacking 1 "2019-02-07" "libguestfs-1.40.2" "Virtualization Support"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "名前"
.IX Header "名前"
guestfs-hacking \- extending and contributing to libguestfs
.SH "説明"
.IX Header "説明"
This manual page is for hackers who want to extend libguestfs itself.
.SH "THE SOURCE CODE"
.IX Header "THE SOURCE CODE"
Libguestfs source is located in the github repository
https://github.com/libguestfs/libguestfs
.PP
Large amounts of boilerplate code in libguestfs (\s-1RPC,\s0 bindings,
documentation) are generated.  This means that many source files will appear
to be missing from a straightforward git checkout.  You have to run the
generator (\f(CW\*(C`./autogen.sh && make \-C generator\*(C'\fR) in order to create those
files.
.PP
Libguestfs uses an autotools-based build system, with the main files being
\&\fIconfigure.ac\fR and \fIMakefile.am\fR.  See \*(L"\s-1THE BUILD SYSTEM\*(R"\s0.
.PP
The \fIgenerator\fR subdirectory contains the generator, plus files describing
the \s-1API.\s0  The \fIlib\fR subdirectory contains source for the library.  The
\&\fIappliance\fR and \fIdaemon\fR subdirectories contain the source for the code
that builds the appliance, and the code that runs in the appliance
respectively.  Other directories are covered in the section \*(L"\s-1SOURCE CODE
SUBDIRECTORIES\*(R"\s0 below.
.PP
Apart from the fact that all \s-1API\s0 entry points go via some generated code,
the library is straightforward.  (In fact, even the generated code is
designed to be readable, and should be read as ordinary code).  Some actions
run entirely in the library, and are written as C functions in files under
\&\fIlib\fR.  Others are forwarded to the daemon where (after some generated \s-1RPC\s0
marshalling) they appear as C functions in files under \fIdaemon\fR.
.PP
To build from source, first read the \fBguestfs\-building\fR\|(1).
.SS "ソースコードのサブディレクトリー"
.IX Subsection "ソースコードのサブディレクトリー"
There are a lot of subdirectories in the source tree! Which ones should you
concentrate on first? \fIlib\fR and \fIdaemon\fR which contain the source code of
the core library.  \fIgenerator\fR is the code generator described above, so
that is important.  The \fIMakefile.am\fR in the root directory will tell you
in which order the subdirectories get built.  And then if you are looking at
a particular tool (eg. \fIv2v\fR) or language binding (eg. \fIpython\fR), go
straight to that subdirectory, but remember that if you didn't run the
generator yet, then you may find files which appear to be missing.
.IP "\fIalign\fR" 4
.IX Item "align"
\&\fBvirt\-alignment\-scan\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIappliance\fR" 4
.IX Item "appliance"
libguestfs アプライアンス、スクリプトなどを構築します。
.IP "\fIbash\fR" 4
.IX Item "bash"
Bash tab-completion scripts.
.IP "\fIbuild-aux\fR" 4
.IX Item "build-aux"
autotools により使用されるさまざまなビルドスクリプト。
.IP "\fIbuilder\fR" 4
.IX Item "builder"
\&\fBvirt\-builder\fR\|(1) コマンドおよびドキュメント。
.IP "\fIcat\fR" 4
.IX Item "cat"
The \fBvirt\-cat\fR\|(1), \fBvirt\-filesystems\fR\|(1), \fBvirt\-log\fR\|(1), \fBvirt\-ls\fR\|(1)
and \fBvirt\-tail\fR\|(1) commands and documentation.
.IP "\fIcommon\fR" 4
.IX Item "common"
Various libraries of internal code can be found in the \fIcommon\fR
subdirectory:
.RS 4
.IP "\fIcommon/edit\fR" 4
.IX Item "common/edit"
Common code for interactively and non-interactively editing files within a
libguestfs filesystem.
.IP "\fIcommon/errnostring\fR" 4
.IX Item "common/errnostring"
The communication protocol used between the library and the daemon running
inside the appliance has to encode errnos as strings, which is handled by
this library.
.IP "\fIcommon/miniexpect\fR" 4
.IX Item "common/miniexpect"
A copy of the miniexpect library from
http://git.annexia.org/?p=miniexpect.git;a=summary.  This is used in
virt\-p2v.
.IP "\fIcommon/mlaugeas\fR" 4
.IX Item "common/mlaugeas"
Bindings for the Augeas library.  These come from the ocaml-augeas library
http://git.annexia.org/?p=ocaml\-augeas.git
.IP "\fIcommon/mlgettext\fR" 4
.IX Item "common/mlgettext"
Small, generated wrapper which allows libguestfs to be compiled with or
without ocaml-gettext.  This is generated by \fI./configure\fR.
.IP "\fIcommon/mlpcre\fR" 4
.IX Item "common/mlpcre"
Lightweight OCaml bindings for Perl Compatible Regular Expressions (\s-1PCRE\s0).
Note this is not related in any way to Markus Mottl's ocaml-pcre library.
.IP "\fIcommon/mlprogress\fR" 4
.IX Item "common/mlprogress"
OCaml bindings for the progress bar functions (see \fIcommon/progress\fR).
.IP "\fIcommon/mlstdutils\fR" 4
.IX Item "common/mlstdutils"
A library of pure OCaml utility functions used in many places.
.IP "\fIcommon/mltools\fR" 4
.IX Item "common/mltools"
OCaml utility functions only used by the OCaml virt tools (like
\&\f(CW\*(C`virt\-sysprep\*(C'\fR, \f(CW\*(C`virt\-v2v\*(C'\fR etc.)
.IP "\fIcommon/mlutils\fR" 4
.IX Item "common/mlutils"
OCaml bindings for C functions in \f(CW\*(C`common/utils\*(C'\fR, and some \s-1POSIX\s0 bindings
which are missing from the OCaml stdlib.
.IP "\fIcommon/mlvisit\fR" 4
.IX Item "common/mlvisit"
OCaml bindings for the visit functions (see \fIcommon/visit\fR).
.IP "\fIcommon/mlxml\fR" 4
.IX Item "common/mlxml"
OCaml bindings for the libxml2 library.
.IP "\fIcommon/options\fR" 4
.IX Item "common/options"
Common options parsing for guestfish, guestmount and some virt tools.
.IP "\fIcommon/parallel\fR" 4
.IX Item "common/parallel"
A framework used for processing multiple libvirt domains in parallel.
.IP "\fIcommon/progress\fR" 4
.IX Item "common/progress"
Common code for printing progress bars.
.IP "\fIcommon/protocol\fR" 4
.IX Item "common/protocol"
The XDR-based communication protocol used between the library and the daemon
running inside the appliance is defined here.
.IP "\fIcommon/qemuopts\fR" 4
.IX Item "common/qemuopts"
Mini-library for writing qemu command lines and qemu config files.
.IP "\fIcommon/structs\fR" 4
.IX Item "common/structs"
Common code for printing and freeing libguestfs structs, used by the library
and some tools.
.IP "\fIcommon/utils\fR" 4
.IX Item "common/utils"
Various utility functions used throughout the library and tools.
.IP "\fIcommon/visit\fR" 4
.IX Item "common/visit"
Recursively visit a guestfs filesystem hierarchy.
.IP "\fIcommon/windows\fR" 4
.IX Item "common/windows"
Utility functions for handling Windows drive letters.
.RE
.RS 4
.RE
.IP "\fIcontrib\fR" 4
.IX Item "contrib"
外部の貢献、実験的な部分です。
.IP "\fIcustomize\fR" 4
.IX Item "customize"
\&\fBvirt\-customize\fR\|(1) command and documentation.
.IP "\fIdaemon\fR" 4
.IX Item "daemon"
libguestfs アプライアンスの中で実行され、アクションを実行しているデーモン。
.IP "\fIdf\fR" 4
.IX Item "df"
\&\fBvirt\-df\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIdib\fR" 4
.IX Item "dib"
\&\fBvirt\-dib\fR\|(1) command and documentation.
.IP "\fIdiff\fR" 4
.IX Item "diff"
\&\fBvirt\-diff\fR\|(1) command and documentation.
.IP "\fIdocs\fR" 4
.IX Item "docs"
Miscellaneous manual pages.
.IP "\fIedit\fR" 4
.IX Item "edit"
\&\fBvirt\-edit\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIexamples\fR" 4
.IX Item "examples"
C \s-1API\s0 のコード例。
.IP "\fIfish\fR" 4
.IX Item "fish"
\&\fBguestfish\fR\|(1) コマンドラインシェル、および \fBvirt\-copy\-in\fR\|(1), \fBvirt\-copy\-out\fR\|(1),
\&\fBvirt\-tar\-in\fR\|(1), \fBvirt\-tar\-out\fR\|(1) のようなさまざまなシェルスクリプト。
.IP "\fIformat\fR" 4
.IX Item "format"
\&\fBvirt\-format\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIfuse\fR" 4
.IX Item "fuse"
\&\fBguestmount\fR\|(1), libguestfs の上に組み立てられた \s-1FUSE\s0 (ユーザー空間ファイルシステム)。
.IP "\fIgenerator\fR" 4
.IX Item "generator"
The crucially important generator, used to automatically generate large
amounts of boilerplate C code for things like \s-1RPC\s0 and bindings.
.IP "\fIget-kernel\fR" 4
.IX Item "get-kernel"
\&\fBvirt\-get\-kernel\fR\|(1) command and documentation.
.IP "\fIgnulib\fR" 4
.IX Item "gnulib"
gnulib はポートブルなライブラリとして使用されます。gnulib のコピーがこの下に含まれます。
.IP "\fIinspector\fR" 4
.IX Item "inspector"
\&\fBvirt\-inspector\fR\|(1), 仮想マシンイメージ検査ツール。
.IP "\fIlib\fR" 4
.IX Item "lib"
C ライブラリーのソースコード。
.IP "\fIlogo\fR" 4
.IX Item "logo"
Logo used on the website.  The fish is called Arthur by the way.
.IP "\fIm4\fR" 4
.IX Item "m4"
M4 macros used by autoconf.  See \*(L"\s-1THE BUILD SYSTEM\*(R"\s0.
.IP "\fImake-fs\fR" 4
.IX Item "make-fs"
\&\fBvirt\-make\-fs\fR\|(1) command and documentation.
.IP "\fIp2v\fR" 4
.IX Item "p2v"
\&\fBvirt\-p2v\fR\|(1) command, documentation and scripts for building the virt\-p2v
\&\s-1ISO\s0 or disk image.
.IP "\fIpo\fR" 4
.IX Item "po"
シンプルな gettext 文字列の翻訳。
.IP "\fIpo-docs\fR" 4
.IX Item "po-docs"
The build infrastructure and \s-1PO\s0 files for translations of manpages and \s-1POD\s0
files.  Eventually this will be combined with the \fIpo\fR directory, but that
is rather complicated.
.IP "\fIrescue\fR" 4
.IX Item "rescue"
\&\fBvirt\-rescue\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIresize\fR" 4
.IX Item "resize"
\&\fBvirt\-resize\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIsparsify\fR" 4
.IX Item "sparsify"
\&\fBvirt\-sparsify\fR\|(1) のコマンドおよびドキュメント。
.IP "\fIsysprep\fR" 4
.IX Item "sysprep"
\&\fBvirt\-sysprep\fR\|(1) コマンドおよびドキュメント。
.IP "\fItests\fR" 4
.IX Item "tests"
テストします。
.IP "\fItest-data\fR" 4
.IX Item "test-data"
Files and other test data used by the tests.
.IP "\fItest-tool\fR" 4
.IX Item "test-tool"
エンドユーザーが QEMU/カーネルの組み合わせが libguestfs で動作するかどうかを確認するためのテストツールです。
.IP "\fItmp\fR" 4
.IX Item "tmp"
Used for temporary files when running the tests (instead of \fI/tmp\fR etc).
The reason is so that you can run multiple parallel tests of libguestfs
without having one set of tests overwriting the appliance created by
another.
.IP "\fItools\fR" 4
.IX Item "tools"
Perl で書かれたコマンドラインツール (\fBvirt\-win\-reg\fR\|(1) および他の多くのもの)。
.IP "\fIutils\fR" 4
.IX Item "utils"
Miscellaneous utilities, such as \f(CW\*(C`boot\-benchmark\*(C'\fR.
.IP "\fIv2v\fR" 4
.IX Item "v2v"
\&\fBvirt\-v2v\fR\|(1) command and documentation.
.IP "\fIwebsite\fR" 4
.IX Item "website"
The http://libguestfs.org website files.
.IP "\fIcsharp\fR" 4
.IX Item "csharp"
.PD 0
.IP "\fIerlang\fR" 4
.IX Item "erlang"
.IP "\fIgobject\fR" 4
.IX Item "gobject"
.IP "\fIgolang\fR" 4
.IX Item "golang"
.IP "\fIhaskell\fR" 4
.IX Item "haskell"
.IP "\fIjava\fR" 4
.IX Item "java"
.IP "\fIlua\fR" 4
.IX Item "lua"
.IP "\fIocaml\fR" 4
.IX Item "ocaml"
.IP "\fIphp\fR" 4
.IX Item "php"
.IP "\fIperl\fR" 4
.IX Item "perl"
.IP "\fIpython\fR" 4
.IX Item "python"
.IP "\fIruby\fR" 4
.IX Item "ruby"
.PD
言語バインディング。
.SS "\s-1THE BUILD SYSTEM\s0"
.IX Subsection "THE BUILD SYSTEM"
Libguestfs uses the \s-1GNU\s0 autotools build system (autoconf, automake,
libtool).
.PP
The \fI./configure\fR script is generated from \fIconfigure.ac\fR and
\&\fIm4/guestfs\-*.m4\fR.  Most of the configure script is split over many m4
macro files by topic, for example \fIm4/guestfs\-daemon.m4\fR deals with the
dependencies of the daemon.
.PP
The job of the top level \fIMakefile.am\fR is mainly to list the subdirectories
(\f(CW\*(C`SUBDIRS\*(C'\fR) in the order they should be compiled.
.PP
\&\fIcommon\-rules.mk\fR is included in every \fIMakefile.am\fR (top level and
subdirectories).  \fIsubdir\-rules.mk\fR is included only in subdirectory
\&\fIMakefile.am\fR files.
.PP
There are many make targets.  Use this command to list them all:
.PP
.Vb 1
\& make help
.Ve
.SH "EXTENDING LIBGUESTFS"
.IX Header "EXTENDING LIBGUESTFS"
.SS "\s-1ADDING A NEW API\s0"
.IX Subsection "ADDING A NEW API"
Because large amounts of boilerplate code in libguestfs are generated, this
makes it easy to extend the libguestfs \s-1API.\s0
.PP
To add a new \s-1API\s0 action there are two changes:
.IP "1." 4
You need to add a description of the call (name, parameters, return type,
tests, documentation) to \fIgenerator/actions_*.ml\fR and possibly
\&\fIgenerator/proc_nr.ml\fR.
.Sp
There are two sorts of \s-1API\s0 action, depending on whether the call goes
through to the daemon in the appliance, or is serviced entirely by the
library (see \*(L"\s-1ARCHITECTURE\*(R"\s0 in \fBguestfs\-internals\fR\|(1)).
\&\*(L"guestfs_sync\*(R" in \fBguestfs\fR\|(3) is an example of the former, since the sync is
done in the appliance.  \*(L"guestfs_set_trace\*(R" in \fBguestfs\fR\|(3) is an example of the
latter, since a trace flag is maintained in the handle and all tracing is
done on the library side.
.Sp
Most new actions are of the first type, and get added to the
\&\f(CW\*(C`daemon_functions\*(C'\fR list.  Each function has a unique procedure number used
in the \s-1RPC\s0 protocol which is assigned to that action when we publish
libguestfs and cannot be reused.  Take the latest procedure number and
increment it.
.Sp
For library-only actions of the second type, add to the
\&\f(CW\*(C`non_daemon_functions\*(C'\fR list.  Since these functions are serviced by the
library and do not travel over the \s-1RPC\s0 mechanism to the daemon, these
functions do not need a procedure number, and so the procedure number is set
to \f(CW\*(C`\-1\*(C'\fR.
.IP "2." 4
Implement the action (in C):
.Sp
For daemon actions, implement the function \f(CW\*(C`do_<name>\*(C'\fR in the
\&\f(CW\*(C`daemon/\*(C'\fR directory.
.Sp
For library actions, implement the function \f(CW\*(C`guestfs_impl_<name>\*(C'\fR
in the \f(CW\*(C`lib/\*(C'\fR directory.
.Sp
In either case, use another function as an example of what to do.
.IP "3." 4
As an alternative to step 2: Since libguestfs 1.38, daemon actions can be
implemented in OCaml.  You have to set the \f(CW\*(C`impl = OCaml ...\*(C'\fR flag in the
generator.  Take a look at \fIdaemon/file.ml\fR for an example.
.PP
これらの変更をした後、コンパイルするために \f(CW\*(C`make\*(C'\fR を使用してください。
.PP
Note that you don’t need to implement the \s-1RPC,\s0 language bindings, manual
pages or anything else.  It’s all automatically generated from the OCaml
description.
.PP
\fIAdding tests for an \s-1API\s0\fR
.IX Subsection "Adding tests for an API"
.PP
You can supply zero or as many tests as you want per \s-1API\s0 call.  The tests
can either be added as part of the \s-1API\s0 description
(\fIgenerator/actions_*.ml\fR), or in some rarer cases you may want to drop a
script into \f(CW\*(C`tests/*/\*(C'\fR.  Note that adding a script to \f(CW\*(C`tests/*/\*(C'\fR is
slower, so if possible use the first method.
.PP
The following describes the test environment used when you add an \s-1API\s0 test
in \fIactions_*.ml\fR.
.PP
テスト環境は 4 個のブロックデバイスを持ちます:
.IP "\fI/dev/sda\fR 2 \s-1GB\s0" 4
.IX Item "/dev/sda 2 GB"
テスト用の一般的なブロックデバイス。
.IP "\fI/dev/sdb\fR 2 \s-1GB\s0" 4
.IX Item "/dev/sdb 2 GB"
\&\fI/dev/sdb1\fR is an ext2 filesystem used for testing filesystem write
operations.
.IP "\fI/dev/sdc\fR 10 \s-1MB\s0" 4
.IX Item "/dev/sdc 10 MB"
2 つのブロックデバイスが必要となるいくつかのテストにおいて使用されます。
.IP "\fI/dev/sdd\fR" 4
.IX Item "/dev/sdd"
\&\s-1ISO\s0 with fixed content (see \fIimages/test.iso\fR).
.PP
To be able to run the tests in a reasonable amount of time, the libguestfs
appliance and block devices are reused between tests.  So don't try testing
\&\*(L"guestfs_kill_subprocess\*(R" in \fBguestfs\fR\|(3) :\-x
.PP
Each test starts with an initial scenario, selected using one of the
\&\f(CW\*(C`Init*\*(C'\fR expressions, described in \fIgenerator/types.ml\fR.  These initialize
the disks mentioned above in a particular way as documented in \fItypes.ml\fR.
You should not assume anything about the previous contents of other disks
that are not initialized.
.PP
You can add a prerequisite clause to any individual test.  This is a
run-time check, which, if it fails, causes the test to be skipped.  Useful
if testing a command which might not work on all variations of libguestfs
builds.  A test that has prerequisite of \f(CW\*(C`Always\*(C'\fR means to run
unconditionally.
.PP
In addition, packagers can skip individual tests by setting environment
variables before running \f(CW\*(C`make check\*(C'\fR.
.PP
.Vb 1
\& SKIP_TEST_<CMD>_<NUM>=1
.Ve
.PP
eg: \f(CW\*(C`SKIP_TEST_COMMAND_3=1\*(C'\fR skips test #3 of \*(L"guestfs_command\*(R" in \fBguestfs\fR\|(3).
.PP
または:
.PP
.Vb 1
\& SKIP_TEST_<CMD>=1
.Ve
.PP
eg: \f(CW\*(C`SKIP_TEST_ZEROFREE=1\*(C'\fR skips all \*(L"guestfs_zerofree\*(R" in \fBguestfs\fR\|(3) tests.
.PP
Packagers can run only certain tests by setting for example:
.PP
.Vb 1
\& TEST_ONLY="vfs_type zerofree"
.Ve
.PP
See \fItests/c\-api/tests.c\fR for more details of how these environment
variables work.
.PP
\fIDebugging new APIs\fR
.IX Subsection "Debugging new APIs"
.PP
Test new actions work before submitting them.
.PP
新しいコマンドを試すために guestfish を使うことができます。
.PP
Debugging the daemon is a problem because it runs inside a minimal
environment.  However you can fprintf messages in the daemon to stderr, and
they will show up if you use \f(CW\*(C`guestfish \-v\*(C'\fR.
.SS "\s-1ADDING A NEW LANGUAGE BINDING\s0"
.IX Subsection "ADDING A NEW LANGUAGE BINDING"
All language bindings must be generated by the generator (see the
\&\fIgenerator\fR subdirectory).
.PP
There is no documentation for this yet.  We suggest you look at an existing
binding, eg. \fIgenerator/ocaml.ml\fR or \fIgenerator/perl.ml\fR.
.PP
\fIAdding tests for language bindings\fR
.IX Subsection "Adding tests for language bindings"
.PP
Language bindings should come with tests.  Previously testing of language
bindings was rather ad-hoc, but we have been trying to formalize the set of
tests that every language binding should use.
.PP
Currently only the OCaml and Perl bindings actually implement the full set
of tests, and the OCaml bindings are canonical, so you should emulate what
the OCaml tests do.
.PP
This is the numbering scheme used by the tests:
.PP
.Vb 1
\& \- 000+ basic tests:
\& 
\&   010  load the library
\&   020  create
\&   030  create\-flags
\&   040  create multiple handles
\&   050  test setting and getting config properties
\&   060  explicit close
\&   065  implicit close (in GC\*(Aqd languages)
\&   070  optargs
\&   080  version
\&   090  retvalues
\& 
\& \- 100  launch, create partitions and LVs and filesystems
\& 
\& \- 400+ events:
\& 
\&   410  close event
\&   420  log messages
\&   430  progress messages
\& 
\& \- 800+ regression tests (specific to the language)
\& 
\& \- 900+ any other custom tests for the language
.Ve
.PP
To save time when running the tests, only 100, 430, 800+, 900+ should launch
the handle.
.SS "\s-1FORMATTING CODE\s0"
.IX Subsection "FORMATTING CODE"
Our C source code generally adheres to some basic code-formatting
conventions.  The existing code base is not totally consistent on this
front, but we do prefer that contributed code be formatted similarly.  In
short, use spaces-not-TABs for indentation, use 2 spaces for each
indentation level, and other than that, follow the K&R style.
.PP
If you use Emacs, add the following to one of your start-up files (e.g.,
~/.emacs), to help ensure that you get indentation right:
.PP
.Vb 9
\& ;;; In libguestfs, indent with spaces everywhere (not TABs).
\& ;;; Exceptions: Makefile and ChangeLog modes.
\& (add\-hook \*(Aqfind\-file\-hook
\&     \*(Aq(lambda () (if (and buffer\-file\-name
\&                          (string\-match "/libguestfs\e\e>"
\&                              (buffer\-file\-name))
\&                          (not (string\-equal mode\-name "Change Log"))
\&                          (not (string\-equal mode\-name "Makefile")))
\&                     (setq indent\-tabs\-mode nil))))
\& 
\& ;;; When editing C sources in libguestfs, use this style.
\& (defun libguestfs\-c\-mode ()
\&   "C mode with adjusted defaults for use with libguestfs."
\&   (interactive)
\&   (c\-set\-style "K&R")
\&   (setq c\-indent\-level 2)
\&   (setq c\-basic\-offset 2))
\& (add\-hook \*(Aqc\-mode\-hook
\&           \*(Aq(lambda () (if (string\-match "/libguestfs\e\e>"
\&                               (buffer\-file\-name))
\&                           (libguestfs\-c\-mode))))
.Ve
.SS "変更のテスト方法"
.IX Subsection "変更のテスト方法"
Turn warnings into errors when developing to make warnings hard to ignore:
.PP
.Vb 1
\& ./configure \-\-enable\-werror
.Ve
.PP
有用なターゲットは次のとおりです:
.ie n .IP """make check""" 4
.el .IP "\f(CWmake check\fR" 4
.IX Item "make check"
一般的なテスト群を実行します。
.Sp
This is implemented using the regular automake \f(CW\*(C`TESTS\*(C'\fR target.  See the
automake documentation for details.
.ie n .IP """make check\-valgrind""" 4
.el .IP "\f(CWmake check\-valgrind\fR" 4
.IX Item "make check-valgrind"
valgrind にあるテスト群のサブセットを実行します。
.Sp
See \*(L"\s-1VALGRIND\*(R"\s0 below.
.ie n .IP """make check\-valgrind\-local\-guests""" 4
.el .IP "\f(CWmake check\-valgrind\-local\-guests\fR" 4
.IX Item "make check-valgrind-local-guests"
ローカルにインストールされた libvirt 仮想マシン (読み込み専用) を使用して、valgrind にあるテスト群のサブセットを実行します。
.ie n .IP """make check\-direct""" 4
.el .IP "\f(CWmake check\-direct\fR" 4
.IX Item "make check-direct"
Runs all tests using default appliance back-end.  This only has any effect
if a non-default backend was selected using \f(CW\*(C`./configure
\&\-\-with\-default\-backend=...\*(C'\fR
.ie n .IP """make check\-valgrind\-direct""" 4
.el .IP "\f(CWmake check\-valgrind\-direct\fR" 4
.IX Item "make check-valgrind-direct"
Run a subset of the test suite under valgrind using the default appliance
back-end.
.ie n .IP """make check\-uml""" 4
.el .IP "\f(CWmake check\-uml\fR" 4
.IX Item "make check-uml"
Runs all tests using the User-Mode Linux backend.
.Sp
As there is no standard location for the User-Mode Linux kernel, you \fIhave\fR
to set \f(CW\*(C`LIBGUESTFS_HV\*(C'\fR to point to the kernel image, eg:
.Sp
.Vb 1
\& make check\-uml LIBGUESTFS_HV=~/d/linux\-um/vmlinux
.Ve
.ie n .IP """make check\-valgrind\-uml""" 4
.el .IP "\f(CWmake check\-valgrind\-uml\fR" 4
.IX Item "make check-valgrind-uml"
Runs all tests using the User-Mode Linux backend, under valgrind.
.Sp
As above, you have to set \f(CW\*(C`LIBGUESTFS_HV\*(C'\fR to point to the kernel.
.ie n .IP """make check\-with\-upstream\-qemu""" 4
.el .IP "\f(CWmake check\-with\-upstream\-qemu\fR" 4
.IX Item "make check-with-upstream-qemu"
Runs all tests using a local qemu binary.  It looks for the qemu binary in
\&\s-1QEMUDIR\s0 (defaults to \fI\f(CI$HOME\fI/d/qemu\fR), but you can set this to another
directory on the command line, eg:
.Sp
.Vb 1
\& make check\-with\-upstream\-qemu QEMUDIR=/usr/src/qemu
.Ve
.ie n .IP """make check\-with\-upstream\-libvirt""" 4
.el .IP "\f(CWmake check\-with\-upstream\-libvirt\fR" 4
.IX Item "make check-with-upstream-libvirt"
Runs all tests using a local libvirt.  This only has any effect if the
libvirt backend was selected using \f(CW\*(C`./configure
\&\-\-with\-default\-backend=libvirt\*(C'\fR
.Sp
It looks for libvirt in \s-1LIBVIRTDIR\s0 (defaults to \fI\f(CI$HOME\fI/d/libvirt\fR), but you
can set this to another directory on the command line, eg:
.Sp
.Vb 1
\& make check\-with\-upstream\-libvirt LIBVIRTDIR=/usr/src/libvirt
.Ve
.ie n .IP """make check\-slow""" 4
.el .IP "\f(CWmake check\-slow\fR" 4
.IX Item "make check-slow"
Runs some slow/long\-running tests which are not run by default.
.Sp
To mark a test as slow/long\-running:
.RS 4
.IP "\(bu" 4
Add it to the list of \f(CW\*(C`TESTS\*(C'\fR in the \fIMakefile.am\fR, just like a normal
test.
.IP "\(bu" 4
Modify the test so it checks if the \f(CW\*(C`SLOW=1\*(C'\fR environment variable is set,
and if \fInot\fR set it skips (ie. returns with exit code 77).  If using
\&\f(CW$TEST_FUNCTIONS\fR, you can call the function \f(CW\*(C`slow_test\*(C'\fR for this.
.IP "\(bu" 4
Add a variable \f(CW\*(C`SLOW_TESTS\*(C'\fR to the \fIMakefile.am\fR listing the slow tests.
.IP "\(bu" 4
Add a rule to the \fIMakefile.am\fR:
.Sp
.Vb 2
\& check\-slow:
\&   $(MAKE) check TESTS="$(SLOW_TESTS)" SLOW=1
.Ve
.RE
.RS 4
.RE
.ie n .IP """sudo make check\-root""" 4
.el .IP "\f(CWsudo make check\-root\fR" 4
.IX Item "sudo make check-root"
Runs some tests which require root privileges.  These are supposed to be
safe, but take care.  You have to run this as root (eg. using \fBsudo\fR\|(8)
explicitly).
.Sp
To mark a test as requiring root:
.RS 4
.IP "\(bu" 4
Add it to the list of \f(CW\*(C`TESTS\*(C'\fR in the \fIMakefile.am\fR, just like a normal
test.
.IP "\(bu" 4
Modify the test so it checks if euid == 0, and if \fInot\fR set it skips
(ie. returns with exit code 77).  If using \f(CW$TEST_FUNCTIONS\fR, you can call
the function \f(CW\*(C`root_test\*(C'\fR for this.
.IP "\(bu" 4
Add a variable \f(CW\*(C`ROOT_TESTS\*(C'\fR to the \fIMakefile.am\fR listing the root tests.
.IP "\(bu" 4
Add a rule to the \fIMakefile.am\fR:
.Sp
.Vb 2
\& check\-root:
\&   $(MAKE) check TESTS="$(ROOT_TESTS)"
.Ve
.RE
.RS 4
.RE
.ie n .IP """make check\-all""" 4
.el .IP "\f(CWmake check\-all\fR" 4
.IX Item "make check-all"
Equivalent to running all \f(CW\*(C`make check*\*(C'\fR rules except \f(CW\*(C`check\-root\*(C'\fR.
.ie n .IP """make check\-release""" 4
.el .IP "\f(CWmake check\-release\fR" 4
.IX Item "make check-release"
Runs a subset of \f(CW\*(C`make check*\*(C'\fR rules that are required to pass before a
tarball can be released.  Currently this is:
.RS 4
.IP "\(bu" 4
check
.IP "\(bu" 4
check-valgrind
.IP "\(bu" 4
check-direct
.IP "\(bu" 4
check-valgrind-direct
.IP "\(bu" 4
check-slow
.RE
.RS 4
.RE
.ie n .IP """make installcheck""" 4
.el .IP "\f(CWmake installcheck\fR" 4
.IX Item "make installcheck"
Run \f(CW\*(C`make check\*(C'\fR on the installed copy of libguestfs.
.Sp
The version of installed libguestfs being tested, and the version of the
libguestfs source tree must be the same.
.Sp
Do:
.Sp
.Vb 4
\& ./autogen.sh
\& make clean ||:
\& make
\& make installcheck
.Ve
.SS "\s-1VALGRIND\s0"
.IX Subsection "VALGRIND"
When you do \f(CW\*(C`make check\-valgrind\*(C'\fR, it searches for any \fIMakefile.am\fR in
the tree that has a \f(CW\*(C`check\-valgrind:\*(C'\fR target and runs it.
.PP
Writing the \fIMakefile.am\fR and tests correctly to use valgrind and working
with automake parallel tests is subtle.
.PP
If your tests are run via a shell script wrapper, then in the wrapper use:
.PP
.Vb 1
\& $VG virt\-foo
.Ve
.PP
and in the \fIMakefile.am\fR use:
.PP
.Vb 2
\& check\-valgrind:
\&     make VG="@VG@" check
.Ve
.PP
However, if your binaries run directly from the \f(CW\*(C`TESTS\*(C'\fR rule, you have to
modify the \fIMakefile.am\fR like this:
.PP
.Vb 1
\& LOG_COMPILER = $(VG)
\& 
\& check\-valgrind:
\&     make VG="@VG@" check
.Ve
.PP
In either case, check that the right program is being tested by examining
the \fItmp/valgrind*\fR log files carefully.
.SS "\s-1SUBMITTING PATCHES\s0"
.IX Subsection "SUBMITTING PATCHES"
パッチをメーリングリストに提出します: http://www.redhat.com/mailman/listinfo/libguestfs および
rjones@redhat.com (Cc)。
.PP
You do not need to subscribe to the mailing list if you don’t want to.
There may be a short delay while your message is moderated.
.SS "\s-1DAEMON CUSTOM PRINTF FORMATTERS\s0"
.IX Subsection "DAEMON CUSTOM PRINTF FORMATTERS"
In the daemon code we have created custom printf formatters \f(CW%Q\fR and \f(CW%R\fR,
which are used to do shell quoting.
.ie n .IP "%Q" 4
.el .IP "\f(CW%Q\fR" 4
.IX Item "%Q"
シンプルなシェルクオート文字列。すべての空白と他のシェル文字がエスケープされます。
.ie n .IP "%R" 4
.el .IP "\f(CW%R\fR" 4
.IX Item "%R"
Same as \f(CW%Q\fR except the string is treated as a path which is prefixed by
the sysroot.
.PP
例:
.PP
.Vb 1
\& asprintf (&cmd, "cat %R", path);
.Ve
.PP
\&\f(CW\*(C`cat /sysroot/some\e path\e with\e spaces\*(C'\fR を生成します
.PP
\&\fINote:\fR Do \fInot\fR use these when you are passing parameters to the
\&\f(CW\*(C`command{,r,v,rv}()\*(C'\fR functions.  These parameters do \s-1NOT\s0 need to be quoted
because they are not passed via the shell (instead, straight to exec).  You
probably want to use the \f(CW\*(C`sysroot_path()\*(C'\fR function however.
.SS "国際化 (i18n) サポート"
.IX Subsection "国際化 (i18n) サポート"
We support i18n (gettext anyhow) in the library.
.PP
However many messages come from the daemon, and we don’t translate those at
the moment.  One reason is that the appliance generally has all locale files
removed from it, because they take up a lot of space.  So we'd have to readd
some of those, as well as copying our \s-1PO\s0 files into the appliance.
.PP
Debugging messages are never translated, since they are intended for the
programmers.
.SH "MISCELLANEOUS TOPICS"
.IX Header "MISCELLANEOUS TOPICS"
.SS "\s-1HOW OCAML PROGRAMS ARE COMPILED AND LINKED\s0"
.IX Subsection "HOW OCAML PROGRAMS ARE COMPILED AND LINKED"
Mostly this section is \*(L"how we make automake & ocamlopt work together\*(R" since
OCaml programs themselves are easy to compile.
.PP
Automake has no native support for OCaml programs, ocamlc nor ocamlopt.
What we do instead is to treat OCaml programs as C programs which happen to
contain these \*(L"other objects\*(R" (\f(CW"DEPENDENCIES"\fR in automake-speak) that
happen to be the OCaml objects.  This works because OCaml programs usually
have C files for native bindings etc.
.PP
So a typical program is described as just its C sources:
.PP
.Vb 1
\& virt_v2v_SOURCES = ... utils\-c.c xml\-c.c
.Ve
.PP
For programs that have no explicit C sources, we create an empty \fIdummy.c\fR
file, and list that instead:
.PP
.Vb 1
\& virt_resize_SOURCES = dummy.c
.Ve
.PP
The OCaml objects which contain most of the code are listed as automake
dependencies (other dependencies may also be listed):
.PP
.Vb 1
\& virt_v2v_DEPENDENCIES = ... cmdline.cmx v2v.cmx
.Ve
.PP
The only other special thing we need to do is to provide a custom link
command.  This is needed because automake won't assemble the ocamlopt
command, the list of objects and the \f(CW\*(C`\-cclib\*(C'\fR libraries in the correct
order otherwise.
.PP
.Vb 2
\& virt_v2v_LINK = \e
\&     $(top_srcdir)/ocaml\-link.sh \-cclib \*(Aq\-lutils \-lgnu\*(Aq \-\- ...
.Ve
.PP
The actual rules, which you can examine in \fIv2v/Makefile.am\fR, are a little
bit more complicated than this because they have to handle:
.IP "\(bu" 4
Compiling for byte code or native code.
.IP "\(bu" 4
The pattern rules needed to compile the OCaml sources to objects.
.Sp
These are now kept in \fIsubdir\-rules.mk\fR at the top level, which is included
in every subdirectory \fIMakefile.am\fR.
.IP "\(bu" 4
Adding OCaml sources files to \f(CW\*(C`EXTRA_DIST\*(C'\fR.
.Sp
Automake isn't aware of the complete list of sources for a binary, so it
will not add them all automatically.
.SS "\s-1VIRT\-V2V\s0"
.IX Subsection "VIRT-V2V"
First a little history.  Virt\-v2v has been through at least two complete
rewrites, so this is probably about the third version (but we don't intend
to rewrite it again).  The previous version was written in Perl and can be
found here: https://git.fedorahosted.org/git/virt\-v2v.git
.PP
The current version started out as almost a line-for-line rewrite of the
Perl code in OCaml + C, and it still has a fairly similar structure.
Therefore if there are details of this code that you don't understand
(especially in the details of guest conversion), checking the Perl code may
help.
.PP
The files to start with when reading this code are:
.IP "\(bu" 4
\&\fItypes.mli\fR
.IP "\(bu" 4
\&\fIv2v.ml\fR
.PP
\&\fItypes.mli\fR defines all the structures used and passed around when
communicating between different bits of the program.  \fIv2v.ml\fR controls how
the program runs in stages.
.PP
After studying those files, you may want to branch out into the input
modules (\fIinput_*\fR), the output modules (\fIoutput_*\fR) or the conversion
modules (\fIconvert_*\fR).  The input and output modules define \fI\-i\fR and \fI\-o\fR
options (see the manual).  The conversion modules define what guest types we
can handle and the detailed steps involved in converting them.
.PP
Every other file in this directory is a support module / library of some
sort.  Some code is written in C, especially where we want to use an
external C library such as libxml2.
.SS "\s-1VIRT\-P2V\s0"
.IX Subsection "VIRT-P2V"
Virt\-p2v is a front end on virt\-v2v.  ie. All it does is act as a \s-1GUI\s0 front
end, and it calls out to virt\-v2v to perform the actual conversion.
Therefore most of the C code in the \fIp2v/\fR subdirectory is Gtk (\s-1GUI\s0) code,
or supporting code for talking to the remote conversion server.  There is no
special support for physical machines in virt\-v2v.  They are converted in
the same way as foreign VMs.
.PP
\fIRunning virt\-p2v\fR
.IX Subsection "Running virt-p2v"
.PP
You can run the \fIp2v/virt\-p2v\fR binary directly, but it will try to convert
your machine’s real \fI/dev/sda\fR which is unlikely to work well.  However
virt\-p2v also has a test mode in which you can supply a test disk:
.PP
.Vb 1
\& make \-C p2v run\-virt\-p2v\-directly
.Ve
.PP
This is a wrapper around the \fBvirt\-p2v\fR\|(1) \fI\-\-test\-disk\fR option.  You can
control the \*(L"physical machine\*(R" disk by setting \f(CW\*(C`PHYSICAL_MACHINE\*(C'\fR to point
to a disk image.
.PP
A more realistic test is to run virt\-p2v inside a \s-1VM\s0 on the local machine.
To do that, do:
.PP
.Vb 1
\& make \-C p2v run\-virt\-p2v\-in\-a\-vm
.Ve
.PP
This also runs qemu with the \*(L"physical machine\*(R" disk (which you can set by
setting \f(CW\*(C`PHYSICAL_MACHINE\*(C'\fR), a virtual \s-1CD,\s0 and a variety of network cards
for testing.  You can change the qemu binary and add extra qemu options by
setting \f(CW\*(C`QEMU\*(C'\fR and/or \f(CW\*(C`QEMU_OPTIONS\*(C'\fR on the make commandline.
.PP
A third way to run virt\-p2v simulates fairly accurately the program being
downloaded over \s-1PXE\s0 and then doing an automatic conversion of the source
physical machine (the non-GUI path \*(-- see next section below):
.PP
.Vb 1
\& make \-C p2v run\-virt\-p2v\-non\-gui\-conversion
.Ve
.PP
\fIUnderstanding the virt\-p2v code\fR
.IX Subsection "Understanding the virt-p2v code"
.PP
\&\fISee also:\fR \*(L"\s-1HOW VIRT\-P2V WORKS\*(R"\s0 in \fBvirt\-p2v\fR\|(1)
.PP
There are two paths through the code, \s-1GUI\s0 or non-GUI (parsing the kernel
command line):
.PP
.Vb 4
\& main.c ──────┬─────▶ gui.c ──────┬─────▶ conversion.c
\&              │                   │
\&              │                   │
\&              └────▶ kernel.c ────┘
.Ve
.PP
but both paths call back to the \fIconversion.c\fR function \f(CW\*(C`start_conversion\*(C'\fR
to run the remote virt\-v2v.
.PP
The main task of \fIgui.c\fR/\fIkernel.c\fR is to populate the virt\-v2v
configuration (\fIconfig.c\fR).
.PP
During conversion, we need to establish ssh connections, and that is done
using two libraries:
.PP
.Vb 1
\& conversion.c ──────▶ ssh.c ──────▶ miniexpect.c
.Ve
.PP
where \fIssh.c\fR is responsible for managing ssh connections overall, and
\&\fIminiexpect.c\fR implements \*(L"expect-like\*(R" functionality for talking
interactively to the remote virt\-v2v conversion server.
.PP
(Note that miniexpect is a separate library with its own upstream, so if you
patch miniexpect.c, then please make sure the changes get reflected in
miniexpect’s upstream too:
\&\fIhttp://git.annexia.org/?p=miniexpect.git;a=summary\fR)
.SH "MAINTAINER TASKS"
.IX Header "MAINTAINER TASKS"
.SS "\s-1MAINTAINER MAKEFILE TARGETS\s0"
.IX Subsection "MAINTAINER MAKEFILE TARGETS"
These \f(CW\*(C`make\*(C'\fR targets probably won’t work and aren't useful unless you are a
libguestfs maintainer.
.PP
\fImake maintainer-commit\fR
.IX Subsection "make maintainer-commit"
.PP
This commits everything in the working directory with the commit message
\&\f(CW\*(C`Version $(VERSION).\*(C'\fR.  You must update \fIconfigure.ac\fR, clean and rebuild
first.
.PP
\fImake maintainer-tag\fR
.IX Subsection "make maintainer-tag"
.PP
This tags the current \s-1HEAD\s0 commit with the tag \f(CW\*(C`v$(VERSION)\*(C'\fR and one of the
messages:
.PP
.Vb 1
\& Version $(VERSION) stable
\&
\& Version $(VERSION) development
.Ve
.PP
(See \*(L"\s-1LIBGUESTFS VERSION NUMBERS\*(R"\s0 in \fBguestfs\fR\|(3) for the difference between a
stable and development release.)
.PP
\fImake maintainer-check-authors\fR
.IX Subsection "make maintainer-check-authors"
.PP
Check that all authors (found in git commit messages) are included in the
\&\fIgenerator/authors.ml\fR file.
.PP
\fImake maintainer-check-extra-dist\fR
.IX Subsection "make maintainer-check-extra-dist"
.PP
This rule must be run after \f(CW\*(C`make dist\*(C'\fR (so there is a tarball in the
working directory).  It compares the contents of the tarball with the
contents of git to ensure that no files have been missed from \fIMakefile.am\fR
\&\f(CW\*(C`EXTRA_DIST\*(C'\fR rules.
.PP
\fImake maintainer-upload-website\fR
.IX Subsection "make maintainer-upload-website"
.PP
This is used by the software used to automate libguestfs releases to copy
the libguestfs website to another git repository before it is uploaded to
the web server.
.SS "\s-1MAKING A STABLE RELEASE\s0"
.IX Subsection "MAKING A STABLE RELEASE"
When we make a stable release, there are several steps documented here.  See
\&\*(L"\s-1LIBGUESTFS VERSION NUMBERS\*(R"\s0 in \fBguestfs\fR\|(3) for general information about the
stable branch policy.
.IP "\(bu" 4
Check \f(CW\*(C`make && make check\*(C'\fR works on at least:
.RS 4
.IP "Fedora (x86\-64)" 4
.IX Item "Fedora (x86-64)"
.PD 0
.IP "Debian (x86\-64)" 4
.IX Item "Debian (x86-64)"
.IP "Ubuntu (x86\-64)" 4
.IX Item "Ubuntu (x86-64)"
.IP "Fedora (aarch64)" 4
.IX Item "Fedora (aarch64)"
.IP "Fedora (ppc64)" 4
.IX Item "Fedora (ppc64)"
.IP "Fedora (ppc64le)" 4
.IX Item "Fedora (ppc64le)"
.RE
.RS 4
.RE
.IP "\(bu" 4
.PD
Check \f(CW\*(C`./configure \-\-without\-libvirt\*(C'\fR works.
.IP "\(bu" 4
Finalize \fIguestfs\-release\-notes.pod\fR
.IP "\(bu" 4
Push and pull from Zanata.
.Sp
次を実行します:
.Sp
.Vb 1
\& zanata push
.Ve
.Sp
to push the latest \s-1POT\s0 files to Zanata.  Then run:
.Sp
.Vb 1
\& ./zanata\-pull.sh
.Ve
.Sp
which is a wrapper to pull the latest translated \fI*.po\fR files.
.IP "\(bu" 4
Consider updating gnulib to latest upstream version.
.IP "\(bu" 4
http://libguestfs.org/download の下に新しい安定版および開発版のディレクトリーを作成します。
.IP "\(bu" 4
Edit \fIwebsite/index.html.in\fR.
.IP "\(bu" 4
Set the version (in \fIconfigure.ac\fR) to the new \fIstable\fR version,
ie. 1.XX.0, and commit it:
.Sp
.Vb 6
\& ./localconfigure
\& make distclean \-k
\& ./localconfigure
\& make && make dist
\& make maintainer\-commit
\& make maintainer\-tag
.Ve
.IP "\(bu" 4
Create the stable branch in git:
.Sp
.Vb 2
\& git branch stable\-1.XX
\& git push origin stable\-1.XX
.Ve
.IP "\(bu" 4
Do a full release of the stable branch.
.IP "\(bu" 4
Set the version to the next development version and commit that.  Optionally
do a full release of the development branch.
.SH "INTERNAL DOCUMENTATION"
.IX Header "INTERNAL DOCUMENTATION"
This section documents internal functions inside libguestfs and various
utilities.  It is intended for libguestfs developers only.
.PP
This section is autogenerated from \f(CW\*(C`/**\*(C'\fR comments in source files, which
are marked up in \s-1POD\s0 format.
.PP
\&\fBThese functions are not publicly exported, and may change or be removed at
any time.\fR
.PP
_\|_INTERNAL_DOCUMENTATION_\|_
.SH "関連項目"
.IX Header "関連項目"
\&\fBguestfs\fR\|(3), \fBguestfs\-building\fR\|(1), \fBguestfs\-examples\fR\|(3),
\&\fBguestfs\-internals\fR\|(1), \fBguestfs\-performance\fR\|(1),
\&\fBguestfs\-release\-notes\fR\|(1), \fBguestfs\-testing\fR\|(1),
\&\fBlibguestfs\-test\-tool\fR\|(1), \fBlibguestfs\-make\-fixed\-appliance\fR\|(1),
http://libguestfs.org/.
.SH "著者"
.IX Header "著者"
Richard W.M. Jones (\f(CW\*(C`rjones at redhat dot com\*(C'\fR)
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (C) 2009\-2019 Red Hat Inc.
.SH "LICENSE"
.IX Header "LICENSE"
.SH "BUGS"
.IX Header "BUGS"
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
.PP
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
.PP
When reporting a bug, please supply:
.IP "\(bu" 4
The version of libguestfs.
.IP "\(bu" 4
Where you got libguestfs (eg. which Linux distro, compiled from source, etc)
.IP "\(bu" 4
Describe the bug accurately and give a way to reproduce it.
.IP "\(bu" 4
Run \fBlibguestfs\-test\-tool\fR\|(1) and paste the \fBcomplete, unedited\fR
output into the bug report.