Manpages

НАЗВА

guestfs-hacking — розширення можливостей і участь у розробці libguestfs

ОПИС

Цю сторінку підручника призначено для тих, хто хоче розширити можливості libguestfs власноруч.

ПОЧАТКОВИЙ КОД

Код libguestfs зберігається у сховищі github https://github.com/libguestfs/libguestfs

Large amounts of boilerplate code in libguestfs (RPC, 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 ("./configure && make -C generator") in order to create those files.

У libguestfs використовується система збирання на основі autotools, основними файлами якої є configure.ac і Makefile.am. Див. "СИСТЕМА ЗБИРАННЯ".

У підкаталозі generator міститься генератор та файли із описом програмного інтерфейсу. У підкаталозі lib міститься початковий код бібліотеки. У підкаталогах appliance та daemon зберігається початковий код, який збирає базову систему, так код, який запускає базову систему, відповідно. Інші каталоги описано у розділі "ПІДКАТАЛОГИ ПОЧАТКОВОГО КОДУ" нижче.

Окрім того факту, що усі вхідні точки програмного інтерфейсу перебувають у певному створеному коді, сама бібліотека є простою. (Фактично, навіть створений код читається так самою легко, як і звичайний код.) Деякі дії виконуються суто у бібліотеці, їхній код написано мовою C, він зберігається у підкаталозі lib. Виконання інших дій переспрямовується до фонової служби, де (після певного скерування RPC) їх реалізовано як функції мовою C у файлах підкаталогу daemon.

Настанови щодо збирання з початкового коду наведено у підручнику guestfs-building(1).

ПІДКАТАЛОГИ ПОЧАТКОВОГО КОДУ
У ієрархії початкового коду багато підкаталогів! На яких слід зосередити увагу передусім? На каталогах lib та daemon, у яких міститься початковий код основи бібліотеки. generator містить код генератора, описаного вище, тому цей підкаталог також є важливим. Файл Makefile.am у кореневому каталозі містить цінні дані щодо порядку збирання коду у підкаталогах. І нарешті, якщо ви шукаєте код певного інструмента (наприклад customize) або прив’язки до мови (наприклад python), зверніться безпосередньо до відповідного підкаталогу, але пам’ятайте, що якщо ще не було запущено генератор, вам може здатися, що у початковому коді не вистачає багатьох файлів.
align

Програма virt-alignment-scan(1) та документація до неї.

appliance

Базова система libguestfs, скрипти збирання тощо.

bash

Скрипти доповнення команд у відповідь на натискання клавіші Tab.

build-aux

Різноманітні скрипти збирання, які використовуються autotools.

builder

Програма virt-builder(1) та документація до неї.

common

У підкаталозі common зберігаються різноманітні бібліотеки внутрішнього коду:
common/edit

Загальний код для інтерактивного та неінтерактивного редагування файлів у файловій системі libguestfs.

common/errnostring

Протоколом обміну даними, який використовується між бібліотекою і фоновою службою, запущеною у базовій системі, передбачено кодування номерів помилок у рядки, які обробляються цією бібліотекою.

common/mlcustomize

Код бібліотек, пов’язаних із "virt-customize", але використовується і в інших інструментах.

common/mlgettext

Невеличкий автоматично створений скрипт-обгортка, який надає змогу збирати libguestfs з ocaml-gettext та без нього. Скрипт створюється за допомогою ./configure.

common/mlpcre

Невибагливі до ресурсів прив’язки до OCaml бібліотеки сумісних із Perl формальних виразів (PCRE). Зауважте, що цей код ніяким чином не пов’язано із бібліотекою ocaml-pcre, яку створив Markus Mottl.

common/mlprogress

Прив’язки OCaml до функцій смужки поступу (див. common/progress).

common/mlstdutils

Бібліотека допоміжних функцій, які використовуються у багатьох місцях, суто мовою OCaml.

common/mltools

Допоміжні функції OCaml, які використовуються лише інструментами віртуалізації мовою OCaml (зокрема "virt-sysprep", "virt-customize" тощо)

common/mlutils

Прив’язки до OCaml для функцій C у "common/utils" та деякі прив’язки POSIX, яких немає у стандартній бібліотеці OCaml.

common/mlvisit

Прив’язки до OCaml для функцій visit (див. common/visit).

common/mlxml

Прив’язки OCaml для бібліотеки libxml2.

common/options

Загальна обробка параметрів для guestfish, guestmount та деяких інструментів віртуалізації.

common/parallel

Комплект бібліотек для паралельної обробки декількох доменів libvirt.

common/progress

Загальний код для виведення смужок поступу.

common/protocol

Тут визначається протокол обміну даними, заснований на XDR, який використовується для спілкування між бібліотекою і фоновою службою у базовій системі.

common/qemuopts

Мінібібліотека для запису рядків команд qemu та файлів налаштувань qemu.

common/structs

Загальний код для виведення та вивільнення структур libguestfs, який використовується у бібліотеці та деяких інструментах.

common/utils

Різноманітні допоміжні функції, які використовуються у бібліотеці та інструментах.

common/visit

Рекурсивний обхід ієрархії файлових систем guestfs.

common/windows

Допоміжні функції для обробки літер дисків у Windows.

contrib

Зовнішні внески, експериментальні частини.

customize

Програма virt-customize(1) та документація до неї.

daemon

Фонова служба, яка працює у базовій системі libguestfs і забезпечує виконання дій.

diff

Програма virt-diff(1) та документація до неї.

docs

Різноманітні сторінки підручника.

edit

Програма virt-edit(1) та документація до неї.

examples

Код прикладів використання програмного інтерфейсу мовою C.

fish

guestfish(1) — оболонка командного рядка та різноманітні скрипти оболонки на її основі, зокрема virt-copy-in(1), virt-copy-out(1), virt-tar-in(1), virt-tar-out(1).

format

Програма virt-format(1) та документація до неї.

fuse

guestmount(1), FUSE (файлова система у просторі користувача), яку зібрано на основі libguestfs.

generator

Критично важливий засіб створення коду, використовується для автоматичного створення значного обсягу важливого коду мовою C, зокрема для RPC та прив’язок.

get-kernel

Програма virt-get-kernel(1) та документація до неї.

inspector

virt-inspector(1) — засіб інспектування образів віртуальних машин.

logo

Логотип, який використовується на сайті. До речі, ім’я рибки — Артур.

make-fs

Програма virt-make-fs(1) та документація до неї.

po-docs

Інфраструктура збирання та файли PO перекладів сторінок підручника та файлів POD. Колись ми об’єднаємо ці дані з каталогом po, але цей процес є доволі складним.

rescue

Програма virt-rescue(1) та документація до неї.

resize

Програма virt-resize(1) та документація до неї.

sparsify

Програма virt-sparsify(1) та документація до неї.

sysprep

Програма virt-sysprep(1) та документація до неї.

tests

Тести.

test-data

Файли та інші тестові дані, які використовуються при тестуванні.

test-tool

Засіб тестування, який допоможе визначити кінцевим користувачам, чи працюватиме їхня комбінація qemu/ядро з libguestfs.

tools

Засоби командного рядка, які написано мовою програмування Perl (virt-win-reg(1) та багато інших).

utils

Різноманітні допоміжні програми, зокрема "boot-benchmark".

website

Файли сайта http://libguestfs.org.

csharp
erlang
gobject
golang
haskell
java

ocaml

perl
python
ruby

Прив’язки до мов програмування.

СИСТЕМА ЗБИРАННЯ
Libguestfs використовує систему збирання GNU autotools (autoconf, automake, libtool).

Скрипт ./configure створюється на основі configure.ac і m4/guestfs-*.m4. Більшу частину вмісту скрипту configure складають дані з багатьох файлів макросів m4, поділених за розділами, наприклад, m4/guestfs-daemon.m4 призначено для обробки залежностей фонової служби (daemon).

Завданням файла Makefile.am на верхньому рівні є визначення списку підкаталогів ("SUBDIRS") у порядку їхнього збирання.

common-rules.mk включається до усіх файлів Makefile.am (верхнього рівня та підкаталогів). subdir-rules.mk включається лише до файлів Makefile.am у підкаталогах.

Цілей збирання багато. Скористайтеся цією командою, щоб побачити список:

make help

РОЗШИРЕННЯ МОЖЛИВОСТЕЙ LIBGUESTFS

ДОДАВАННЯ НОВИХ ПРОГРАМНИХ ІНТЕРФЕЙСІВ
Оскільки більша частина стереотипного коду у libguestfs створюється у автоматичному режимі, розширити програмний інтерфейс libguestfs доволі просто.

Щоб додати нову дію програмного інтерфейсу, слід внести дві зміни:

Існує два різновиди дій програмного інтерфейсу. Тип залежить від того, проходить виклик до базової системи через фонову службу, чи обслуговується лише засобами бібліотеки (див. "АРХІТЕКТУРА" in guestfs-internals(1)). "guestfs_sync" in guestfs(3) є прикладом дій першого типу, оскільки синхронізація відбувається у базовій системі. "guestfs_set_trace" in guestfs(3) є прикладом дій другого типу, оскільки прапорець трасування обслуговується у дескрипторі, а усе трасування виконується на боці бібліотеки.

Більшість нових дій належить до першого типу, тому їхні записи додаються до списку "daemon_functions". У кожної функції є унікальний номер процедури, який використовується у протоколі RPC, який пов’язується із цією дією під час оприлюднення версії libguestfs і який не можна використовувати повторно. Знайдіть останній номер процедури і додайте до нього одиницю, щоб отримати ваш номер.

Дії другого типу, які пов’язано лише з бібліотекою, слід додавати до списку "non_daemon_functions". Оскільки ці функції обслуговуються бібліотекою і не поширюються механізмом RPC до фонової служби, ці функції не потребують номеру процедури; отже, для них встановлюється номер процедури -1.

Для дій фонової служби слід реалізувати функцію "do_<назва>" у каталозі "daemon/".

Для дій бібліотеки слід реалізувати функцію "guestfs_impl_<назва>" у каталозі "lib/".

У обох випадках скористайтеся якоюсь іншою функцією як прикладом реалізації.

Після внесення цих змін скористайтеся командою "make" для збирання.

Зауважте, що вам не потрібно реалізовувати RPC, прив’язки до мов, сторінки підручника або щось інше. Усе це буде створено автоматично на основі опису OCaml.

Додавання тестів для програмного інтерфейсу

До кожного виклику програмного інтерфейсу можна не додавати тести або додавати будь-яку кількість тестів. Тести може бути додано або як частину опису програмного інтерфейсу (generator/actions_*.ml), або у деяких рідкісних випадках, додати скрипт до "tests/*/". Зауважте, що додавання скрипту до "tests/*/" уповільнює тестування, тому, якщо можна, користуйтеся першим зі способів.

Нижче описано тестове середовище, яке використовується при додавання тесту програмного інтерфейсу до actions_*.ml.

У середовищі тестування 4 блокових пристрої:
/dev/sda 2 ГБ

Блоковий пристрій загального типу для тестування.

/dev/sdb 2 ГБ

/dev/sdb1 — файлова система ext2, яка використовується для тестування дій із запису до файлової системи.

/dev/sdc 10 МБ

Використовується для тестів, у яких потрібні два блокових пристрої.

/dev/sdd

ISO із фіксованим вмістом (див. images/test.iso).

Щоб мати змогу виконувати тестування у прийнятні строки, базову систему та блокові пристрої libguestfs слід повторно використовувати у тестах. Отже, не намагайтеся тестувати "guestfs_kill_subprocess" in guestfs(3) :-x

Кожен тест запускає початковий сценарій, який вибирається за допомогою одного з виразів "Init*", описаний у generator/types.ml. Сценарій ініціалізує диски, згадані вище, у спосіб, який задокументовано у types.ml. Ви не повинні робити у своєму коді жодних припущень щодо попереднього вмісту інших дисків, які не ініціалізовано.

Ви можете додати інструкцію щодо попередніх вимог до будь-якого окремого тесту. Це динамічна перевірка, яка, якщо її не буде пройдено, призведе до пропускання тесту. Це корисно для тестування команди, яка може не працювати у всіх різновидах збірок libguestfs. Тест, для якого попередньою вимогою є "Always", запускається безумовно.

Крім того, пакувальники можуть пропускати окремі тести встановленням відповідних змінних середовища до запуску "make check".

SKIP_TEST_<CMD>_<NUM>=1

Приклад: "SKIP_TEST_COMMAND_3=1" призведе до пропускання тесту 3 у "guestfs_command" in guestfs(3).

або:

SKIP_TEST_<CMD>=1

Приклад: "SKIP_TEST_ZEROFREE=1" призводить до пропускання усіх тестів "guestfs_zerofree" in guestfs(3).

Пакувальники можуть обмежити тестування певним набором тестів, встановлюючи, наприклад, таке:

TEST_ONLY="vfs_type zerofree"

Див. tests/c-api/tests.c, щоб дізнатися більше про те, як працюють ці змінні середовища.

Діагностика нових програмних інтерфейсів

Перевірте нові можливості, перш ніж записувати їх до сховища коду.

Для перевірки нових команд ви можете скористатися guestfish.

Діагностика фонової служби є проблематичною, оскільки вона виконується у мінімалістичному середовищі. Втім, ви можете скористатися виведенням повідомлень за допомогою fprintf у фоновій службі до stderr. Повідомлення можна буде переглядати за допомогою "guestfish -v".

ДОДАВАННЯ НОВОЇ ПРИВ’ЯЗКИ ДО МОВИ
Усі прив’язки до мов має бути створено відповідним засобом (див. підкаталог generator).

Документації з цього питання ще не написано. Пропонуємо вам звернутися до коду наявних прив’язок, наприклад generator/ocaml.ml або generator/perl.ml.

Додавання тестів для прив’язок до мов

Прив’язки до мов мають постачатися із тестами. Раніше тестування прив’язок до мов було суто ситуативним, але тепер ми намагаємося формалізувати набір тестів, які має використовувати кожна прив’язка до мови.

У поточній версії повний набір тестів реалізовано лише для прив’язок до OCaml і Perl. Канонічним набором є набір для OCaml, тому вам слід емулювати тести саме для OCaml.

Ось схема нумерації, яка використовується у тестах:

- 000+, базові перевірки:
010 завантажити бібліотеку
020 створення
030 прапорці створення
040 створення декількох дескрипторів
050 налаштовування тестування та отримання властивостей налаштовування
060 явне закриття
065 неявне закриття (у мовах із збирачем сміття)
070 аргументи параметрів
080 версія
090 повернуті значення
- 100 запуск, створення розділів та логічних томів, а також файлових систем
- події 400+:
410 подія закриття
420 повідомлення журналу
430 повідомлення щодо поступу
- 800+ тести на регресії (специфічні для мови)
- 900+ будь-які інші нетипові тести для мови

Для заощадження часу під час виконання тестування дескриптор запускатимуть лише 100, 430, 800+, 900+.

ФОРМАТУВАННЯ КОДУ
Наш початковий код мовою C загалом відповідає деяким базовим вимогам щодо форматування коду. Наявна кодова база є повністю однорідною у цьому сенсі, але ми б хотіли, щоб увесь новий код також було форматовано подібним чином. Якщо коротко, користуйтеся пробілами, а не символами табуляції, використовуйте додаткові 2 пробіли на кожному із рівнів відступів, у інших аспектах форматування слідуйте стилю книги Кернігана та Річі.

Якщо ви користуєтеся Emacs, додайте наступний текст до одного із ваших файлів налаштувань для запуску (наприклад, ~/.emacs), щоб забезпечити належні правила встановлення відступів:

;;; In libguestfs, indent with spaces everywhere (not TABs).
;;; Exceptions: Makefile and ChangeLog modes.
(add-hook 'find-file-hook
'(lambda () (if (and buffer-file-name
(string-match "/libguestfs\\>"
(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 'c-mode-hook
'(lambda () (if (string-match "/libguestfs\\>"
(buffer-file-name))
(libguestfs-c-mode))))

ТЕСТУВАННЯ ВНЕСЕНИХ ВАМИ ЗМІН
Перетворити попередження на повідомлення про помилки під час розробки, щоб ці попередження не ігнорувалися:

./configure --enable-werror

Корисні цілі збирання:
"make check"

Запускає звичайний комплект перевірок.

Реалізовано за допомогою типової цілі automake "TESTS". Докладніше про цю ціль можна дізнатися з документації до automake.

"make check-valgrind"

Запускає підмножину комплекту тестування у valgrind.

Див. "VALGRIND" нижче.

"make check-valgrind-local-guests"

Запускає підмножину комплекту тестування у valgrind з використанням локально встановлених гостьових систем libvirt (лише для читання).

"make check-direct"

Виконує усі тести за допомогою типового модуля роботи із базовою системою. Працює, лише якщо за допомогою "./configure --with-default-backend=..." було вибрано нетиповий модуль.

"make check-valgrind-direct"

Запустити підмножину комплексу тестів під керуванням valgrind з використанням типового модуля базової системи.

"make check-with-upstream-qemu"

Виконує усі тести з використанням локального виконуваного файла qemu. Шукає виконуваний файл qemu за допомогою змінної QEMUDIR (типове значення $HOME/d/qemu), але ви можете встановити інший каталог за допомогою рядка команди. Приклад:

make check-with-upstream-qemu QEMUDIR=/usr/src/qemu

"make check-with-upstream-libvirt"

Виконує усі тести за допомогою локальної копії libvirt. Працює, лише якщо за допомогою "./configure --with-default-backend=libvirt" було вибрано модуль libvirt.

Пошук libvirt виконуватиметься у каталозі LIBVIRTDIR (типово, $HOME/d/libvirt), але ви можете вказати інший каталог у рядку команди. Приклад:

make check-with-upstream-libvirt LIBVIRTDIR=/usr/src/libvirt

"make check-slow"

Запускає повільні тести або тести, які виконуються довго. Такі тести типово не запускаються.

Щоб позначити тест як повільний або такий, який виконується довго:

check-slow:
$(MAKE) check TESTS="$(SLOW_TESTS)" SLOW=1

"sudo make check-root"

Запускає деякі тести, які потребують прав доступу користувача root. Ці тести, як ми припускаємо, безпечні, але вам слід вжити усіх додаткових засобів захисту. Вам слід запускати цю команду від імені root (наприклад, за допомогою явного використання sudo(8)).

Щоб позначити тест як такий, що вимагає прав доступу користувача root:

check-root:
$(MAKE) check TESTS="$(ROOT_TESTS)"

"make check-all"

Еквівалент запуску усіх правил "make check*", окрім "check-root".

"make check-release"

Виконує підмножину правил "make check*", які слід передати до створення архіву tar. У поточній версії це:

"make installcheck"

Запустити "make check" для встановленої копії libguestfs.

Версії встановленої libguestfs, тестування якої виконується, та версія у ієрархії початкового коду libguestfs мають збігатися.

Команди:

./configure
make clean ||:
make
make installcheck

VALGRIND
Коли ви віддаєте команду "make check-valgrind", відбувається пошук будь-якого Makefile.am у ієрархії коду, де є ціль "check-valgrind:", і його запуск.

Правильно написати Makefile.am і тести, щоб скористатися valgrind і паралельним тестуванням automake, не так уже і просто.

Якщо ваш тести запускаються за допомогою скриптової обгортки для командної оболонки, у обгортці слід скористатися таким кодом:

$VG virt-foo

а у Makefile.am слід вказати:

check-valgrind:
make VG="@VG@" check

Втім, якщо ваші виконувані файли запускаються безпосередньо з правила "TESTS", до Makefile.am слід внести такий рядок:

LOG_COMPILER = $(VG)
check-valgrind:
make VG="@VG@" check

Який би з варіантів ви не реалізовували, слід перевіряти, чи ту програму ви тестуєте, шляхом уважного вивчення файлів журналу tmp/valgrind*.

НАДСИЛАННЯ ЛАТОК
Submit patches to the mailing list: https://lists.libguestfs.org and CC to rjones [AT] redhat.com.

Можете не підписуватися на список листування, якщо не хочете. Втім, для непідписаних користувачів повідомлення з’являються у списку із затримкою, потрібною на модерацію.

ПІДТРИМКА ІНТЕРНАЦІОНАЛІЗАЦІЇ (I18N)
У нашій бібліотеці передбачено можливість інтернаціоналізації (засобами gettext).

Втім, багато повідомлень надходять від фонової служби, і у поточній версії ми їх не перекладаємо. Однією з причин цього є те, що, загалом, у базовій системі немає файлів локалей, оскільки вони досить об’ємні. Тому для реалізації можливості перекладу нам довелося б додати ці файли і скопіювати наші файли PO до базової системи.

Діагностичні повідомлення не перекладаються, оскільки їх призначено для програмістів.

ІНШІ ТЕМИ

ЯК КОМПІЛЮЮТЬСЯ І КОМПОНУЮТЬСЯ ПРОГРАМИ OCAML
Більша частина цього розділу присвячена питанню «як ми змусили automake і ocamlopt працювати разом», оскільки самі програми OCaml зібрати легко.

У automake немає вбудованої підтримки програм OCaml, ocamlc та ocamlopt. Наш підхід полягає у обробці програм OCaml як програм C, які можуть містити такі «інші об’єкти» ("DEPENDENCIES" у термінології automake), які можуть бути об’єктами OCaml. Це працює, оскільки програми OCaml зазвичай містять файли C для природних прив’язок до бібліотек тощо.

Отже, типова програма описується як список файлів з її кодом мовою C:

virt_customize_SOURCES = ... crypt-c.c perl_edit-c.c

Для програм, які не містять явних початкових текстів мовою C ми створюємо порожній файл dummy.c і додаємо його до списку замість справжніх файлів:

virt_resize_SOURCES = dummy.c

Об’єкти OCaml, які містять більшу частину коду, потрапляють до списку як залежності automake (інші залежності також можуть потрапляти до списку):

virt_customize_DEPENDENCIES = ... customize_main.cmx

Окрім того, єдиною іншою річчю, яку нам слід зробити, є надання нетипової команди компонування. Ця команда потрібна, оскільки інакше automake не зможе зібрати команду ocamlopt, список об’єктів та бібліотеки "-cclib" у належному порядку.

virt_customize_LINK = \
$(top_builddir)/ocaml-link.sh -cclib '-lutils' -- ...

Справжні правила, із якими ви можете ознайомитися у файлі customize/Makefile.am є дещо складнішими за ці, оскільки у них ще треба обробити:

Ці правила тепер зберігаються у subdir-rules.mk на верхньому рівні ієрархії коду. Цей файл включається до усіх підкаталогів Makefile.am.

Automake не зможе визначити повний список початкових кодів для виконуваного файла, тому програма не зможе додати відповідні файли автоматично.

ЗАВДАННЯ ІЗ СУПРОВОДУ

ЦІЛІ ДЛЯ СУПРОВІДНИКІВ У MAKEFILE
Ці цілі "make", ймовірно, не працюватимуть або не будуть корисними, якщо ви не є супровідником пакунків libguestfs.

make maintainer-commit

Ця ціль вносить усі зміни із робочого каталогу до системи керування сховищем коду із повідомленням щодо внеску "Version $(VERSION).". Вам слід спочатку оновити configure.ac, очистити ієрархію коду та виконати повторне збирання.

make maintainer-tag

Ця команда створює мітку для поточного внеску у HEAD зі значенням мітки "v$(VERSION)" і одним із таких повідомлень:

Version $(VERSION) stable
Version $(VERSION) development

(Опис відмінностей між стабільним випуском і випуском, який перебуває у розробці, наведено у розділі "НУМЕРАЦІЯ ВЕРСІЙ LIBGUESTFS" in guestfs(3).)

make maintainer-check-authors

Перевірити, чи усіх авторів (записи яких можна знайти у повідомленнях щодо внесків до git) включено до файла generator/authors.ml.

make maintainer-check-extra-dist

Це правило слід запускати після "make dist" (щоб у робочому каталозі уже був архів tar). Воно порівнює вміст архіву tar із даними у git з метою переконатися, що не пропущено жодного файла із правил "EXTRA_DIST" у Makefile.am.

make maintainer-upload-website

Це правило використовується програмним забезпеченням автоматизації випусків libguestfs для копіювання сайта libguestfs до іншого сховища git до його вивантаження на вебсервер.

СТВОРЕННЯ СТАБІЛЬНОГО ВИПУСКУ
Тут наведено документацію щодо створення стабільних випусків. Загальні правила щодо створення стабільних випусків наведено у розділі "НУМЕРАЦІЯ ВЕРСІЙ LIBGUESTFS" in guestfs(3).

Fedora (x86-64)
Debian (x86-64)
Ubuntu (x86-64)
Fedora (aarch64)
Fedora (ppc64)
Fedora (ppc64le)

./localconfigure
make distclean -k
./localconfigure
make && make dist
make maintainer-commit
make maintainer-tag

git branch stable-1.XX
git push origin stable-1.XX

ВНУТРІШНЯ ДОКУМЕНТАЦІЯ

У цьому розділі наведено документацію щодо внутрішніх функцій libguestfs та різноманітних допоміжних програм. Вміст цього розділу буде цікавим лише для розробників libguestfs.

Цей розділ створено автоматично на основі тих коментарів "/**" у файлах початкового коду, які форматовано для використання у форматі POD.

Ці функції не експортуються відкрито (public). Їх може бути змінено або вилучено у будь-якій новішій версії.

__INTERNAL_DOCUMENTATION__

ТАКОЖ ПЕРЕГЛЯНЬТЕ

guestfs(3), guestfs-building(1), guestfs-examples(3), guestfs-internals(1), guestfs-performance(1), guestfs-release-notes(1), guestfs-testing(1), libguestfs-test-tool(1), libguestfs-make-fixed-appliance(1), http://libguestfs.org/.

АВТОРИ

Richard W.M. Jones ("rjones at redhat dot com")

АВТОРСЬКІ ПРАВА

Copyright (C) 2009-2023 Red Hat Inc.

LICENSE

BUGS

To get a list of bugs against libguestfs, use this link: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools

To report a new bug against libguestfs, use this link: https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools

When reporting a bug, please supply: