.\" 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 — розширення можливостей і участь у розробці libguestfs .SH "ОПИС" .IX Header "ОПИС" Цю сторінку підручника призначено для тих, хто хоче розширити можливості libguestfs власноруч. .SH "ПОЧАТКОВИЙ КОД" .IX Header "ПОЧАТКОВИЙ КОД" Код libguestfs зберігається у сховищі github https://github.com/libguestfs/libguestfs .PP Велика частина стереотипного коду у libguestfs (\s-1RPC,\s0 прив'язки, документація) створюється автоматично. Це означає, що у звичайному клоні сховища git не буде багатьох файлів, які є у архівах з початковим кодом. Вам доведеться запустити генератор (\f(CW\*(C`./autogen.sh && make \-C generator\*(C'\fR), щоб створити ці файли. .PP У libguestfs використовується система збирання на основі autotools, основними файлами якої є \fIconfigure.ac\fR і \fIMakefile.am\fR. Див. \*(L"СИСТЕМА ЗБИРАННЯ\*(R". .PP У підкаталозі \fIgenerator\fR міститься генератор та файли із описом програмного інтерфейсу. У підкаталозі \fIlib\fR міститься початковий код бібліотеки. У підкаталогах \fIappliance\fR та \fIdaemon\fR зберігається початковий код, який збирає базову систему, так код, який запускає базову систему, відповідно. Інші каталоги описано у розділі \*(L"ПІДКАТАЛОГИ ПОЧАТКОВОГО КОДУ\*(R" нижче. .PP Окрім того факту, що усі вхідні точки програмного інтерфейсу перебувають у певному створеному коді, сама бібліотека є простою. (Фактично, навіть створений код читається так самою легко, як і звичайний код.) Деякі дії виконуються суто у бібліотеці, їхній код написано мовою C, він зберігається у підкаталозі \fIlib\fR. Виконання інших дій переспрямовується до фонової служби, де (після певного скерування \s-1RPC\s0) їх реалізовано як функції мовою C у файлах підкаталогу \fIdaemon\fR. .PP Настанови щодо збирання з початкового коду наведено у підручнику \&\fBguestfs\-building\fR\|(1). .SS "ПІДКАТАЛОГИ ПОЧАТКОВОГО КОДУ" .IX Subsection "ПІДКАТАЛОГИ ПОЧАТКОВОГО КОДУ" У ієрархії початкового коду багато підкаталогів! На яких слід зосередити увагу передусім? На каталогах \fIlib\fR та \fIdaemon\fR, у яких міститься початковий код основи бібліотеки. \fIgenerator\fR містить код генератора, описаного вище, тому цей підкаталог також є важливим. Файл \fIMakefile.am\fR у кореневому каталозі містить цінні дані щодо порядку збирання коду у підкаталогах. І нарешті, якщо ви шукаєте код певного інструмента (наприклад \&\fIv2v\fR) або прив'язки до мови (наприклад \fIpython\fR), зверніться безпосередньо до відповідного підкаталогу, але пам'ятайте, що якщо ще не було запущено генератор, вам може здатися, що у початковому коді не вистачає багатьох файлів. .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" Скрипти доповнення команд у відповідь на натискання клавіші Tab. .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" Код програм \fBvirt\-cat\fR\|(1), \fBvirt\-filesystems\fR\|(1), \fBvirt\-log\fR\|(1), \&\fBvirt\-ls\fR\|(1) and \fBvirt\-tail\fR\|(1) та документація до них. .IP "\fIcommon\fR" 4 .IX Item "common" У підкаталозі \fIcommon\fR зберігаються різноманітні бібліотеки внутрішнього коду: .RS 4 .IP "\fIcommon/edit\fR" 4 .IX Item "common/edit" Загальний код для інтерактивного та неінтерактивного редагування файлів у файловій системі libguestfs. .IP "\fIcommon/errnostring\fR" 4 .IX Item "common/errnostring" Протоколом обміну даними, який використовується між бібліотекою і фоновою службою, запущеною у базовій системі, передбачено кодування номерів помилок у рядки, які обробляються цією бібліотекою. .IP "\fIcommon/miniexpect\fR" 4 .IX Item "common/miniexpect" Копія бібліотеки miniexpect з http://git.annexia.org/?p=miniexpect.git;a=summary. Використовується у virt\-p2v. .IP "\fIcommon/mlaugeas\fR" 4 .IX Item "common/mlaugeas" Прив'язки до бібліотеки Augeas. Їх запозичено з бібліотеки ocaml-augeas, http://git.annexia.org/?p=ocaml\-augeas.git .IP "\fIcommon/mlgettext\fR" 4 .IX Item "common/mlgettext" Невеличкий автоматично створений скрипт\-обгортка, який надає змогу збирати libguestfs з ocaml-gettext та без нього. Скрипт створюється за допомогою \&\fI./configure\fR. .IP "\fIcommon/mlpcre\fR" 4 .IX Item "common/mlpcre" Невибагливі до ресурсів прив'язки до OCaml бібліотеки сумісних із Perl формальних виразів (\s-1PCRE\s0). Зауважте, що цей код ніяким чином не пов'язано із бібліотекою ocaml-pcre, яку створив Markus Mottl. .IP "\fIcommon/mlprogress\fR" 4 .IX Item "common/mlprogress" Прив'язки OCaml до функцій смужки поступу (див. \fIcommon/progress\fR). .IP "\fIcommon/mlstdutils\fR" 4 .IX Item "common/mlstdutils" Бібліотека допоміжних функцій, які використовуються у багатьох місцях, суто мовою OCaml. .IP "\fIcommon/mltools\fR" 4 .IX Item "common/mltools" Допоміжні функції OCaml, які використовуються лише інструментами віртуалізації мовою OCaml (зокрема \f(CW\*(C`virt\-sysprep\*(C'\fR, \f(CW\*(C`virt\-v2v\*(C'\fR тощо) .IP "\fIcommon/mlutils\fR" 4 .IX Item "common/mlutils" Прив'язки до OCaml для функцій C у \f(CW\*(C`common/utils\*(C'\fR та деякі прив'язки \s-1POSIX,\s0 яких немає у стандартній бібліотеці OCaml. .IP "\fIcommon/mlvisit\fR" 4 .IX Item "common/mlvisit" Прив'язки до OCaml для функцій visit (див. \fIcommon/visit\fR). .IP "\fIcommon/mlxml\fR" 4 .IX Item "common/mlxml" Прив'язки OCaml для бібліотеки libxml2. .IP "\fIcommon/options\fR" 4 .IX Item "common/options" Загальна обробка параметрів для guestfish, guestmount та деяких інструментів віртуалізації. .IP "\fIcommon/parallel\fR" 4 .IX Item "common/parallel" Комплект бібліотек для паралельної обробки декількох доменів libvirt. .IP "\fIcommon/progress\fR" 4 .IX Item "common/progress" Загальний код для виведення смужок поступу. .IP "\fIcommon/protocol\fR" 4 .IX Item "common/protocol" Тут визначається протокол обміну даними, заснований на \s-1XDR,\s0 який використовується для спілкування між бібліотекою і фоновою службою у базовій системі. .IP "\fIcommon/qemuopts\fR" 4 .IX Item "common/qemuopts" Мінібібліотека для запису рядків команд qemu та файлів налаштувань qemu. .IP "\fIcommon/structs\fR" 4 .IX Item "common/structs" Загальний код для виведення та вивільнення структур libguestfs, який використовується у бібліотеці та деяких інструментах. .IP "\fIcommon/utils\fR" 4 .IX Item "common/utils" Різноманітні допоміжні функції, які використовуються у бібліотеці та інструментах. .IP "\fIcommon/visit\fR" 4 .IX Item "common/visit" Рекурсивний обхід ієрархії файлових систем guestfs. .IP "\fIcommon/windows\fR" 4 .IX Item "common/windows" Допоміжні функції для обробки літер дисків у Windows. .RE .RS 4 .RE .IP "\fIcontrib\fR" 4 .IX Item "contrib" Зовнішні внески, експериментальні частини. .IP "\fIcustomize\fR" 4 .IX Item "customize" Програма \fBvirt\-customize\fR\|(1) та документація до неї. .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) та документація до неї. .IP "\fIdiff\fR" 4 .IX Item "diff" Програма \fBvirt\-diff\fR\|(1) та документація до неї. .IP "\fIdocs\fR" 4 .IX Item "docs" Різноманітні сторінки підручника. .IP "\fIedit\fR" 4 .IX Item "edit" Програма \fBvirt\-edit\fR\|(1) та документація до неї. .IP "\fIexamples\fR" 4 .IX Item "examples" Код прикладів використання програмного інтерфейсу мовою C. .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), \s-1FUSE\s0 (файлова система у просторі користувача), яку зібрано на основі libguestfs. .IP "\fIgenerator\fR" 4 .IX Item "generator" Критично важливий засіб створення коду, використовується для автоматичного створення значного обсягу важливого коду мовою C, зокрема для \s-1RPC\s0 та прив'язок. .IP "\fIget-kernel\fR" 4 .IX Item "get-kernel" Програма \fBvirt\-get\-kernel\fR\|(1) та документація до неї. .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" Логотип, який використовується на сайті. До речі, ім'я рибки — Артур. .IP "\fIm4\fR" 4 .IX Item "m4" Макроси M4, які використовуються autoconf. Див. \*(L"СИСТЕМА ЗБИРАННЯ\*(R". .IP "\fImake-fs\fR" 4 .IX Item "make-fs" Програма \fBvirt\-make\-fs\fR\|(1) та документація до неї. .IP "\fIp2v\fR" 4 .IX Item "p2v" Програма \fBvirt\-p2v\fR\|(1), документація та скрипти для збирання \s-1ISO\s0 або образу диска virt\-p2v. .IP "\fIpo\fR" 4 .IX Item "po" Переклади простих рядків gettext. .IP "\fIpo-docs\fR" 4 .IX Item "po-docs" Інфраструктура збирання та файли \s-1PO\s0 перекладів сторінок підручника та файлів \&\s-1POD.\s0 Колись ми об'єднаємо ці дані з каталогом \fIpo\fR, але цей процес є доволі складним. .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" Файли та інші тестові дані, які використовуються при тестуванні. .IP "\fItest-tool\fR" 4 .IX Item "test-tool" Засіб тестування, який допоможе визначити кінцевим користувачам, чи працюватиме їхня комбінація qemu/ядро з libguestfs. .IP "\fItmp\fR" 4 .IX Item "tmp" Використовується для тимчасових файлів під час тестування (замість \fI/tmp\fR та подібних каталогів). Причиною створення є уможливлення запуску декількох тестів libguestfs паралельно без ризику перезапису базової системи набором тестів, який виконується паралельно із набором, за допомогою якого було створено базову систему. .IP "\fItools\fR" 4 .IX Item "tools" Засоби командного рядка, які написано мовою програмування Perl (\fBvirt\-win\-reg\fR\|(1) та багато інших). .IP "\fIutils\fR" 4 .IX Item "utils" Різноманітні допоміжні програми, зокрема \f(CW\*(C`boot\-benchmark\*(C'\fR. .IP "\fIv2v\fR" 4 .IX Item "v2v" Програма \fBvirt\-v2v\fR\|(1) та документація до неї. .IP "\fIwebsite\fR" 4 .IX Item "website" Файли сайта http://libguestfs.org. .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 "СИСТЕМА ЗБИРАННЯ" .IX Subsection "СИСТЕМА ЗБИРАННЯ" Libguestfs використовує систему збирання \s-1GNU\s0 autotools (autoconf, automake, libtool). .PP Скрипт \fI./configure\fR створюється на основі \fIconfigure.ac\fR і \&\fIm4/guestfs\-*.m4\fR. Більшу частину вмісту скрипту configure складають дані з багатьох файлів макросів m4, поділених за розділами, наприклад, \&\fIm4/guestfs\-daemon.m4\fR призначено для обробки залежностей фонової служби (daemon). .PP Завданням файла \fIMakefile.am\fR на верхньому рівні є визначення списку підкаталогів (\f(CW\*(C`SUBDIRS\*(C'\fR) у порядку їхнього збирання. .PP \&\fIcommon\-rules.mk\fR включається до усіх файлів \fIMakefile.am\fR (верхнього рівня та підкаталогів). \fIsubdir\-rules.mk\fR включається лише до файлів \&\fIMakefile.am\fR у підкаталогах. .PP Цілей збирання багато. Скористайтеся цією командою, щоб побачити список: .PP .Vb 1 \& make help .Ve .SH "РОЗШИРЕННЯ МОЖЛИВОСТЕЙ LIBGUESTFS" .IX Header "РОЗШИРЕННЯ МОЖЛИВОСТЕЙ LIBGUESTFS" .SS "ДОДАВАННЯ НОВИХ ПРОГРАМНИХ ІНТЕРФЕЙСІВ" .IX Subsection "ДОДАВАННЯ НОВИХ ПРОГРАМНИХ ІНТЕРФЕЙСІВ" Оскільки більша частина стереотипного коду у libguestfs створюється у автоматичному режимі, розширити програмний інтерфейс libguestfs доволі просто. .PP Щоб додати нову дію програмного інтерфейсу, слід внести дві зміни: .IP "1." 4 Вам слід додати опис виклику (назву, параметри, тип значення, яке повертається, тести, документацію) до \fIgenerator/actions_*.ml\fR і, можливо, до \fIgenerator/proc_nr.ml\fR. .Sp Існує два різновиди дій програмного інтерфейсу. Тип залежить від того, проходить виклик до базової системи через фонову службу, чи обслуговується лише засобами бібліотеки (див. \*(L"АРХІТЕКТУРА\*(R" in \fBguestfs\-internals\fR\|(1)). \*(L"guestfs_sync\*(R" in \fBguestfs\fR\|(3) є прикладом дій першого типу, оскільки синхронізація відбувається у базовій системі. \*(L"guestfs_set_trace\*(R" in \fBguestfs\fR\|(3) є прикладом дій другого типу, оскільки прапорець трасування обслуговується у дескрипторі, а усе трасування виконується на боці бібліотеки. .Sp Більшість нових дій належить до першого типу, тому їхні записи додаються до списку \f(CW\*(C`daemon_functions\*(C'\fR. У кожної функції є унікальний номер процедури, який використовується у протоколі \s-1RPC,\s0 який пов'язується із цією дією під час оприлюднення версії libguestfs і який не можна використовувати повторно. Знайдіть останній номер процедури і додайте до нього одиницю, щоб отримати ваш номер. .Sp Дії другого типу, які пов'язано лише з бібліотекою, слід додавати до списку \&\f(CW\*(C`non_daemon_functions\*(C'\fR. Оскільки ці функції обслуговуються бібліотекою і не поширюються механізмом \s-1RPC\s0 до фонової служби, ці функції не потребують номеру процедури; отже, для них встановлюється номер процедури \f(CW\*(C`\-1\*(C'\fR. .IP "2." 4 Реалізація дії (мовою C): .Sp Для дій фонової служби слід реалізувати функцію \f(CW\*(C`do_<назва>\*(C'\fR у каталозі \f(CW\*(C`daemon/\*(C'\fR. .Sp Для дій бібліотеки слід реалізувати функцію \f(CW\*(C`guestfs_impl_<назва>\*(C'\fR у каталозі \f(CW\*(C`lib/\*(C'\fR. .Sp У обох випадках скористайтеся якоюсь іншою функцією як прикладом реалізації. .IP "3." 4 Альтернатива кроку 2: починаючи з версії libguestfs 1.38, дії фонової служби може бути реалізовано мовою OCaml. Вам слід встановити прапорець \f(CW\*(C`impl = OCaml ...\*(C'\fR у генераторі. Прикладом може слугувати файл \fIdaemon/file.ml\fR. .PP Після внесення цих змін скористайтеся командою \f(CW\*(C`make\*(C'\fR для збирання. .PP Зауважте, що вам не потрібно реалізовувати \s-1RPC,\s0 прив'язки до мов, сторінки підручника або щось інше. Усе це буде створено автоматично на основі опису OCaml. .PP \fIДодавання тестів для програмного інтерфейсу\fR .IX Subsection "Додавання тестів для програмного інтерфейсу" .PP До кожного виклику програмного інтерфейсу можна не додавати тести або додавати будь\-яку кількість тестів. Тести може бути додано або як частину опису програмного інтерфейсу (\fIgenerator/actions_*.ml\fR), або у деяких рідкісних випадках, додати скрипт до \f(CW\*(C`tests/*/\*(C'\fR. Зауважте, що додавання скрипту до \f(CW\*(C`tests/*/\*(C'\fR уповільнює тестування, тому, якщо можна, користуйтеся першим зі способів. .PP Нижче описано тестове середовище, яке використовується при додавання тесту програмного інтерфейсу до \fIactions_*.ml\fR. .PP У середовищі тестування 4 блокових пристрої: .IP "\fI/dev/sda\fR 2 ГБ" 4 .IX Item "/dev/sda 2 ГБ" Блоковий пристрій загального типу для тестування. .IP "\fI/dev/sdb\fR 2 ГБ" 4 .IX Item "/dev/sdb 2 ГБ" \&\fI/dev/sdb1\fR — файлова система ext2, яка використовується для тестування дій із запису до файлової системи. .IP "\fI/dev/sdc\fR 10 МБ" 4 .IX Item "/dev/sdc 10 МБ" Використовується для тестів, у яких потрібні два блокових пристрої. .IP "\fI/dev/sdd\fR" 4 .IX Item "/dev/sdd" \&\s-1ISO\s0 із фіксованим вмістом (див. \fIimages/test.iso\fR). .PP Щоб мати змогу виконувати тестування у прийнятні строки, базову систему та блокові пристрої libguestfs слід повторно використовувати у тестах. Отже, не намагайтеся тестувати \*(L"guestfs_kill_subprocess\*(R" in \fBguestfs\fR\|(3) :\-x .PP Кожен тест запускає початковий сценарій, який вибирається за допомогою одного з виразів \f(CW\*(C`Init*\*(C'\fR, описаний у \fIgenerator/types.ml\fR. Сценарій ініціалізує диски, згадані вище, у спосіб, який задокументовано у \&\fItypes.ml\fR. Ви не повинні робити у своєму коді жодних припущень щодо попереднього вмісту інших дисків, які не ініціалізовано. .PP Ви можете додати інструкцію щодо попередніх вимог до будь\-якого окремого тесту. Це динамічна перевірка, яка, якщо її не буде пройдено, призведе до пропускання тесту. Це корисно для тестування команди, яка може не працювати у всіх різновидах збірок libguestfs. Тест, для якого попередньою вимогою є \&\f(CW\*(C`Always\*(C'\fR, запускається безумовно. .PP Крім того, пакувальники можуть пропускати окремі тести встановленням відповідних змінних середовища до запуску \f(CW\*(C`make check\*(C'\fR. .PP .Vb 1 \& SKIP_TEST__=1 .Ve .PP Приклад: \f(CW\*(C`SKIP_TEST_COMMAND_3=1\*(C'\fR призведе до пропускання тесту 3 у \&\*(L"guestfs_command\*(R" in \fBguestfs\fR\|(3). .PP або: .PP .Vb 1 \& SKIP_TEST_=1 .Ve .PP Приклад: \f(CW\*(C`SKIP_TEST_ZEROFREE=1\*(C'\fR призводить до пропускання усіх тестів \&\*(L"guestfs_zerofree\*(R" in \fBguestfs\fR\|(3). .PP Пакувальники можуть обмежити тестування певним набором тестів, встановлюючи, наприклад, таке: .PP .Vb 1 \& TEST_ONLY="vfs_type zerofree" .Ve .PP Див. \fItests/c\-api/tests.c\fR, щоб дізнатися більше про те, як працюють ці змінні середовища. .PP \fIДіагностика нових програмних інтерфейсів\fR .IX Subsection "Діагностика нових програмних інтерфейсів" .PP Перевірте нові можливості, перш ніж записувати їх до сховища коду. .PP Для перевірки нових команд ви можете скористатися guestfish. .PP Діагностика фонової служби є проблематичною, оскільки вона виконується у мінімалістичному середовищі. Втім, ви можете скористатися виведенням повідомлень за допомогою fprintf у фоновій службі до stderr. Повідомлення можна буде переглядати за допомогою \f(CW\*(C`guestfish \-v\*(C'\fR. .SS "ДОДАВАННЯ НОВОЇ ПРИВ’ЯЗКИ ДО МОВИ" .IX Subsection "ДОДАВАННЯ НОВОЇ ПРИВ’ЯЗКИ ДО МОВИ" Усі прив'язки до мов має бути створено відповідним засобом (див. підкаталог \&\fIgenerator\fR). .PP Документації з цього питання ще не написано. Пропонуємо вам звернутися до коду наявних прив'язок, наприклад \fIgenerator/ocaml.ml\fR або \&\fIgenerator/perl.ml\fR. .PP \fIДодавання тестів для прив'язок до мов\fR .IX Subsection "Додавання тестів для прив'язок до мов" .PP Прив'язки до мов мають постачатися із тестами. Раніше тестування прив'язок до мов було суто ситуативним, але тепер ми намагаємося формалізувати набір тестів, які має використовувати кожна прив'язка до мови. .PP У поточній версії повний набір тестів реалізовано лише для прив'язок до OCaml і Perl. Канонічним набором є набір для OCaml, тому вам слід емулювати тести саме для OCaml. .PP Ось схема нумерації, яка використовується у тестах: .PP .Vb 1 \& \- 000+, базові перевірки: \& \& 010 завантажити бібліотеку \& 020 створення \& 030 прапорці створення \& 040 створення декількох дескрипторів \& 050 налаштовування тестування та отримання властивостей налаштовування \& 060 явне закриття \& 065 неявне закриття (у мовах із збирачем сміття) \& 070 аргументи параметрів \& 080 версія \& 090 повернуті значення \& \& \- 100 запуск, створення розділів та логічних томів, а також файлових систем \& \& \- події 400+: \& \& 410 подія закриття \& 420 повідомлення журналу \& 430 повідомлення щодо поступу \& \& \- 800+ тести на регресії (специфічні для мови) \& \& \- 900+ будь\-які інші нетипові тести для мови .Ve .PP Для заощадження часу під час виконання тестування дескриптор запускатимуть лише 100, 430, 800+, 900+. .SS "ФОРМАТУВАННЯ КОДУ" .IX Subsection "ФОРМАТУВАННЯ КОДУ" Наш початковий код мовою C загалом відповідає деяким базовим вимогам щодо форматування коду. Наявна кодова база є повністю однорідною у цьому сенсі, але ми б хотіли, щоб увесь новий код також було форматовано подібним чином. Якщо коротко, користуйтеся пробілами, а не символами табуляції, використовуйте додаткові 2 пробіли на кожному із рівнів відступів, у інших аспектах форматування слідуйте стилю книги Кернігана та Річі. .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)))) \& \& ;;; Під час редагування початкового коду C у libguestfs користуйтеся цим стилем. \& (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 "ТЕСТУВАННЯ ВНЕСЕНИХ ВАМИ ЗМІН" Перетворити попередження на повідомлення про помилки під час розробки, щоб ці попередження не ігнорувалися: .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 Реалізовано за допомогою типової цілі automake \f(CW\*(C`TESTS\*(C'\fR. Докладніше про цю ціль можна дізнатися з документації до automake. .ie n .IP """make check\-valgrind""" 4 .el .IP "\f(CWmake check\-valgrind\fR" 4 .IX Item "make check-valgrind" Запускає підмножину комплекту тестування у valgrind. .Sp Див. \*(L"\s-1VALGRIND\*(R"\s0 нижче. .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" Запускає підмножину комплекту тестування у valgrind з використанням локально встановлених гостьових систем libvirt (лише для читання). .ie n .IP """make check\-direct""" 4 .el .IP "\f(CWmake check\-direct\fR" 4 .IX Item "make check-direct" Виконує усі тести за допомогою типового модуля роботи із базовою системою. Працює, лише якщо за допомогою \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" Запустити підмножину комплексу тестів під керуванням valgrind з використанням типового модуля базової системи. .ie n .IP """make check\-uml""" 4 .el .IP "\f(CWmake check\-uml\fR" 4 .IX Item "make check-uml" Виконує усі тести з використанням модуля режиму користувача у Linux. .Sp Оскільки немає стандартизованого місця для зберігання ядра Linux з режимом користувача, вам \fIслід\fR встановити значення \f(CW\*(C`LIBGUESTFS_HV\*(C'\fR таким чином, щоб воно вказувало на образ ядра. Приклад: .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" Виконує усі тести з використанням модуля режиму користувача Linux під керуванням valgrind. .Sp Як і вище, вам слід встановити значення \f(CW\*(C`LIBGUESTFS_HV\*(C'\fR так, щоб воно вказувало на ядро. .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" Виконує усі тести з використанням локального виконуваного файла qemu. Шукає виконуваний файл qemu за допомогою змінної \s-1QEMUDIR\s0 (типове значення \&\fI\f(CI$HOME\fI/d/qemu\fR), але ви можете встановити інший каталог за допомогою рядка команди. Приклад: .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" Виконує усі тести за допомогою локальної копії libvirt. Працює, лише якщо за допомогою \f(CW\*(C`./configure \-\-with\-default\-backend=libvirt\*(C'\fR було вибрано модуль libvirt. .Sp Пошук libvirt виконуватиметься у каталозі \s-1LIBVIRTDIR\s0 (типово, \&\fI\f(CI$HOME\fI/d/libvirt\fR), але ви можете вказати інший каталог у рядку команди. Приклад: .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" Запускає повільні тести або тести, які виконуються довго. Такі тести типово не запускаються. .Sp Щоб позначити тест як повільний або такий, який виконується довго: .RS 4 .IP "\(bu" 4 Додайте це до списку \f(CW\*(C`TESTS\*(C'\fR у \fIMakefile.am\fR, подібно до звичайного тесту. .IP "\(bu" 4 Змініть тест так, щоб у ньому перевірялася умова для змінної середовища \&\f(CW\*(C`SLOW=1\*(C'\fR, і якщо таке значення змінної \fIне\fR встановлено, тест пропускався (тобто повертав код виходу 77). Якщо використовується \f(CW$TEST_FUNCTIONS\fR, для цього ви можете викликати функцію \f(CW\*(C`slow_test\*(C'\fR. .IP "\(bu" 4 Додайте змінну \f(CW\*(C`SLOW_TESTS\*(C'\fR до файла \fIMakefile.am\fR зі значенням\-списком повільних тестів. .IP "\(bu" 4 Додайте таке правило до \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" Запускає деякі тести, які потребують прав доступу користувача root. Ці тести, як ми припускаємо, безпечні, але вам слід вжити усіх додаткових засобів захисту. Вам слід запускати цю команду від імені root (наприклад, за допомогою явного використання \fBsudo\fR\|(8)). .Sp Щоб позначити тест як такий, що вимагає прав доступу користувача root: .RS 4 .IP "\(bu" 4 Додайте це до списку \f(CW\*(C`TESTS\*(C'\fR у \fIMakefile.am\fR, подібно до звичайного тесту. .IP "\(bu" 4 Внесіть зміни до тесту так, щоб тест перевіряв, чи euid == 0, і якщо це значення \fIне\fR встановлено, тест пропускається (тобто повертає код виходу 77). Якщо використовується \f(CW$TEST_FUNCTIONS\fR, ви можете викликати функцію \&\f(CW\*(C`root_test\*(C'\fR для цього. .IP "\(bu" 4 Додайте змінну \f(CW\*(C`ROOT_TESTS\*(C'\fR до файла \fIMakefile.am\fR зі значенням\-списком тестів для root. .IP "\(bu" 4 Додайте таке правило до \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" Еквівалент запуску усіх правил \f(CW\*(C`make check*\*(C'\fR, окрім \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" Виконує підмножину правил \f(CW\*(C`make check*\*(C'\fR, які слід передати до створення архіву tar. У поточній версії це: .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" Запустити \f(CW\*(C`make check\*(C'\fR для встановленої копії libguestfs. .Sp Версії встановленої libguestfs, тестування якої виконується, та версія у ієрархії початкового коду libguestfs мають збігатися. .Sp Команди: .Sp .Vb 4 \& ./autogen.sh \& make clean ||: \& make \& make installcheck .Ve .SS "\s-1VALGRIND\s0" .IX Subsection "VALGRIND" Коли ви віддаєте команду \f(CW\*(C`make check\-valgrind\*(C'\fR, відбувається пошук будь\-якого \fIMakefile.am\fR у ієрархії коду, де є ціль \f(CW\*(C`check\-valgrind:\*(C'\fR, і його запуск. .PP Правильно написати \fIMakefile.am\fR і тести, щоб скористатися valgrind і паралельним тестуванням automake, не так уже і просто. .PP Якщо ваш тести запускаються за допомогою скриптової обгортки для командної оболонки, у обгортці слід скористатися таким кодом: .PP .Vb 1 \& $VG virt\-foo .Ve .PP а у \fIMakefile.am\fR слід вказати: .PP .Vb 2 \& check\-valgrind: \& make VG="@VG@" check .Ve .PP Втім, якщо ваші виконувані файли запускаються безпосередньо з правила \&\f(CW\*(C`TESTS\*(C'\fR, до \fIMakefile.am\fR слід внести такий рядок: .PP .Vb 1 \& LOG_COMPILER = $(VG) \& \& check\-valgrind: \& make VG="@VG@" check .Ve .PP Який би з варіантів ви не реалізовували, слід перевіряти, чи ту програму ви тестуєте, шляхом уважного вивчення файлів журналу \fItmp/valgrind*\fR. .SS "НАДСИЛАННЯ ЛАТОК" .IX Subsection "НАДСИЛАННЯ ЛАТОК" Надсилайте латки до списку листування, http://www.redhat.com/mailman/listinfo/libguestfs і копію повідомлення до rjones@redhat.com. .PP Можете не підписуватися на список листування, якщо не хочете. Втім, для непідписаних користувачів повідомлення з'являються у списку із затримкою, потрібною на модерацію. .SS "НЕТИПОВІ ЗАСОБИ ФОРМАТУВАННЯ \s-1PRINTF\s0 У ФОНОВІЙ СЛУЖБІ" .IX Subsection "НЕТИПОВІ ЗАСОБИ ФОРМАТУВАННЯ PRINTF У ФОНОВІЙ СЛУЖБІ" У коді фонової служби напис створено нетипові форматувальники printf \f(CW%Q\fR і \&\f(CW%R\fR, які використовуються для режиму встановлення лапок у командній оболонці. .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" Те саме, що і \f(CW%Q\fR, але рядок вважатиметься шляхом із префіксом sysroot. .PP Приклад: .PP .Vb 1 \& asprintf (&cmd, "cat %R", path); .Ve .PP дасть \f(CW\*(C`cat /sysroot/якийсь\e шлях\e із\e пробілами\*(C'\fR .PP \&\fIЗауваження:\fR \fIне\fR використовуйте ці замінники, якщо передаєте параметри функціям \f(CW\*(C`command{,r,v,rv}()\*(C'\fR. У параметрах цих функцій НЕ потрібно нічого міняти, оскільки вони не передаються крізь командну оболонку (а безпосередньо передаються функції exec). Втім, ймовірно, варто використовувати функцію \f(CW\*(C`sysroot_path()\*(C'\fR. .SS "ПІДТРИМКА ІНТЕРНАЦІОНАЛІЗАЦІЇ (I18N)" .IX Subsection "ПІДТРИМКА ІНТЕРНАЦІОНАЛІЗАЦІЇ (I18N)" У нашій бібліотеці передбачено можливість інтернаціоналізації (засобами gettext). .PP Втім, багато повідомлень надходять від фонової служби, і у поточній версії ми їх не перекладаємо. Однією з причин цього є те, що, загалом, у базовій системі немає файлів локалей, оскільки вони досить об'ємні. Тому для реалізації можливості перекладу нам довелося б додати ці файли і скопіювати наші файли \s-1PO\s0 до базової системи. .PP Діагностичні повідомлення не перекладаються, оскільки їх призначено для програмістів. .SH "ІНШІ ТЕМИ" .IX Header "ІНШІ ТЕМИ" .SS "ЯК КОМПІЛЮЮТЬСЯ І КОМПОНУЮТЬСЯ ПРОГРАМИ \s-1OCAML\s0" .IX Subsection "ЯК КОМПІЛЮЮТЬСЯ І КОМПОНУЮТЬСЯ ПРОГРАМИ OCAML" Більша частина цього розділу присвячена питанню «як ми змусили automake і ocamlopt працювати разом», оскільки самі програми OCaml зібрати легко. .PP У automake немає вбудованої підтримки програм OCaml, ocamlc та ocamlopt. Наш підхід полягає у обробці програм OCaml як програм C, які можуть містити такі «інші об'єкти» (\f(CW"DEPENDENCIES"\fR у термінології automake), які можуть бути об'єктами OCaml. Це працює, оскільки програми OCaml зазвичай містять файли C для природних прив'язок до бібліотек тощо. .PP Отже, типова програма описується як список файлів з її кодом мовою C: .PP .Vb 1 \& virt_v2v_SOURCES = ... utils\-c.c xml\-c.c .Ve .PP Для програм, які не містять явних початкових текстів мовою C ми створюємо порожній файл \fIdummy.c\fR і додаємо його до списку замість справжніх файлів: .PP .Vb 1 \& virt_resize_SOURCES = dummy.c .Ve .PP Об'єкти OCaml, які містять більшу частину коду, потрапляють до списку як залежності automake (інші залежності також можуть потрапляти до списку): .PP .Vb 1 \& virt_v2v_DEPENDENCIES = ... cmdline.cmx v2v.cmx .Ve .PP Окрім того, єдиною іншою річчю, яку нам слід зробити, є надання нетипової команди компонування. Ця команда потрібна, оскільки інакше automake не зможе зібрати команду ocamlopt, список об'єктів та бібліотеки \f(CW\*(C`\-cclib\*(C'\fR у належному порядку. .PP .Vb 2 \& virt_v2v_LINK = \e \& $(top_srcdir)/ocaml\-link.sh \-cclib \*(Aq\-lutils \-lgnu\*(Aq \-\- ... .Ve .PP Справжні правила, із якими ви можете ознайомитися у файлі \fIv2v/Makefile.am\fR є дещо складнішими за ці, оскільки у них ще треба обробити: .IP "\(bu" 4 Компіляцію у байткод або природний код системи. .IP "\(bu" 4 Взірцеві правила, потрібні для збирання коду OCaml у об'єкти. .Sp Ці правила тепер зберігаються у \fIsubdir\-rules.mk\fR на верхньому рівні ієрархії коду. Цей файл включається до усіх підкаталогів \fIMakefile.am\fR. .IP "\(bu" 4 Додавання файлів початкового коду OCaml до \f(CW\*(C`EXTRA_DIST\*(C'\fR. .Sp Automake не зможе визначити повний список початкових кодів для виконуваного файла, тому програма не зможе додати відповідні файли автоматично. .SS "\s-1VIRT\-V2V\s0" .IX Subsection "VIRT-V2V" Спочатку трохи історії. Протягом свого існування програма virt\-v2v зазнала принаймні двох повних переписувань, тому поточна версія є принаймні третьою (ми не маємо планів переписувати її ще раз). Попередню версію було написано мовою Perl. Її код і досі зберігається тут: https://git.fedorahosted.org/git/virt\-v2v.git .PP Поточну версію було започатковано як майже порядково переписану з Perl на OCaml + C, і вона все ще зберігає повністю подібну структуру. Тому, якщо ви не розумієте якихось подробиць щодо коду (особливо подробиць щодо перетворення гостьових систем), вам може допомогти читання коду мовою Perl. .PP Ось файли, з яких варто розпочати читання цього коду: .IP "\(bu" 4 \&\fItypes.mli\fR .IP "\(bu" 4 \&\fIv2v.ml\fR .PP У \fItypes.mli\fR визначаються усі структури, які використовуються і передаються під час обміну даними між різними частинами програми. У \&\fIv2v.ml\fR реалізовано керування роботою програми на різних етапах. .PP Після вивчення цих файлів ви можете перейти до вивчення модулів вхідних даних (\fIinput_*\fR), модулів вихідних даних (\fIoutput_*\fR) або модулів перетворення (\fIconvert_*\fR). Модулі вхідних і вихідних даних визначають перелік варіантів для параметрів \fI\-i\fR та \fI\-o\fR (див. підручник). Модулі перетворення визначають, із якими типами гостьових систем ми можемо працювати і які конкретно кроки слід виконати для їхнього перетворення. .PP Усі інші файли у цьому каталозі є певним чином супровідними модулями або бібліотеками. Частину коду написано мовою C, особливо там, де ми хотіли використати зовнішні бібліотеки C, зокрема libxml2. .SS "\s-1VIRT\-P2V\s0" .IX Subsection "VIRT-P2V" Virt\-p2v є оболонкою над virt\-v2v. Інакше кажучи, усе, що робить ця програма, — це працює як оболонка із графічним інтерфейсом, для виконання самого перетворення ця програма викликає virt\-v2v. Тому, більша частина коду мовою C у підкаталозі \fIp2v/\fR є кодом Gtk (графічного інтерфейсу) або супутнім кодом для обміну даними із віддаленим сервером перетворення. У virt\-v2v немає ніякого спеціальної підтримки фізичних машин. Дані фізичним машин перетворюються у той самий спосіб, що і дані сторонніх віртуальних машин. .PP \fIЯк запустити virt\-p2v\fR .IX Subsection "Як запустити virt-p2v" .PP Ви можете запустити виконуваний файл \fIp2v/virt\-p2v\fR безпосередньо, але програма спробує перетворити справжній диск \fI/dev/sda\fR вашої системи, що навряд чи дасть бажані результати. Втім, virt\-p2v також має тестовий режим, у якому ви можете вказати тестовий диск: .PP .Vb 1 \& make \-C p2v run\-virt\-p2v\-directly .Ve .PP Це обгортка до параметра \fI\-\-test\-disk\fR \fBvirt\-p2v\fR\|(1). Ви можете керувати диском «фізичної машини» встановленням значення \f(CW\*(C`PHYSICAL_MACHINE\*(C'\fR, яке вказує на образ диска. .PP Реалістичнішим тестом є запуск virt\-p2v у віртуальній машині на локальній машині. Для цього зробіть так: .PP .Vb 1 \& make \-C p2v run\-virt\-p2v\-in\-a\-vm .Ve .PP Ця команда також запускає qemu для диска «фізичної машини» (вказати яку можна за допомогою встановлення значення змінної \f(CW\*(C`PHYSICAL_MACHINE\*(C'\fR), віртуального компакт\-диска та різноманітних мережевих карток для тестування. Ви можете змінити виконуваний файл qemu і додати параметри команди qemu встановленням значень параметрів \f(CW\*(C`QEMU\*(C'\fR і/або \f(CW\*(C`QEMU_OPTIONS\*(C'\fR у командному рядку make. .PP Запущена у третій спосіб програма virt\-p2v досить точно імітує програму, що отримується за допомогою \s-1PXE,\s0 а потім виконує автоматичне перетворення початкової фізичної машини (спосіб без графічного інтерфейсу — див. наступний розділ нижче): .PP .Vb 1 \& make \-C p2v run\-virt\-p2v\-non\-gui\-conversion .Ve .PP \fIЯк розібратися у коді virt\-p2v\fR .IX Subsection "Як розібратися у коді virt-p2v" .PP \&\fIДив. також:\fR \*(L"ЯК ПРАЦЮЄ \s-1VIRT\-P2V\*(R"\s0 in \fBvirt\-p2v\fR\|(1) .PP Існує два шляхи крізь код, з графічним інтерфейсом або без графічного інтерфейсу (обробка командного рядка ядра): .PP .Vb 4 \& main.c ──────┬─────▶ gui.c ──────┬─────▶ conversion.c \& │ │ \& │ │ \& └────▶ kernel.c ────┘ .Ve .PP але обидва шляхи виконують зворотний виклик функції \f(CW\*(C`start_conversion\*(C'\fR з \&\fIconversion.c\fR для запуску віддаленого virt\-v2v. .PP Основним завданням \fIgui.c\fR/\fIkernel.c\fR є заповнення параметрів налаштовування virt\-v2v (\fIconfig.c\fR). .PP Під час перетворення слід встановити з'єднання ssh, і це виконується за допомогою двох бібліотек: .PP .Vb 1 \& conversion.c ──────▶ ssh.c ──────▶ miniexpect.c .Ve .PP де \fIssh.c\fR відповідає за керування з'єднаннями ssh взагалі, а \&\fIminiexpect.c\fR реалізує expect\-подібні функціональні можливості для інтерактивного обміну даними із віддаленим сервером перетворення virt\-v2v. .PP (Зауважте, що miniexpect є окремою бібліотекою із власною основною гілкою розробки, отже, якщо ви накладаєте латку на miniexpect.c, будь ласка, переконайтеся, що зміни також надіслано до основної гілки розробки miniexpect: \fIhttp://git.annexia.org/?p=miniexpect.git;a=summary\fR) .SH "ЗАВДАННЯ ІЗ СУПРОВОДУ" .IX Header "ЗАВДАННЯ ІЗ СУПРОВОДУ" .SS "ЦІЛІ ДЛЯ СУПРОВІДНИКІВ У \s-1MAKEFILE\s0" .IX Subsection "ЦІЛІ ДЛЯ СУПРОВІДНИКІВ У MAKEFILE" Ці цілі \f(CW\*(C`make\*(C'\fR, ймовірно, не працюватимуть або не будуть корисними, якщо ви не є супровідником пакунків libguestfs. .PP \fImake maintainer-commit\fR .IX Subsection "make maintainer-commit" .PP Ця ціль вносить усі зміни із робочого каталогу до системи керування сховищем коду із повідомленням щодо внеску \f(CW\*(C`Version $(VERSION).\*(C'\fR. Вам слід спочатку оновити \fIconfigure.ac\fR, очистити ієрархію коду та виконати повторне збирання. .PP \fImake maintainer-tag\fR .IX Subsection "make maintainer-tag" .PP Ця команда створює мітку для поточного внеску у \s-1HEAD\s0 зі значенням мітки \&\f(CW\*(C`v$(VERSION)\*(C'\fR і одним із таких повідомлень: .PP .Vb 1 \& Version $(VERSION) stable \& \& Version $(VERSION) development .Ve .PP (Опис відмінностей між стабільним випуском і випуском, який перебуває у розробці, наведено у розділі \*(L"НУМЕРАЦІЯ ВЕРСІЙ \s-1LIBGUESTFS\*(R"\s0 in \fBguestfs\fR\|(3).) .PP \fImake maintainer-check-authors\fR .IX Subsection "make maintainer-check-authors" .PP Перевірити, чи усіх авторів (записи яких можна знайти у повідомленнях щодо внесків до git) включено до файла \fIgenerator/authors.ml\fR. .PP \fImake maintainer-check-extra-dist\fR .IX Subsection "make maintainer-check-extra-dist" .PP Це правило слід запускати після \f(CW\*(C`make dist\*(C'\fR (щоб у робочому каталозі уже був архів tar). Воно порівнює вміст архіву tar із даними у git з метою переконатися, що не пропущено жодного файла із правил \f(CW\*(C`EXTRA_DIST\*(C'\fR у \&\fIMakefile.am\fR. .PP \fImake maintainer-upload-website\fR .IX Subsection "make maintainer-upload-website" .PP Це правило використовується програмним забезпеченням автоматизації випусків libguestfs для копіювання сайта libguestfs до іншого сховища git до його вивантаження на вебсервер. .SS "СТВОРЕННЯ СТАБІЛЬНОГО ВИПУСКУ" .IX Subsection "СТВОРЕННЯ СТАБІЛЬНОГО ВИПУСКУ" Тут наведено документацію щодо створення стабільних випусків. Загальні правила щодо створення стабільних випусків наведено у розділі \&\*(L"НУМЕРАЦІЯ ВЕРСІЙ \s-1LIBGUESTFS\*(R"\s0 in \fBguestfs\fR\|(3). .IP "\(bu" 4 Перевірте, чи працює \f(CW\*(C`make && make check\*(C'\fR принаймні у таких системах: .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 Перевірте, чи працює \f(CW\*(C`./configure \-\-without\-libvirt\*(C'\fR. .IP "\(bu" 4 Внесіть завершальні зміни до \fIguestfs\-release\-notes.pod\fR .IP "\(bu" 4 Надіслати і отримати дані з Zanata. .Sp Віддайте команду: .Sp .Vb 1 \& zanata push .Ve .Sp щоб надіслати найсвіжіші файли \s-1POT\s0 на Zanata. Потім віддайте команду: .Sp .Vb 1 \& ./zanata\-pull.sh .Ve .Sp яка є обгорткою для команд отримання найсвіжіших перекладених файлів \&\fI*.po\fR. .IP "\(bu" 4 Оновіть gnulib до найсвіжішої версії основної гілки розробки. .IP "\(bu" 4 Створіть каталоги стабільної версії і версії у розробці на http://libguestfs.org/download. .IP "\(bu" 4 Внесіть зміни до \fIwebsite/index.html.in\fR. .IP "\(bu" 4 Встановіть версію (у \fIconfigure.ac\fR) у значення нової \fIстабільної\fR версії, тобто 1.XX.0, і запишіть версію: .Sp .Vb 6 \& ./localconfigure \& make distclean \-k \& ./localconfigure \& make && make dist \& make maintainer\-commit \& make maintainer\-tag .Ve .IP "\(bu" 4 Створіть стабільну гілку у git: .Sp .Vb 2 \& git branch stable\-1.XX \& git push origin stable\-1.XX .Ve .IP "\(bu" 4 Виконайте повноцінний випуск стабільної гілки. .IP "\(bu" 4 Встановіть значення номера наступної версії для розробки і запишіть його до сховища. Можна також створити повноцінний випуск із гілки для розробки. .SH "ВНУТРІШНЯ ДОКУМЕНТАЦІЯ" .IX Header "ВНУТРІШНЯ ДОКУМЕНТАЦІЯ" У цьому розділі наведено документацію щодо внутрішніх функцій libguestfs та різноманітних допоміжних програм. Вміст цього розділу буде цікавим лише для розробників libguestfs. .PP Цей розділ створено автоматично на основі тих коментарів \f(CW\*(C`/**\*(C'\fR у файлах початкового коду, які форматовано для використання у форматі \s-1POD.\s0 .PP \&\fBЦі функції не експортуються відкрито (public). Їх може бути змінено або вилучено у будь\-якій новішій версії.\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 "АВТОРСЬКІ ПРАВА" .IX Header "АВТОРСЬКІ ПРАВА" 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.