RFC 8762 Simple Two-Way Active Measurement Protocol

Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 8762                                        G. Jun
Category: Standards Track                                      ZTE Corp.
ISSN: 2070-1721                                                H. Nydell
                                                       Accedian Networks
                                                                R. Foote
                                                                   Nokia
                                                              March 2020

Simple Two-Way Active Measurement Protocol

Простой протокол двухстороннего активного измерения STAMP

PDF

Аннотация

Этот документ описывает простой протокол двухстороннего активного измерения (Simple Two-way Active Measurement Protocol или STAMP), позволяющий измерять параметры производительности, такие как задержка, ее вариации и потеря пакетов в одном направлении или при обходе по кругу (туда и обратно).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8762.

Авторские права

Copyright (c) 2020. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Разработка и внедрение протокола двухстороннего активного измерения (Two-Way Active Measurement Protocol или TWAMP) [RFC5357] и его расширений (например, [RFC6038], где определяется симметричный размер для TWAMP) принесли ценный опыт. Имеется несколько независимых реализаций TWAMP и TWAMP Light, которые развернуты и обеспечивают важные измерения рабочих параметров производительности.

В то же время наблюдается заметный интерес к использованию более простого механизма для активного мониторинга производительности, обеспечивающего детерминированное поведение и внутреннее разделение функций управления (фирменная настройка и «оркестровка») и тестирования. Недавняя работа Performance Measurement from IP Edge to Customer Equipment using TWAMP Light [BBF.TR-390] в рамках Broadband Forum показала, что взаимодействие между реализациями TWAMP Light затруднено по причине того, что устройство и работа TWAMP Light достаточно слабо описаны в [RFC5357]. В соответствии с [RFC8545] TWAMP Light включает подмножество функций TWAMP-Test. Таким образом, для получения полнофункционального инструментария для измерения потери и задержки пакетов требуется поддержка других приложений, например, для управления и защиты.

Этот документ определяет протокол активного измерения производительности (Simple Two-way Active Measurement Protocol или STAMP), который позволяет измерять в одном или обоих направлениях параметры производительности, включая задержку и ее вариации, а также потери пакетов. Поддержка некоторых необязательных расширения TWAMP, например, [RFC7750], обсуждается в [STAMP-OPTION].

2. Используемые соглашения

2.1. Сокращения

STAMP

Simple Two-way Active Measurement Protocol (простой протокол активных двухсторонних измерений).

NTP

Network Time Protocol (протокол сетевого времени).

PTP

Precision Time Protocol (протокол точного времени).

HMAC

Hashed Message Authentication Code (хэшированный код аутентификации сообщения).

OWAMP

One-Way Active Measurement Protocol (протокол односторонних активных измерений).

TWAMP

Two-Way Active Measurement Protocol (протокол двухсторонних активных измерений).

MBZ

Must be Zero (должно быть 0).

PDU

Protocol Data Unit (блок данных протокола).

2.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Операции и управление измерениями STAMP

На рисунке 1 представлены отправитель Session-Sender и рефлектор Session-Reflector измерительной сессии STAMP, которая в этом документе называется просто сессией STAMP. Сессия представляет собой двухсторонних поток пакетов между одним конкретным отправителем и одним конкретным рефлектором в течение определенного времени. Настройка и управления для отправителя, рефлектора и сессии STAMP могут выполняться разными способами, рассмотрение которых выходит за рамки документа. Примерами могут служить командный интерфейс CLI (Command Line Interface), система поддержки операций телекоммуникационного сервиса (Operational Support System или OSS, Business Support System или BSS), SNMP, и контроллеры программно определяемых сетей (Software-Defined Networking илм SDN) на основе NETCONF и YANG.

    o----------------------------------------------------------o
    |                      Настройка и                         |
    |                      управление                          |
    o----------------------------------------------------------o
           ||                                          ||
           ||                                          ||
           ||                                          ||
+----------------------+                +-------------------------+
| STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
+----------------------+                +-------------------------+

Рисунок 1. Эталонная модель STAMP.


4. Теория операций

Отправитель STAMP Session-Sender передает тестовые пакеты по протоколу UDP в направлении STAMP Session-Reflector. Рефлектор получает пакеты от Session-Sender и действует в соответствии с конфигурацией. Два режима работы Session-Reflector характеризуют ожидаемое поведение и измеряемые параметры.

Stateless — без учета состояния

STAMP Session-Reflector не поддерживает состояние для теста и использует значение порядкового номера в принятых пакетах в качестве поля Sequence Number отраженных пакетов. В результате порядковые номера в пакетах отправителя и рефлектора совпадают и в этом режиме можно обнаружить лишь потерю пакетов на круговом пути.

Stateful — с учетом состояния

STAMP Session-Reflector поддерживает состояние теста, что позволяет отправителю определить направление, на котором теряются пакеты, используя комбинацию порядковых номеров в своих пакетах и откликах. Для этого STAMP Session-Reflector должен поддерживать состояние в каждой настроенной сессии STAMP-Test для однозначной привязки тестовых пакетов к экземпляру сессии и добавление порядкового номера в пакеты STAMP-Test с увеличением на 1 для каждого пакета в сессии.

STAMP поддерживает работу с аутентификацией и без нее. Тестовые пакеты без аутентификации (параграфы 4.2.1 и 4.3.1) обеспечивают взаимодействие между STAMP и TWAMP Light, как описано в параграфе 4.6.

По умолчанию STAMP использует симметричные пакеты, т. е. размер пакетов отправителя и рефлектора совпадает.

4.1. Номера портов UDP в тестах STAMP

Отправитель STAMP должен использовать порт UDP 862 (TWAMP-Test Receiver) в качестве принятого по умолчанию целевого порта UDP. Реализация STAMP на стороне Session-Sender должна быть способна использовать номера портов назначения из диапазонов User Ports (Registered Ports) и Dynamic Ports (Private or Ephemeral Ports), заданных в [RFC6335]. Перед использованием порта из диапазона User Ports должно быть внимательно рассмотрено влияние на сеть и согласовано применение со всеми пользователями домена, где планируется тестирование.

По умолчанию реализация STAMP Session-Reflector должна принимать пакеты STAMP-Test на порту UDP 862. Поддерживающая эту спецификацию реализация Session-Reflector должна быть способна задать номер порта для приема пакетов STAMP-Test из диапазонов User Ports и Dynamic Ports, заданных в [RFC6335]. STAMP определяет два формата тестовых пакетов, один из которых применяет Session-Sender, другой — Session-Reflector.

4.2. Поведение и формат пакетов отправителя

STAMP Session-Reflector по умолчанию поддерживает симметричный размер тестовых пакетов, как указано в разделе 3 [RFC6038]. Базовый отраженный пакет включает информацию от рефлектора, поэтому должен быть больше. Для поддержки симметрии между базовыми пакетами STAMP в базовый пакет STAMP Session-Sender включено поле нулей MBZ с учетом размера базового отраженного пакета STAMP. Поэтому базовый пакет STAMP Session-Sender имеет минимальный размер 44 октета в режиме без аутентификации (рисунок 2) и 112 октетов в режиме с аутентификацией (рисунко 4). Генерация пакетов STAMP переменного размера описана в [STAMP-OPTION].

4.2.1. Формат пакетов в режиме без аутентификации

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
|                                                               |
|                        MBZ  (30 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат пакета отправителя в режиме без аутентификации.

Sequence Number

4-октетное поле порядкового номера. Для каждой новой сессии значения начинается с 0 и инкрементируется в каждом переданном пакете.

Timestamp

8-октетное поле с временной меткой. Узел STAMP должен поддерживать 64-битовые метки протокола сетевого времени (Network Time Protocol или NTP) версии 4 [RFC5905], формат которых задан в [RFC5357]. Узел STAMP может поддерживать метки протокола IEEE 1588v2 Precision Time Protocol (PTP), усеченные до 64 битов [IEEE.1588.2008] и применяемые в [RFC8186]. Использование конкретного формата NTP или PTP задается в конфигурации Session-Sender или для конкретной сессии.

Error Estimate

2-октетное поле, формат которого показан на рисунке 3.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z|   Scale   |   Multiplier  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Формат оценки ошибок.

Поля S, Scale и Multiplier интерпретируются в соответствии с параграфом 4.1.2 в [RFC4656], поле Z — в соответствии с параграфом 2.3 в [RFC8186]:

0

64-битовые временные метки NTP.

1

усеченные временные метки PTPv2.

По умолчанию отправитель и рефлектор STAMP используют формат временных меток NTP (Z = 0). Оператор с помощью функции настройки или управления может задать использование усеченного формата меток PTPv2 (Z = 1). Отметим, что поддерживающую эту спецификацию реализацию Session-Sender можно настроить на использование формата PTPv2, даже когда в Session-Reflector задан формат NTP.

MBZ

В пакетах Session-Sender без аутентификации имеет размер 30 октетов. Поле должно быть заполнено нулями при передаче и должно игнорироваться на приемной стороне.

4.2.2. Формат пакетов в режиме с аутентификацией

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      MBZ (12 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Timestamp                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
~                                                               ~
|                         MBZ (70 октетов)                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат пакета отправителя в режиме с аутентификацией.


Определения полей совпадают с режимом без аутентификации, как указано в параграфе 4.2.1. Поля MBZ служат для выравнивания пакетов по размеру, кратному 16 октетам. Поля должны заполняться нулями при передаче и должны игнорироваться при получении. Оба поля MBZ учитываются при расчете HMAC [RFC2104]. Пакет включает также хэш-код HMAC в конце PDU. Принятое по умолчанию использование поля HMAC описано в параграфе 4.4.

4.3. Поведение и формат пакетов рефлектора

Session-Reflector принимает пакет STAMP-Test и проверяет его. Если базовый пакет STAMP-Test действителен, поддерживающая эту спецификацию реализация Session-Reflector готовит и передает отраженный тестовый пакет, симметричный полученному от Session-Sender, копируя в него содержимое за пределами размера базового пакета STAMP (параграф 4.2).

4.3.1. Формат пакетов в режиме без аутентификации

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |            MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Receive Timestamp                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Session-Sender Timestamp                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |            MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                      MBZ                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Формат пакета рефлектора в режиме без аутентификации.


Sequence Number

4-октетное поле, значение которого устанавливается в соответствии с режимом STAMP Session-Reflector:

  • в режиме без поддержки состояний копируется одноименное поле из принятого пакета STAMP-Test;
  • в режиме с учетом состояния Session-Reflector считает переданные пакеты STAMP-Test, начиная с 0 и увеличивая на 1 номер в каждом последующем пакете для каждой сессии. Значение счетчика помещается в поле Sequence Number.

Timestamp

Receive Timestamp

8-октетные поля в формате NTP или PTPv2, указанном флагом Z в поле Error Estimate, как указано в параграфе 4.2.1. Receive Timestamp указывает время приема тестового пакета рефлектором, Timestamp — время начала передачи рефлектором ответного тестового пакета.

Error Estimate

Размер и описание полей соответствуют указанным в параграфе 4.2.1. Поле относится к Timestamp и Receive Timestamp.

Session-Sender Sequence Number, Session-Sender Timestamp, Session-Sender Error Estimate

Копии соответствующих полей из пакета STAMP-Test от Session-Sender.

Session-Sender TTL

1-октетное значение, содержащее копию поля IPv4 TTL (или IPv6 Hop Limit) из принятого пакета STAMP-Test.

MBZ

Служит для выравнивания полей по 4-октетной границе. Поля должны заполняться нулями при передаче и должны игнорироваться при получении.

4.3.2. Формат пакетов в режиме с аутентификацией

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receive Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
|                        MBZ (15 октетов)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Формат пакета рефлектора в режиме с аутентификацией.


Определения полей совпадают с режимом без аутентификации, как указано в параграфе 4.3.1. Поля MBZ служат для выравнивания пакетов по размеру, кратному 16 октетам. Поля должны заполняться нулями при передаче и должны игнорироваться при получении. Оба поля MBZ учитываются при расчете HMAC [RFC2104]. Пакет включает также хэш-код HMAC в конце PDU. Принятое по умолчанию использование поля HMAC описано в параграфе 4.4.

4.4. Защита целостности в STAMP

Режим с аутентификацией обеспечивает защиту каждого сообщения STAMP путем добавления хэш-кода HMAC. STAMP использует HMAC-SHA-256 с отсечкой до 128 битов (как в IPsec [RFC4868]), поэтому поле HMAC имеет размер 16 октетов. При расчете HMAC используются первые 6 блоков (96 октетов). В HMAC применяются свои ключи, которые могут быть уникальными для каждой сессии STAMP-Test. Механизм распространения ключей и управления ими выходит за рамки спецификации. Одним из вариантов является использование оркестратора для настройки ключей HMAC на основе модели данных YANG STAMP [STAMP-YANG]. Значение HMAC должно проверяться как можно раньше, чтобы предотвратить распространение поврежденных данных.

В будущих спецификациях может быть задано применение более совершенных криптографических алгоритмов и возможно обновление модели данных YANG STAMP [STAMP-YANG].

4.5. Защита конфиденциальности в STAMP

Если нужна конфиденциальность STAMP, в сессии STAMP-Test должен применяться защищенный транспорт. Например, пакеты STAMP могут передаваться через выделенный туннель IPsec или использовать общий туннель с потоком, для которого выполняется мониторинг. Защиту конфиденциальности может также обеспечить протокол Datagram Transport Layer Security (DTLS).

4.6. Взаимодействие с TWAMP Light

Одним из важных требований к STAMP является возможность взаимодействия с устройствами TWAMP Light. Поскольку в STAMP и TWAMP применяются разные алгоритмы для режима с аутентификацией (HMAC-SHA-256 и HMAC-SHA-1), такое взаимодействие возможно лишь в режиме без аутентификации. Здесь возможны два варианта:

  • STAMP Session-Sender и TWAMP Light Session-Reflector;

  • TWAMP Light Session-Sender и STAMP Session-Reflector.

В первом случае Session-Sender может не знать, что рефлектор не поддерживает STAMP. Например, TWAMP Light Session-Reflector может не поддерживать работу через порт UDP 862, как указано в [RFC8545]. Поэтому раздел 4 позволяет применять иной порт в STAMP Session-Sender. Если используется какое-либо из расширений STAMP, рефлектор TWAMP Light будет видеть его как поле Packet Padding.

Во втором варианте, если TWAMP Light Session-Sender не поддерживает использование порта UDP 862, система управления тестом должна задать для STAMP Session-Reflector другой порт UDP в соответствии с разделом 4. Рефлектор должен использовать принятый по умолчанию формат временных меток NTP.

STAMP Session-Reflector, поддерживающий эту спецификацию, будет передавать базовый пакет (рисунок 5) при получении пакета, размер которого меньше принятой в STAMP базы. Если принятый от TWAMP Session-Sender пакет больше базового пакета STAMP, поддерживающий эту спецификацию рефлектор будет копировать оставшуюся часть пакета для передачи отраженного пакета симметричного размера.

5. Вопросы эксплуатации

Протокол STAMP предназначен для использования в действующих сетях, чтобы позволить оператору оценить соглашения об уровне обслуживания на основе задержки пакетов, ее вариаций и потери пакетов. При использовании STAMP через Internet, особенно при передаче пакетов STAMP-Test с номером целевого порта UDP из диапазона User Ports, должно быть тщательно проанализировано возможное влияние пакетов STAMP-Test. Каждый случай использования STAMP должен согласовываться между пользователями узлов Session-Sender и Session-Reflector до начала сессии STAMP-Test.

Использование общеизвестного номера целевого порта UDP в пакетах STAMP-Test, передаваемых от Session-Sender, не будет препятствовать измерениям в среде с множеством равноценных путей (ECMP) и приведенный в параграфе 5.3 [RFC8545] анализ полностью применим к STAMP.

6. Взаимодействие с IANA

Этот документ не требует действий IANA.

7. Вопросы безопасности

[RFC5357] не указывает вопросы безопасности, связанные с TWAMP-Test, но ссылается на вопросы безопасности, отмеченные для OWAMP в [RFC4656]. Поскольку OWAMP и TWAMP включают компоненты плоскостей данных и управления, для STAMP применимы лишь вопросы безопасности, рассмотренные для OWAMP-Test в параграфах 6.2 и 6.3 [RFC4656].

STAMP использует общеизвестный номер порта UDP, выделенный для получателя OWAMP-Test и TWAMP-Test. Таким образом, вопросы безопасности и меры по снижению риска атак с использованием зарегистрированного порта, указанные в разделе 6 [RFC8545], полностью применимы для STAMP. Поскольку управление и поддержка STAMP-Test полностью выходят за рамки этой спецификации, задаются лишь базовые требования.

Для смягчения возможных атак при управлении и поддержке сессий STAMP-Test должен применяться защищенный транспорт.

Нагрузка сети пакетами STAMP-Test должна внимательно оцениваться, а возможное влияние на имеющиеся службы должно тщательно анализироваться до начала тестирования. В параграфе 3.1.5 [RFC8085] даны рекомендации по обработке сетевой нагрузки для протоколов на основе UDP. Хотя характеристики тестового трафика зависят от цели тестирования, настоятельно рекомендуется оставаться в пределах, заданных [RFC8085].

Использование HMAC-SHA-256 в режиме с аутентификацией защищает целостность данных в пакетах STAMP-Test.

8. Литература

8.1. Нормативные документы

[IEEE.1588.2008] IEEE, «IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems», IEEE Standard 1588, July 2008.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC6038] Morton, A. and L. Ciavattone, «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features», RFC 6038, DOI 10.17487/RFC6038, October 2010, <https://www.rfc-editor.org/info/rfc6038>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry», BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8186] Mirsky, G. and I. Meilik, «Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)», RFC 8186, DOI 10.17487/RFC8186, June 2017, <https://www.rfc-editor.org/info/rfc8186>.

[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., «Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)», RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.

8.2. Дополнительная литература

[BBF.TR-390] Broadband Forum, «Performance Measurement from IP Edge to Customer Equipment using TWAMP Light», TR-390 Issue 1, May 2017.

[RFC4868] Kelly, S. and S. Frankel, «Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec», RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, «Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)», RFC 7750, DOI 10.17487/RFC7750, February 2016, <https://www.rfc-editor.org/info/rfc7750>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[STAMP-OPTION] Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, «Simple Two-way Active Measurement Protocol Optional Extensions», Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-option-tlv-031, 21 February 2020, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-03>.

[STAMP-YANG] Mirsky, G., Xiao, M., and W. Luo, «Simple Two-way Active Measurement Protocol (STAMP) Data Model», Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-05, 25 October 2019, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-05>.

Благодарности

Авторы выражают свою признательность Jose Ignacio Alvarez-Hamelin и Brian Weis за их глубокое понимание безопасности и защиты отождествлений, а также за множество полезных и важных предложений. Спасибо David Ball, Rakesh Gandhi и Xiao Min за их рецензии и полезные комментари.

Адреса авторов

Greg Mirsky

ZTE Corp.

Email: gregimirsky@gmail.com

Guo Jun

ZTE Corp.

68# Zijinghua Road

Nanjing

Jiangsu, 210012

China

Phone: +86 18105183663

Email: guo.jun2@zte.com.cn

Henrik Nydell

Accedian Networks

Email: hnydell@accedian.com

Richard Foote

Nokia

Email: footer.foote@nokia.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

1Работа опубликована в RFC 8972. Прим. перев.

Рубрика: RFC, Измерения и тестирование | Комментарии к записи RFC 8762 Simple Two-Way Active Measurement Protocol отключены

RFC 8740 Using TLS 1.3 with HTTP/2

Отменен RFC 9113

Рубрика: RFC | Оставить комментарий

Тесты iperf2 UDP на петлевом интерфейсе и в ЛВС 1Гбит/с

Тесты iperf2 UDP на петлевом интерфейсе и в ЛВС 1Гбит/с

Целью описанного ниже тестирования является оценка производительности сетевых компонент ядра Linux на платформе RISC-V HiFive Unleashed при использовании протокола UDP.

Измерения проводились с использованием трёх разных аппаратных платформ (по отдельности и во взаимодействии между парой платформ). Каждая из платформ имеет сетевой интерфейс GigabitEthernet, подключенный к ЛВС на основе коммутатора CSR-109-8G.

  • Плата HiFive Unleashed, Linux с ядром 5.2.9 (4 ядра U-540);

  • 2-процессорный сервер Intel (2 E5-2630 v4, 2,20 ГГц, 40 ядер);

  • Ноутбук Lenovo (Intel(R) Core(TM)2 Duo T6570, 2,10 ГГц, 2 ядра).

Управление тестами и контроль результатов выполнялись из консоли SSH на сервере.

В качестве тестового инструмента была выбрана программа iperf, которая, в отличие от iperf3, поддерживает многопотоковый (multithread) режим работы, позволяя загрузить все процессорные ядра в тестируемой системе. Все тесты выполнялись с использованием пакета iperf версии 2.0.14a, собранной из свежей версии SourceForge.

Измерения при каждом наборе параметров выполнялись многократно с выбором среднего значения при наличии разброса, который в большинстве случаев был незначительным.

Тесты на петлевом интерфейсе

Freedom-u540

root@freedom-u540:/usr/src/code# lscpu 
Architecture:        riscv64 
Byte Order:          Little Endian 
CPU(s):              4 
On-line CPU(s) list: 0-3 
Thread(s) per core:  1 
Core(s) per socket:  1 
Socket(s):           4 
CPU max MHz:         1400.0000 
CPU min MHz:         350.0000 
L1d cache:           128 KiB 
L1i cache:           128 KiB

root@freedom-u540:~# iperf -c 0 -u -e -P 1 
------------------------------------------------------------ 
Client connecting to 0, UDP port 5001 
Sending 1470 byte datagrams, IPG target: 11215.21 us 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 127.0.0.1 port 56209 connected with 127.0.0.1 port 5001 
[ ID] Interval        Transfer     Bandwidth      Write/Err  PPS 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  3] Sent 893 datagrams 
[  3] Server Report: 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.029/ 0.027/ 0.049/ 0.002 ms   89 pps  0 pkts 4490.80

root@freedom-u540:~# iperf -c 0 -u -e -P 2 
...
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  3] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  2.51 MBytes  2.10 Mbits/sec  1786/0      179 pps 
[  3] Server Report: 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.001 ms    0/  893 (0%)  0.028/ 0.027/ 0.053/ 0.002 ms   89 pps  0 pkts 4654.00

root@freedom-u540:~# iperf -c 0 -u -e -P 4 
...
[  4] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  4] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  5.01 MBytes  4.20 Mbits/sec  3572/0      357 pps 
[  4] Server Report: 
[  4] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.029/ 0.027/ 0.071/ 0.004 ms   89 pps  0 pkts 4533.59

root@freedom-u540:~# iperf -c 0 -u -e -P 8 
...
[  9] Server Report: 
[  9] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.028/ 0.027/ 0.041/ 0.002 ms   89 pps  0 pkts 4614.31 
[  9] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  9] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  10.0 MBytes  8.41 Mbits/sec  7144/0      714 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 16 
...
[ 10] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 10] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  20.1 MBytes  16.8 Mbits/sec  14288/0     1427 pps 
[ 10] Server Report: 
[ 10] 0.00-9.98 sec  1.25 MBytes  1.05 Mbits/sec   0.004 ms    2/  893 (0.22%)  0.031/ 0.027/ 0.088/ 0.007 ms   89 pps  0 pkts 4252.09

root@freedom-u540:~# iperf -c 0 -u -e -P 32 
...
[ 33] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 33] Sent 893 datagrams 
[ 33] Server Report:
[ 33] 0.00-9.95 sec  1.25 MBytes  1.05 Mbits/sec   0.003 ms    1/  893 (0.11%)  0.033/ 0.027/ 0.369/ 0.014 ms   89 pps  0 pkts 4036.93 
[ 33] 0.00-9.95 sec  4 datagrams received out-of-order 
[SUM] 0.00-10.00 sec  40.1 MBytes  33.6 Mbits/sec  28576/0     2853 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 64
...
[ 15] Server Report: 
[ 15] 0.00-9.91 sec  1.27 MBytes  1.08 Mbits/sec   0.032 ms  -14/  893 (-1.6%)  0.039/ 0.029/ 0.618/ 0.030 ms   90 pps  0 pkts 3412.60 
[ 15] 0.00-9.91 sec  21 datagrams received out-of-order 
[ 15] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 15] Sent 893 datagrams 
[SUM] 0.00-10.01 sec  80.2 MBytes  67.2 Mbits/sec  57152/0     5696 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 128
...
[ 56] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 56] Sent 893 datagrams 
[ 56] Server Report: 
[ 56] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.001 ms    0/  893 (0%)  0.038/ 0.031/ 0.144/ 0.008 ms   89 pps  0 pkts 3449.57 
[SUM] 0.00-10.01 sec   160 MBytes   134 Mbits/sec  114304/0    11368 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 256
...
[ 47] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       88 pps 
[ 47] Sent 893 datagrams 
[ 47] Server Report: 
[ 47] 0.00-9.96 sec  1.24 MBytes  1.05 Mbits/sec   0.010 ms    5/  893 (0.56%)  0.049/ 0.031/ 1.644/ 0.061 ms   89 pps  0 pkts 2647.73 
[SUM] 0.00-10.01 sec   321 MBytes   269 Mbits/sec  228577/0    22605 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 512
...
[207] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  890/0       88 pps 
[207] Sent 890 datagrams 
[207] Server Report: 
[207] 0.00-0.25 sec  1.44 KBytes  47.1 Kbits/sec   0.000 ms  898/  899 (1e+02%) 1315.652/1315.652/1315.652/ 0.000 ms 3600 pps 4736 pkts 0.00 
[SUM] 0.00-10.01 sec   640 MBytes   536 Mbits/sec  456285/0    42023 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 1024
...
[120] 0.00-10.17 sec  1.07 MBytes   884 Kbits/sec  764/0       73 pps 
[120] Sent 764 datagrams 
[120] Server Report: 
[120] 0.00-0.25 sec  1.44 KBytes  47.0 Kbits/sec   0.000 ms  772/  773 (1e+02%) 1289.439/1289.439/1289.439/ 0.000 ms 3091 pps 3986 pkts 0.00 
[SUM] 0.00-10.03 sec  1.01 GBytes   862 Mbits/sec  733728/0    68602 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 2048
...
[449] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  890/0       86 pps 
[449] Sent 890 datagrams 
[449] Server Report: 
[449] 0.00-0.25 sec  1.44 KBytes  47.0 Kbits/sec   0.000 ms  898/  899 (1e+02%) 1318.279/1318.279/1318.279/ 0.000 ms 3593 pps 4737 pkts 0.00 
[SUM] 0.00-9.93 sec  1.24 GBytes  1.07 Gbits/sec  904649/0    84159 pps

При значении -b 1024 уже начали возникать ошибки, связанные с перегрузкой, поэтому были проведены дополнительные измерения в диапазоне 800 — 2000 Мбит/с с линейным приращением скорости генерации.

root@freedom-u540:/usr/src/code# lscpu 
Architecture:        riscv64 
Byte Order:          Little Endian 
CPU(s):              4 
On-line CPU(s) list: 0-3 
Thread(s) per core:  1 
Core(s) per socket:  1 
Socket(s):           4 
CPU max MHz:         1400.0000 
CPU min MHz:         350.0000 
L1d cache:           128 KiB 
L1i cache:           128 KiB

root@freedom-u540:~# iperf -c 0 -u -e -P 1 
------------------------------------------------------------ 
Client connecting to 0, UDP port 5001 
Sending 1470 byte datagrams, IPG target: 11215.21 us 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 127.0.0.1 port 56209 connected with 127.0.0.1 port 5001 
[ ID] Interval        Transfer     Bandwidth      Write/Err  PPS 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  3] Sent 893 datagrams 
[  3] Server Report: 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.029/ 0.027/ 0.049/ 0.002 ms   89 pps  0 pkts 4490.80

root@freedom-u540:~# iperf -c 0 -u -e -P 2 
...
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  3] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  2.51 MBytes  2.10 Mbits/sec  1786/0      179 pps 
[  3] Server Report: 
[  3] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.001 ms    0/  893 (0%)  0.028/ 0.027/ 0.053/ 0.002 ms   89 pps  0 pkts 4654.00

root@freedom-u540:~# iperf -c 0 -u -e -P 4 
...
[  4] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  4] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  5.01 MBytes  4.20 Mbits/sec  3572/0      357 pps 
[  4] Server Report: 
[  4] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.029/ 0.027/ 0.071/ 0.004 ms   89 pps  0 pkts 4533.59

root@freedom-u540:~# iperf -c 0 -u -e -P 8 
...
[  9] Server Report: 
[  9] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.000 ms    0/  893 (0%)  0.028/ 0.027/ 0.041/ 0.002 ms   89 pps  0 pkts 4614.31 
[  9] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[  9] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  10.0 MBytes  8.41 Mbits/sec  7144/0      714 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 16 
...
[ 10] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 10] Sent 893 datagrams 
[SUM] 0.00-10.00 sec  20.1 MBytes  16.8 Mbits/sec  14288/0     1427 pps 
[ 10] Server Report: 
[ 10] 0.00-9.98 sec  1.25 MBytes  1.05 Mbits/sec   0.004 ms    2/  893 (0.22%)  0.031/ 0.027/ 0.088/ 0.007 ms   89 pps  0 pkts 4252.09

root@freedom-u540:~# iperf -c 0 -u -e -P 32 
...
[ 33] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 33] Sent 893 datagrams 
[ 33] Server Report:
[ 33] 0.00-9.95 sec  1.25 MBytes  1.05 Mbits/sec   0.003 ms    1/  893 (0.11%)  0.033/ 0.027/ 0.369/ 0.014 ms   89 pps  0 pkts 4036.93 
[ 33] 0.00-9.95 sec  4 datagrams received out-of-order 
[SUM] 0.00-10.00 sec  40.1 MBytes  33.6 Mbits/sec  28576/0     2853 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 64
...
[ 15] Server Report: 
[ 15] 0.00-9.91 sec  1.27 MBytes  1.08 Mbits/sec   0.032 ms  -14/  893 (-1.6%)  0.039/ 0.029/ 0.618/ 0.030 ms   90 pps  0 pkts 3412.60 
[ 15] 0.00-9.91 sec  21 datagrams received out-of-order 
[ 15] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 15] Sent 893 datagrams 
[SUM] 0.00-10.01 sec  80.2 MBytes  67.2 Mbits/sec  57152/0     5696 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 128
...
[ 56] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       89 pps 
[ 56] Sent 893 datagrams 
[ 56] Server Report: 
[ 56] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec   0.001 ms    0/  893 (0%)  0.038/ 0.031/ 0.144/ 0.008 ms   89 pps  0 pkts 3449.57 
[SUM] 0.00-10.01 sec   160 MBytes   134 Mbits/sec  114304/0    11368 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 256
...
[ 47] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  893/0       88 pps 
[ 47] Sent 893 datagrams 
[ 47] Server Report: 
[ 47] 0.00-9.96 sec  1.24 MBytes  1.05 Mbits/sec   0.010 ms    5/  893 (0.56%)  0.049/ 0.031/ 1.644/ 0.061 ms   89 pps  0 pkts 2647.73 
[SUM] 0.00-10.01 sec   321 MBytes   269 Mbits/sec  228577/0    22605 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 512
...
[207] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  890/0       88 pps 
[207] Sent 890 datagrams 
[207] Server Report: 
[207] 0.00-0.25 sec  1.44 KBytes  47.1 Kbits/sec   0.000 ms  898/  899 (1e+02%) 1315.652/1315.652/1315.652/ 0.000 ms 3600 pps 4736 pkts 0.00 
[SUM] 0.00-10.01 sec   640 MBytes   536 Mbits/sec  456285/0    42023 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 1024
...
[120] 0.00-10.17 sec  1.07 MBytes   884 Kbits/sec  764/0       73 pps 
[120] Sent 764 datagrams 
[120] Server Report: 
[120] 0.00-0.25 sec  1.44 KBytes  47.0 Kbits/sec   0.000 ms  772/  773 (1e+02%) 1289.439/1289.439/1289.439/ 0.000 ms 3091 pps 3986 pkts 0.00 
[SUM] 0.00-10.03 sec  1.01 GBytes   862 Mbits/sec  733728/0    68602 pps

root@freedom-u540:~# iperf -c 0 -u -e -P 2048
...
[449] 0.00-10.02 sec  1.25 MBytes  1.05 Mbits/sec  890/0       86 pps 
[449] Sent 890 datagrams 
[449] Server Report: 
[449] 0.00-0.25 sec  1.44 KBytes  47.0 Kbits/sec   0.000 ms  898/  899 (1e+02%) 1318.279/1318.279/1318.279/ 0.000 ms 3593 pps 4737 pkts 0.00 
[SUM] 0.00-9.93 sec  1.24 GBytes  1.07 Gbits/sec  904649/0    84159 pps

Николай Малых

nmalykh@protokols.ru

Рубрика: Linux, RISC-V, Измерения и тестирование | Оставить комментарий

Тестирование производительности сети с помощью iperf

PDF

Документ соответствует iperf версии 2.0.14a (20 Jan 2020) pthreads.

Синтаксис

iperf -s [options]
iperf -c server [options]
iperf -u -s [options]
iperf -u -c server [options]

Описание

Пакет iperf служит для измерения производительности работы сети. Программа позволяет измерять пропускную способность на основе протоколов TCP и UDP. Для проведения теста нужен сервер, принимающий и отбрасывающий пакеты, и клиент, который генерирует тестовые пакеты. Клиент и сервер могут размещаться на одном (локальные тесты) или разных (тесты сети) хостах локальной или распределенной сети.

Для создания пакетов клиент использует многопотоковый (multithread) режим, что позволяет эффективно загрузить загрузить имеющиеся в системе процессорные ядра.

Опции

-b, —bandwidth

Задает полосу текстового потока и может также задавать стандартное отклонение от нормального распределения в форме <mean>,[<stdev>], которое обычно указывается в выводе. Значения могут задаваться с символьными суффиксами1.

-e, —enhanced

Задает расширенный формат вывода. В тестах UDP при расширенном выводе предполагается синхронизация часов клиента и сервера по протоколу NTP или PTP. На точность измерения задержки UDP оказывает влияние точность эталонных (опорных) часов.

-f, —format [abkmgBKMG]

Задает формат вывода и может включать значения a (адаптивный), b (биты), B (байты), k (килобиты), m (мегабиты), g (гигабиты), K (килобайты), M (мегабайты), G (гигабайты).

-h, —help

Выводит справочную информацию о программе.

-i, —interval < n[p] | f >

Задает интервал выборки или отображения n секунд (принято по умолчанию) или n пакетов (суффикс p). При использовании f интервал задает группа (burst) или кадр.

-l, —len n[kmKM]

Задает размер буфера чтения-записи (TCP) или размер пакетов (UDP) и может использовать суффиксы k, m, K, M1. По умолчанию для TCP принято n = 128K, для UDP — n = 1470.

—l2checks

Задает проверку размера кадров L2 для принятых пакетов UDP (требуется поддержка сокета пакетов).

-m, —print_mss

Задает вывод максимального размера сегментов TCP (MSS2, MTU — заголовок TCP/IP).

—NUM_REPORT_STRUCTS <count>

Переопределяет принятый по умолчанию размер общей памяти для потоков (thread) трафика и блока отчетов для снижения числа конфликтов блокировки семафора (mutex). Принятого по умолчанию значения 5000 должно быть достаточно для сетей 1 Гбит/с. Значение следует увеличит при наличии предупреждений о слишком медленных потоках. При отсутствии таких предупреждений увеличение параметра приведет лишь к дополнительному расходу памяти.

-o, —output filename

Задает запись вывода и сообщений об ошибках в указанный файл.

-p, —port n

Задает порт, используемый сервером (по умолчанию 5001).

-u, —udp

Задает использование протокола UDP вместо принятого по умолчанию TCP.

-w, —window n[kmKM]

Задает размер окна TCP (размер буфера сокета).

-z, —realtime

Запрашивает использование планировщика в реальном масштабе времени (если он поддерживается).

-B, —bind host[:port][%dev]

Задает привязку к IP-адресу хоста или групповому адресу, а также может задавать привязку к порту.

-C, —compatibility

Служит для совместимости со старыми версиями, не передающими дополнительных сообщений.

-M, —mss n

Задает максимальный размер сегмента TCP (MTU — 40 байтов).

-N, —nodelay

Отключает задержку TCP (алгоритм Nagle).

-v, —version

Выводит информацию о версии программы и завершает работу.

-x, —reportexclude [CDMSV]

Исключает отчеты о соединениях (C), данных (D), групповых пакетах (M), настройках (S) и сервере (V).

-y, —reportstyle C|c

Установка значения C или c задает вывод в формате CSV3.

-Z, —tcp-congestion

Задает используемый по умолчанию алгоритм контроля насыщения для новых соединений. Платформа должна поддерживать setsockopt TCP_CONGESTION. (см. sysctl и tcp_allowed_congestion_control).

Опции сервера

-b, —bandwidth n[kmgKMG]

Задает целевую скорость чтения n и может использовать описанные выше суффиксы (только для сервера TCP).

-s, —server

Задает работу в режиме сервера.

—histogram[=binwidth[u],bincount,[lowerci],[upperci]]

Задает вывод гистограмм задержки для пакетов (опция -u) или групп (burst) и кадров (опция —trip-times или —isochronous). binwidth — продолжительность элемента (по умолчанию 1 мсек, для мксек суффикс u), bincount — общее число элементов (по умолчанию 1000), ci — доверительный интервал между 0-100% (по умолчанию от 5% до 95%).

-B, —bind ip | ip%device

Задает привязку к IP-адресу получателя, а также может задавать привязку к порту и входному интерфейсу. Приниматься будут лишь пакеты, соответствующие заданным опцией параметрам. Опция полезна также при групповой адресации. Например, iperf -s -B 224.0.0.1%eth0 будет задавать прием групповых пакетов на входном интерфейсе eth0.

-D, —daemon

Задает работу сервера в режиме демона. В Windows это ведет к запуску заданной команды как IperfService с установкой службы при необходимости. Служба не настраивается на автоматический запуск или перезапуск и при необходимости это можно организовать с помощью сценарий инициализации или команды Windows sc.

-H, —ssm-host host

Задает хост отправителя (адрес IP) для групповых пакетов SSM (т. е. S в S,G)

-R, —remove

Удаляет службу IPerfService (только Windows).

-U, —single_udp

Задает работу в режиме UDP с одним потоком (thread).

-V, —ipv6_domain

Включает прием пакетов IPv6 путем установки домена и сокета AF_INET6 (можно принимать сразу IPv4 и IPv6).

Опции клиента

-b, —bandwidth n[kmgKMG] | npps

Задает целевую полосу в бит/с (по умолчанию 1 Мбит/с) или пакет/с для трафика TCP или UDP. Значение параметра может указываться с суффиксом, задающим единицу измерения. Кроме того, поддерживается возможность задать среднее и стандартное отклонение от нормального распределения (mean,standard)

-c, —client host | host%device

Задает работу в режиме клиента с сервером host. Необязательный параметр %device указывает выходной интерфейс (SO_BINDTODEVICE).

—connect-only

Задает лишь организацию соединений TCP без передачи реального трафика, что может быть полезно для измерения времени TCP connect().

-d, —dualtest

Задает выполнение теста одновременно в обоих направлениях.

—fq-rate n[kmgKMG]

Задает скорость, используемую при беспристрастных очередях на уровне соектов, в битах или байтах в секунду. Параметр может содержать суффикс для задания единиц измерения (строчные буквы указывают единицы в битах, прописные — в байтах). Опция доступна лишь на платформах, поддерживающих опцию сокетов SO_MAX_PACING_RATE.

—incr-dstip

Задает инкрементирование IP-адреса получателя при использовании опции -P.

—ipg n

Задает межпакетный интервал (в миллисекундах) в изохронном кадре (burst). Требует опции —isochronous

—isochronous[=fps:mean,stdev]

Задает передачу изохронного трафика с заданным числом кадров в секунду и нагрузкой, указанной средним и стандартным отклонением (mean, stdev) от нормального распределения (по умолчанию 60:20m,0). Скорость может указываться с суффиксом для задания единиц измерения (строчные буквы указывают единицы в битах, прописные — в байтах).

—no-connect-sync

По умолчанию параллельные потоки трафика (-P больше 1) будут синхронизироваться до организации соединений TCP и реальной передачи трафика, т. е. потоки (thread) сначала завершают согласование TCP 3WHS (возможно с ошибкой) и лишь после этого начинается передача трафика. Эта опция отключает такую синхронизацию и каждый поток начинает передаваться сразу после организации соединения.

—no-udp-fin

Отключает выполнение завершающего обмена UDP от сервера к клиенту, в результате чего у клиента не будут выводиться сообщения от сервера. Все пакеты в тесте будут передаваться только от клиента к серверу без передачи пакетов в обратном направлении. Эта опция устанавливается клиентом и передается серверу (начиная с версии 2.0.14).

-n, —num n[kmKM]

Число байтов для передачи (вместо -t)

-r, —tradeoff

Выполнять двухсторонние тесты по направлениям, сначала от клиента к серверу, затем обратно.

-t, —time n

Время прослушивания новых соединений (в секундах), приема или передачи трафика. По умолчанию передача длится 10 секунд, а прием и прослушивание не ограничены во времени.

—trip-times

Включает измерение задержки записи (или передачи данных) в тесте TCP. Требуется синхронизация часов.

—txdelay-time

Время (в секундах) удержания или задержки между организацией соединения TCP и записью в сокет, а для UDP — задержки между стартом потока трафика и первой записью.

—txstart-time n.n

Устанавливает начало передачи (n.n) по времени unix или epoch (с поддержкой наносекундного разрешения, например, 1536014418.839992457).

-B, —bind ip | ip:port | ipv6 -V | [ipv6]:port -V

Задает IP-адрес отправителя, а также позволяет задать порт отправителя и выходное устройство (%device) для передачи пакетов. Опция влияет на системные вызовы bind() и обычно служит для привязки к определенному адресу IP и порту отправителя (например, iperf -c <host> -B 192.168.100.2:6002). Это задает источник пакетов но не применяется при маршрутизации. Здесь может возникнуть путаница при просмотре маршрутов и устройств. Например, если IP-адрес интерфейса eth0 указан в опции -B, а таблица маршрутизации для IP-адреса получателя (опция -c) указывает выходной интерфейс eth1, хост будет передавать через интерфейс eth1 пакеты с IP-адресом интерфейса eth0. Для задания выходного интерфейса в системе с несколькими подключениями следует применять форму -c <host>%device (требуются полномочия root) для обхода поиска в таблице маршрутизации хоста или настроить таблицу маршрутизации хоста для каждой опции -B соответствующим образом и задать выходные интерфейсы в правилах.

Указание выходного интерфейса требуется при использовании адресов IPv6 link-local.

-F, —fileinput name

Задает считывание передаваемых данных из файла.

-I, —stdin

Задает считывание передаваемых данных со стандартного устройства ввода (stdin).

-L, —listenport n

Задает порт для приема возвращаемых пакетов.

-P, —parallel n

Задает число параллельных потоков (thread), запускаемых клиентом.

-R, —reverse

Задает обращение (реверс) потока трафика после обмена заголовками и может быть полезно при тестировании через межсетевые экраны4.

-S, —tos

Устанавливает значение поля IP_TOS для сокета (1 байт).

-T, —ttl n

Задает TTL для группового трафика (по умолчанию 1)

-V, —ipv6_domain

Задает домен для IPv6 (передача пакетов по IPv6).

-X, —peerdetect

Задает определение версии сервера до начала обмена трафиком.

-Z, —linux-congestion algo

Задает алгоритм контроля насыщения TCP (только для Linux).

Примеры

Тест TCP (клиент)

iperf -c <host> -e -i 1 
------------------------------------------------------------ 
Client connecting to <host>, TCP port 5001 with pid 5149 
Write buffer size:  128 KByte 
TCP window size:  340 KByte (default) 
------------------------------------------------------------ 
[  3] local 45.56.85.133 port 49960 connected with 45.33.58.123 port 5001 (ct=3.23 ms) 
[ ID] Interval        Transfer    Bandwidth       Write/Err  Rtry     Cwnd/RTT        NetPwr 
[  3] 0.00-1.00 sec   126 MBytes  1.05 Gbits/sec  1006/0        0       56K/626 us  210636.47 
[  3] 1.00-2.00 sec   138 MBytes  1.15 Gbits/sec  1100/0      299     483K/3884 us  37121.32 
[  3] 2.00-3.00 sec   137 MBytes  1.15 Gbits/sec  1093/0       24     657K/5087 us  28162.31 
[  3] 3.00-4.00 sec   126 MBytes  1.06 Gbits/sec  1010/0      284     294K/2528 us  52366.58 
[  3] 4.00-5.00 sec   117 MBytes   980 Mbits/sec  935/0       373     487K/2025 us  60519.66 
[  3] 5.00-6.00 sec   144 MBytes  1.20 Gbits/sec  1149/0        2     644K/3570 us  42185.36 
[  3] 6.00-7.00 sec   126 MBytes  1.06 Gbits/sec  1011/0      112     582K/5281 us  25092.56 
[  3] 7.00-8.00 sec   110 MBytes   922 Mbits/sec  879/0        56     279K/1957 us  58871.89 
[  3] 8.00-9.00 sec   127 MBytes  1.06 Gbits/sec  1014/0       46     483K/3372 us  39414.89 
[  3] 9.00-10.00 sec  132 MBytes  1.11 Gbits/sec  1054/0        0     654K/3380 us  40872.75 
[  3] 0.00-10.00 sec 1.25 GBytes  1.07 Gbits/sec  10251/0    1196      -1K/3170 us  42382.03

где (с учетом -e)

ct=

Время соединения TCP (время трехэтапного согласования 3WHS).

Write/Err

Общее число успешных записей в сокет и общее число некритических ошибок записи в сокет.

Rtry

Общее число попыток TCP.

Cwnd/RTT (только *nix)

Окно насыщения TCP и время кругового обхода (выборка)

NetPwr (только *nix)

Отношение пропускной способности к RTT.

Тест TCP (сервер)

iperf -s -e -i 1 -l 8K 
------------------------------------------------------------ 
Server listening on TCP port 5001 with pid 13430 
Read buffer size: 8.00 KByte 
TCP window size: 85.3 KByte (default) 
------------------------------------------------------------ 
[  4] local 45.33.58.123 port 5001 connected with 45.56.85.133 port 49960 
[ ID] Interval        Transfer    Bandwidth       Reads   Dist(bin=1.0K) 
[  4] 0.00-1.00 sec   124 MBytes  1.04 Gbits/sec  22249    798:2637:2061:767:2165:1563:589:11669 
[  4] 1.00-2.00 sec   136 MBytes  1.14 Gbits/sec  24780    946:3227:2227:790:2427:1888:641:12634 
[  4] 2.00-3.00 sec   137 MBytes  1.15 Gbits/sec  24484    1047:2686:2218:810:2195:1819:728:12981 
[  4] 3.00-4.00 sec   126 MBytes  1.06 Gbits/sec  20812    863:1353:1546:614:1712:1298:547:12879 
[  4] 4.00-5.00 sec   117 MBytes   984 Mbits/sec  20266    769:1886:1828:589:1866:1350:476:11502 
[  4] 5.00-6.00 sec   143 MBytes  1.20 Gbits/sec  24603    1066:1925:2139:822:2237:1827:744:13843 
[  4] 6.00-7.00 sec   126 MBytes  1.06 Gbits/sec  22635    834:2464:2249:724:2269:1646:608:11841 
[  4] 7.00-8.00 sec   110 MBytes   921 Mbits/sec  21107    842:2437:2747:592:2871:1903:496:9219 
[  4] 8.00-9.00 sec   126 MBytes  1.06 Gbits/sec  22804    1038:1784:2639:656:2738:1927:573:11449 
[  4] 9.00-10.00 sec   133 MBytes 1.11 Gbits/sec  23091    1088:1654:2105:710:2333:1928:723:12550 
[  4] 0.00-10.02 sec  1.25 Gbytes 1.07 Gbits/sec  227306   9316:22088:21792:7096:22893:17193:6138:120790

где (с учетом -e)

Reads

Общее число считываний сокета.

Dist(bin=size)

8 элементов (bin) гистограммы чтения, возвращенных клиентом и разделяемых двоеточиями. В примере это элементы 0-1K, 1K-2K, .., 7K-8K.

Тест TCP (сервер) с опцией —trip-times на стороне клиента

iperf -s -e -i 1 

------------------------------------------------------------ 
Server listening on TCP port 5001 with pid 30369 
Read buffer size:  128 KByte 
TCP window size: 85.3 KByte (default) 
------------------------------------------------------------ 
[  4] local 10.19.87.7 port 5001 connected with 10.19.87.10 port 43338 (trip-times) 
[ ID] Interval        Transfer    Bandwidth       Reads   Dist(bin=16.0K)           Burst Latency avg/min/max/stdev (cnt/size) inP      NetPwr 
[  4] 0.00-1.00 sec   112 MBytes   941 Mbits/sec  7000    1552:5447:1:0:0:0:0:0     8.749/ 1.583/10.340/ 1.011 ms (897/131127) 1029057 bytes 13444.08 
[  4] 1.00-2.00 sec   112 MBytes   941 Mbits/sec  7015    1562:5453:0:0:0:0:0:0     8.790/ 7.131/10.443/ 0.878 ms (898/131050) 1034467 bytes 13387.92 
[  4] 2.00-3.00 sec   112 MBytes   941 Mbits/sec  7009    1543:5466:0:0:0:0:0:0     8.799/ 7.050/10.389/ 0.869 ms (897/131170) 1035306 bytes 13371.80 
[  4] 3.00-4.00 sec   112 MBytes   941 Mbits/sec  7032    1589:5442:1:0:0:0:0:0     8.810/ 7.128/10.437/ 0.877 ms (898/131047) 1036818 bytes 13356.91 
[  4] 4.00-5.00 sec   112 MBytes   941 Mbits/sec  7013    1556:5457:0:0:0:0:0:0     8.805/ 7.244/10.352/ 0.874 ms (898/131050) 1036239 bytes 13365.03 
[  4] 5.00-6.00 sec   112 MBytes   941 Mbits/sec  6999    1554:5440:3:1:0:0:0:1    10.384/ 7.257/12.712/ 1.284 ms (898/131050) 1222077 bytes 11332.64 
[  4] 6.00-7.00 sec   112 MBytes   941 Mbits/sec  7015    1568:5447:0:0:0:0:0:0    10.682/ 8.714/12.711/ 1.121 ms (898/131045) 1257085 bytes 11016.23 
[  4] 7.00-8.00 sec   112 MBytes   941 Mbits/sec  7010    1557:5453:0:0:0:0:0:0    10.683/ 8.681/12.695/ 1.125 ms (898/131050) 1257237 bytes 11015.71 
[  4] 8.00-9.00 sec   112 MBytes   941 Mbits/sec  7016    1570:5446:0:0:0:0:0:0    10.674/ 8.704/12.679/ 1.128 ms (897/131193) 1256177 bytes 11024.46 
[  4] 9.00-10.00 sec  112 MBytes   941 Mbits/sec  7062    1624:5438:0:0:0:0:0:0    10.693/ 8.624/12.681/ 1.127 ms (898/131047) 1258342 bytes 11005.49 
[  4] 10.00-10.01 sec  1.28 MBytes 939 Mbits/sec  80      17:63:0:0:0:0:0:0        11.582/ 8.761/12.361/ 1.191 ms (11/121860) 1359148 bytes 10131.78 
[  4] 0.00-10.01 sec  1.10 GBytes  941 Mbits/sec  70251   15692:54552:5:1:0:0:0:1   9.699/11.582/11.582/ 0.000 ms (8988/131072) 1141261 bytes 12133.03 

где (с учетом -e)

Burst Latency

Односторонная задержка TCP от write() до read() в формате среднее/минимальное/максимальное/стандартное отклонение. Требуется синхронизация часов клиента и сервера от одного источника (например, по протоколу PTP). Рекомендуется применять опорный источник GPS OCXO.

cnt

Число принятых завершенных групп (burst), использованных для расчета задержки.

size

Средний размер группы (burst) в байтах (только для оценки).

inP

Сокращение для in progress (в работе). Указывает среднее число байтов, находящихся в обработке или «на лету» (в сети) с точки зрения записывающего приложения5.

NetPwr

Отношение пропускной способности к задержке в одном направлении.

Тест UDP (клиент)

iperf -c <host> -e -i 1 -u -b 10m 
------------------------------------------------------------ 
Client connecting to <host>, UDP port 5001 with pid 5169 
Sending 1470 byte datagrams, IPG target: 1176.00 us (kalman adjust) 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 45.56.85.133 port 32943 connected with 45.33.58.123 port 5001 
[ ID] Interval        Transfer     Bandwidth      Write/Err  PPS 
[  3] 0.00-1.00 sec  1.19 MBytes  10.0 Mbits/sec  852/0      851 pps 
[  3] 1.00-2.00 sec  1.19 MBytes  10.0 Mbits/sec  850/0      850 pps 
[  3] 2.00-3.00 sec  1.19 MBytes  10.0 Mbits/sec  850/0      850 pps 
[  3] 3.00-4.00 sec  1.19 MBytes  10.0 Mbits/sec  851/0      850 pps 
[  3] 4.00-5.00 sec  1.19 MBytes  10.0 Mbits/sec  850/0      850 pps
[  3] 5.00-6.00 sec  1.19 MBytes  10.0 Mbits/sec  850/0      850 pps 
[  3] 6.00-7.00 sec  1.19 MBytes  10.0 Mbits/sec  851/0      850 pps 
[  3] 7.00-8.00 sec  1.19 MBytes  10.0 Mbits/sec  850/0      850 pps 
[  3] 8.00-9.00 sec  1.19 MBytes  10.0 Mbits/sec  851/0      850 pps 
[  3] 0.00-10.00 sec 11.9 MBytes  10.0 Mbits/sec  8504/0     850 pps 
[  3] Sent 8504 datagrams 
[  3] Server Report: 
[  3] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.047 ms 0/ 8504 (0%) 0.537/ 0.392/23.657/ 0.497 ms 850 pps 2329.37 

где (с учетом -e)

Write/Err

Общее число успешных записей в сокет и некритичных ошибок при записи в сокет.

PPS

Число переданных в секунду пакетов.

Тест UDP (сервер)

iperf -s -e -i 1 -u 
------------------------------------------------------------ 
Server listening on UDP port 5001 with pid 13496 
Receiving 1470 byte datagrams 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 45.33.58.123 port 5001 connected with 45.56.85.133 port 32943 
[ ID] Interval        Transfer     Bandwidth        Jitter   Lost/Total      Latency avg/min/max/stdev      PPS      NetPwr 
[  3] 0.00-1.00 sec  1.19 MBytes  10.0 Mbits/sec   0.057 ms    0/  851 (0%)  0.475/ 0.408/ 1.898/ 0.090 ms  851 pps  2633.56 
[  3] 1.00-2.00 sec  1.19 MBytes  10.0 Mbits/sec   0.039 ms    0/  851 (0%)  0.669/ 0.405/16.256/ 1.375 ms  850 pps  1869.32 
[  3] 2.00-3.00 sec  1.19 MBytes  10.0 Mbits/sec   0.038 ms    0/  850 (0%)  0.795/ 0.395/23.657/ 2.138 ms  850 pps  1572.05 
[  3] 3.00-4.00 sec  1.19 MBytes  10.0 Mbits/sec   0.045 ms    0/  850 (0%)  0.475/ 0.403/ 3.477/ 0.148 ms  850 pps  2628.58 
[  3] 4.00-5.00 sec  1.19 MBytes  10.0 Mbits/sec   0.043 ms    0/  851 (0%)  0.463/ 0.400/ 1.458/ 0.068 ms  850 pps  2699.88 
[  3] 5.00-6.00 sec  1.19 MBytes  10.0 Mbits/sec   0.032 ms    0/  850 (0%)  0.486/ 0.404/ 2.658/ 0.154 ms  850 pps  2572.21 
[  3] 6.00-7.00 sec  1.19 MBytes  10.0 Mbits/sec   0.055 ms    0/  850 (0%)  0.469/ 0.404/ 2.768/ 0.108 ms  850 pps  2664.82 
[  3] 7.00-8.00 sec  1.19 MBytes  10.0 Mbits/sec   0.039 ms    0/  851 (0%)  0.571/ 0.400/12.452/ 0.855 ms  850 pps  2192.68 
[  3] 8.00-9.00 sec  1.19 MBytes  10.0 Mbits/sec   0.083 ms    0/  850 (0%)  0.475/ 0.392/ 3.702/ 0.196 ms  850 pps  2628.29 
[  3] 9.00-10.00 sec 1.19 MBytes  10.0 Mbits/sec   0.047 ms    0/  850 (0%)  0.493/ 0.396/ 6.010/ 0.343 ms  850 pps  2534.89 
[  3] 0.00-10.00 sec 11.9 MBytes  10.0 Mbits/sec   0.047 ms    0/ 8504 (0%)  0.537/ 0.392/23.657/ 0.867 ms  850 pps  2329.37 

где (с учетом -e)

Latency

Сквозная задержка в формате средняя/минимальная/максимальная/стандартная. Для теста требуется синхронизация часов клиента и сервера от одного источника (например, по протоколу PTP). Рекомендуется источник синхронизации GPS OCXO.

PPS

Число принятых в секунду пакетов.

NetPwr

Отношение пропускной способности к задержке.

Изохронный тест UDP (клиент)

iperf -c 192.168.100.33 -u -e -i 1 --isochronous=60:100m,10m --realtime 
------------------------------------------------------------ 
Client connecting to 192.168.100.33, UDP port 5001 with pid 14971 
UDP isochronous: 60 frames/sec mean= 100 Mbit/s, stddev=10.0 Mbit/s, Period/IPG=16.67/0.005 ms 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 192.168.100.76 port 42928 connected with 192.168.100.33 port 5001 
[ ID] Interval        Transfer     Bandwidth      Write/Err  PPS  frames:tx/missed/slips
[  3] 0.00-1.00 sec  12.0 MBytes   101 Mbits/sec  8615/0     8493 pps   62/0/0 
[  3] 1.00-2.00 sec  12.0 MBytes   100 Mbits/sec  8556/0     8557 pps   60/0/0 
[  3] 2.00-3.00 sec  12.0 MBytes   101 Mbits/sec  8586/0     8586 pps   60/0/0 
[  3] 3.00-4.00 sec  12.1 MBytes   102 Mbits/sec  8687/0     8687 pps   60/0/0 
[  3] 4.00-5.00 sec  11.8 MBytes  99.2 Mbits/sec  8468/0     8468 pps   60/0/0 
[  3] 5.00-6.00 sec  11.9 MBytes  99.8 Mbits/sec  8519/0     8520 pps   60/0/0 
[  3] 6.00-7.00 sec  12.1 MBytes   102 Mbits/sec  8694/0     8694 pps   60/0/0 
[  3] 7.00-8.00 sec  12.1 MBytes   102 Mbits/sec  8692/0     8692 pps   60/0/0 
[  3] 8.00-9.00 sec  11.9 MBytes   100 Mbits/sec  8537/0     8537 pps   60/0/0 
[  3] 9.00-10.00 sec 11.8 MBytes  99.0 Mbits/sec  8450/0     8450 pps   60/0/0 
[  3] 0.00-10.01 sec  120 MBytes   100 Mbits/sec  85867/0    8574 pps  602/0/0 
[  3] Sent 85867 datagrams 
[  3] Server Report: 
[  3] 0.00-9.98 sec 120 MBytes 101 Mbits/sec 0.009 ms 196/85867 (0.23%) 0.665/ 0.083/ 1.318/ 0.174 ms 8605 pps 18903.85

где (с учетом -e)

frames:tx/missed/slips

Общее число изохронных кадров или групп (burst), общее число не переданных идентификаторов кадров, общее число проскальзываний (slip) кадров

Изохронный тест UDP (сервер)

iperf -s -e -u --udp-histogram=100u,2000 --realtime 
------------------------------------------------------------ 
Server listening on UDP port 5001 with pid 5175 
Receiving 1470 byte datagrams 
UDP buffer size:  208 KByte (default) 
------------------------------------------------------------ 
[  3] local 192.168.100.33 port 5001 connected with 192.168.100.76 port 42928 isoch (peer 2.0.13-alpha) 
[ ID] Interval        Transfer     Bandwidth        Jitter   Lost/Total        Latency avg/min/max/stdev PPS            NetPwr  Frames/Lost 
[  3] 0.00-9.98 sec   120 MBytes   101 Mbits/sec   0.010 ms  196/85867 (0.23%)  0.665/ 0.083/ 1.318/ 0.284 ms 8585 pps  18903.85  601/1 
[  3] 0.00-9.98 sec   T8(f)-PDF:   bin(w=100us):cnt(85671)=1:2,2:844,3:10034,4:8493,5:8967,6:8733,7:8823,8:9023,9:8901,10:8816,11:7730,12:4563,13:741,14:1    (5.00/95.00%=3/12,Out-liers=0,obl/obu=0/0) 
[  3] 0.00-9.98 sec F8(f)-PDF: bin(w=100us):cnt(598)=15:2,16:1,17:27,18:68,19:125,20:136,21:103,22:83,23:22,24:23,25:5,26:3 (5.00/95.00%=17/24,Outliers=0,obl/obu=0/0) 

где (с учетом -e)

Frames/lost

Общее число полученных кадров (групп), общее число потерянных или ошибочных кадров.

T8-PDF(f)

Гистограмма задержки для пакетов.

F8-PDF(f)

Гистограмма задержки для кадров.

Примечания

  1. Установка параметров окружения в iperf не поддерживается должным образом, как можно видеть в исходном коде.

  2. Опция -B задает привязку на логическом (ip) и физическом (%device) уровне для клиента и сервера. У клиента влияет на системные вызовы bind() и обычно служит для привязки к определенному адресу IP и порту отправителя (например, iperf -c <host> -B 192.168.100.2:6002). Это задает источник пакетов но не применяется при маршрутизации. Здесь может возникнуть путаница при просмотре маршрутов и устройств. Например, если IP-адрес интерфейса eth0 указан в опции -B, а таблица маршрутизации для IP-адреса получателя (опция -c) указывает выходной интерфейс eth1, хост будет передавать через интерфейс eth1 пакеты с IP-адресом интерфейса eth0. Для задания выходного интерфейса в системе с несколькими подключениями следует применять форму -c <host>%device (требуются полномочия root) для обхода поиска в таблице маршрутизации хоста или настроить таблицу маршрутизации хоста соответствующим образом.

  3. Время соединения (трехэтапного согласования) TCP можно увидеть на стороне клиента iperf при работе с опцией -e (—enhanced). Поле ct=<value> в сообщениях о соединении (например. [ 3] local 192.168.1.4 port 48736 connected with 192.168.1.1 port 5001 (ct=1.84 ms) показывает, что 3WHS составляет 1,84 мсек).

  4. Параметр NetPwr6 является экспериментальным. Значение поля определяется отношением пропускной способности к задержке в сети. Для TCP в качестве задержки применяется период кругового обхода (RTT), для UDP — измеренное время сквозной задержки. Не следует воспринимать слово «мощность» (power) буквально, как величину работы, выполненной за единицу времени. Следует также отметить, что должна использоваться опция -i interval с протоколом TCP для задания частоты выборки RTT.

Сведения об ошибках

См. https://sourceforge.net/p/iperf2/tickets/

Авторы

Программа iperf2, созданная на основе iperf (разработка Mark Gates и Alex Warshavsky), стала более удобной и функциональной. В разработке участвовали Ajay Tirumala, Jim Ferguson, Jon Dugan <jdugan at x1024 dot net>, Feng Qin, Kevin Gibbs, John Estabrook <jestabro at ncsa.uiuc.edu>, Andrew Gallatin <gallatin at gmail.com>, Stephen Hemminger  <shemminger at linux-foundation.org>, Tim Auckland <tim.auckland at gmail.com>, Robert J. McMahon <rjmcmahon at rjmcmahon.com>.

Исходный код

http://sourceforge.net/projects/iperf2/

 

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Некоторые числовые опции поддерживают указание единиц в форме <value>c (например, 10M), где c задает единицу измерения и может принимать значения k, m, g, K, M, G. Символы нижнего регистра указывают единицы на основе десятичных значений (103, 106, 109), а символы верхнего регистра — на основе двоичных (2n — 1K = 1024, 1M = 1048576, 1G = 1073741824).

2Maximum segment size.

3Comma separated values — разделенные запятыми значения.

4Опции —reverse (-R), -r и -d вызывают путаницу. Если нужно выполнить тест через шлюз NAT, следует применять опцию —reverse (или -R в системах, отличных от Windows). Опции -d и -r сохранены для совместимости. Вновь открытые и исходные сокеты работают в полнодуплексном режиме. Работа через межсетевой экран обычно требует использовать -d, опция -r нужна при работе через шлюз NAT. Кроме того, установка —reverse -b <rate> дает несколько отличающийся эффект. Для TCP это будет ограничивать скорость на читающей стороне, т. е. скорость чтения клиентом iperf из полнодуплексного сокета. Это будет приводить к использования стандартного контроля насыщения TCP для реверсированного трафика. Опции —reverse -b <rate> должны применяться на передающей стороне (т. е., на обращенном сервере) для трафика UDP, поскольку здесь нет управления потоком трафика.

5Закон Литтла (Little) в теории очередей определяет среднее число элементов (L) в стационарной системе очередей на основе средневзвешенного времени (W) нахождения элемента в системе и среднего числа элементов, прибывающих в систему за единицу времени (lambda). Математически это выражается в форме L = lambda * W. Здесь элементами TCP являются байты, а UDP — пакеты.

6Network power — «мощность» сети.

Рубрика: Linux | Комментарии к записи Тестирование производительности сети с помощью iperf отключены

Справочник по командному процессору Bash

PDF

Редакция 5.0 для Bash версии 5.0.

Декабрь 2018 г.

Chet Ramey, Case Western Reserve University.

Brian Fox, Free Software Foundation.

Этот документ является кратким описанием свойств командного процессора (оболочки) Bash (версия 5.0, 7 декабря 2018 г.). Данная редакция 5.0 обновлена 7 декабря 2018 г. Copyright c 1988–2018 Free Software Foundation, Inc.

Разрешается копировать, распространять и/или изменять этот документ в соответствии с лицензией GNU Free Documentation License версии 1.3 или более поздней версии, опубликованной Free Software Foundation, без инвариантных разделов, а также текста передней и задней обложки. Копия лицензии представлена в разделе Приложение C. GNU Free Documentation License.

1. Введение

1.1. Что такое Bash?

Bash является «оболочкой» или интерпретатором команд для операционных систем GNU. Имя служит сокращением Bourne-Again Shell. Stephen Bourne является автором прямого предка современного интерпретатора Unix sh из седьмой редакции Bell Labs Research Unix.

Интерпретатор bash в значительной степени совместим с sh и включает полезные свойства интерпретаторов Korn (ksh) и C (csh). Предполагается, что это будет совместимая реализация части Shell and Tools спецификации IEEE POSIX (IEEE Standard 1003.1). Интерпретатор предлагает функциональные улучшения sh для интерактивного и программируемого применения. Хотя операционные системы GNU включают другие интерпретаторы, такие как csh, по умолчанию применяется bash. Как и другие программы GNU интерпретатор bash является переносимым. В настоящее время он работает практически на всех версиях Unix и некоторых других операционных систем. Имеются независимые реализации для платформ MS-DOS, OS/2 и Windows.

1.2. Что такое оболочка?

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

Оболочки Unix являются одновременно интерпретаторами команд и языками программирования. В качестве интерпретатора команд оболочка служит интерфейсом между пользователем и обширным набором утилит GNU. Свойства языка программирования позволяют комбинировать эти утилиты. Могут создаваться файлы с командами, которые сами могут служить командой. Эти новые команды имеют такой же статус как системные команды в каталогах типа /bin, давая пользователям и группам возможность организации среды для автоматизации своих задач. Оболочки могут использоваться в интерактивном или командном режиме. В первом случае выполняются команды, введенные пользователем, во втором — считанные из файла.

Оболочка позволяет выполнять команды GNU в синхронном или асинхронном режиме. В синхронном режиме оболочка ждет завершения команды перед восприятием последующего ввода, асинхронные команды могут выполняться параллельно с чтением и выполнением оболочкой других команд. Перенаправление позволяет контролировать ввод и вывод команд. Кроме того, оболочка позволяет контролировать содержимое командных сред.

Оболочки включают небольшой набор внутренних команд (builtin), реализующих функции, которые невозможно или неудобно реализовать в отдельных утилитах. Например, команды cd, break, continue и exec не могут быть реализованы вне оболочки, поскольку они напрямую манипулируют этой оболочкой. Команды history, getopts, kill или pwd, наряду с другими, могут быть реализованы в отдельных утилитах, но внутренние команды более удобны. Хотя интерпретация и выполнение команд важны, большая часть возможностей (и сложностей) оболочек связана со встроенными языками программирования. Подобно языкам высокого уровня они включают переменные, конструкции управления потоком, кавычки и функции.

Оболочки предоставляют также функции, предназначенные для интерактивного применения, а не для программирования. Эти интерактивные функции включают управление заданиями, редактирование команд, историю команд и псевдонимы.

2. Определения

POSIX

Семейство стандартов для открытых систем на базе Unix. Bash относится в основном к части Shell and Utilities стандарта POSIX 1003.1.

blank

Символ пробела или табуляции.

builtin — внутренняя команда

Команда, реализованная внутри оболочки, а не во внешней программе на файловой системе.

control operator — оператор управления

Маркер, выполняющий функцию управления. Это может быть перевод строки или одна из последовательностей ||, &&, &, ;, ;;, ;&, ;;&, |, |&, (, ).

exit status — статус выхода

Значение, возвращаемое командой по завершении (0 — 255).

field — поле

Блок текста, являющийся результатом одного или нескольких shell-преобразований (expansion). После преобразования при выполнении команды результирующие поля применяются как имена команд и аргументы.

filename — имя файла

Строка символов, служащая для идентификации файла.

job -задание

Набор процессов, образующих конвейер (pipeline), и все процессы-потомки, относящиеся к одной группе.

job control — управление заданием

Механизм, с помощью которого можно селективно останавливать (suspend) и возобновлять (resume) процессы.

metacharacter — метасимвол

Символ, который при использовании без кавычек является разделителем слов. Метасимволы включают пробел, символ табуляции, перевод строки, а также символы |, &, ;, (, ), <, и >.

name — имя

Слово, состоящее лишь из букв, цифр и символов подчеркивания, начинающееся с буквы или символа подчеркивания. Имена используется для shell-переменных и функций, иногда их называют идентификаторами.

operator — оператор

Оператор управления или перенаправления (см. параграф 3.6. Перенаправление). Оператор содержит хотя бы один метасимвол без кавычек.

process group — группа процессов

Набор связанных процессов, имеющих общий идентификатор группы.

process group ID — идентификатор группы процессов

Уникальный идентификатор, представляющий группу процессов при их выполнении.

reserved word — зарезервированное слово

Слово, имеющее в оболочке специальное назначение. Большинство зарезервированных слов служит для создания конструкций управления потоком, например, for и while.

return status — статус возврата

Синоним статуса выхода (завершения).

signal — сигнал

Механизм, с помощью которого ядро может уведомить процесс о произошедшем в системе событии.

special builtin — специальная внутренняя команда

Внутренняя команда оболочки, указанная стандартном POSIX как специальная (особая).

token — маркер

Последовательность символов, воспринимаемая оболочкой как единый блок. Маркер — это слово или оператор.

word — слово

Последовательность символов, трактуемая как слово. Слова не могут включать метасимволы без кавычек.

3. Базовые свойства

Bash — это сокращение Bourne-Again SHell. Bourne shell — традиционная оболочка Unix, написанная изначально Stephen Bourne. Все внутренние функции Bourne shell доступны в bash, правила преобразования и работы с кавычками взяты из спецификации POSIX для «стандартной» оболочки Unix.

В этой главе кратко описаны основные компоненты оболочек — команды, управляющие структуры, функции, параметры, преобразования, перенаправления, обеспечивающие возможность направлять ввод и вывод в именованные файлы и из них, а также выполнение команд оболочки.

3.1. Синтаксис

При чтении входных данных выполняется последовательность операций. Если входные данные указывают начало комментария, командный процессор игнорирует символ # и оставшуюся часть строки.

В иных случаях, упрощенно говоря, оболочка считывает ввод и делит его на слова и операторы, используя правила преобразования кавычек для выбора трактовки слов и символов.

Затем процессор разбирает полученные маркеры на команды и другие конструкции, удаляя специальную трактовку некоторых слов и символов и преобразуя иные, перенаправляет ввод и вывод, выполняет специальные команды, ждет результата завершения команды и делает код завершения доступным для дальнейшей проверки или обработки.

3.1.1. Операции

Ниже приведен краткий список операций командного процессора при чтении и выполнении команд

  1. Чтение ввода из файла (3.8. Сценарии оболочки), из строки, представленной в качестве аргумента опции -c при вызове (6.1. Вызов Bash), или с пользовательского терминала.

  2. Разбиение входных данных на слова и операторы в соответствии с правилами обработки кавычек из параграфа 3.1.2. Кавычки. Эти маркеры разделяются метасимволами. Здесь же выполняется преобразование псевдонимов (6.6. Псевдонимы).

  3. Разбор маркеров на простые и составные команды (3.2. Команды).

  4. Выполнение различных преобразований (3.5. Преобразования) с разбиением преобразованных маркеров на имена файлов (3.5.8. Преобразование имен файлов), команды и аргументы.

  5. Выполнение требуемых перенаправлений (3.6. Перенаправление) с удалением операторов и операндов перенаправления из списка аргументов.

  6. Выполнение команды (3.7. Выполнение команд).

  7. Необязательное ожидание завершения команды и получения статуса выхода (3.7.5. Статус выхода).

3.1.2. Кавычки

Кавычки служат для обхода специальной трактовки некоторых символов и слов командным процессором. Это может использоваться для отключения специальной трактовки особых символов и зарезервированных слов, а также для отключения преобразований параметров.

Каждый из метасимволов (2. Определения) имеет для командного процессора особый смысл и должен помещаться в кавычки для обычной трактовки. При использовании средств преобразования истории команд (9.3. Преобразование истории) символ преобразования истории (обычно !) должен заключаться в кавычки, чтобы предотвратить преобразование. Более подробно преобразование истории рассмотрено в параграфе 9.1. Средства Bash History.

Имеется три механизма «кавычек» — escape-символы, одинарные и двойные кавычки.

3.1.2.1. Экранирование символов

Символ обратной дробной черты (\) без кавычек является в Bash символом экранирования (escape). Он сохраняет буквальное значение следующего за ним символа, за исключением перевода строки. При получении последовательности \newline без кавычек она трактуется как продолжение текста на следующей строке (т. е. просто удаляется из входного потока).

3.1.2.2. Одинарные кавычки

Заключение символов в одинарные кавычки (’) обеспечивает буквальную трактовку каждого символа внутри кавычек. Одинарные кавычки не могут помещаться внутри другой пары одинарных кавычек даже с символом экранирования.

3.1.2.3. Двойные кавычки

Заключение символов в двойные кавычки («) обеспечивает буквальную трактовку каждого символа внутри кавычек, за исключением символов $, ‘, \, а при преобразовании истории еще и символа !. При работе оболочки в режиме POSIX (6.11. Режим POSIX) символ ! не имеет особого значения внутри двойных кавычек даже при включенном преобразовании истории. Символы $ и ‘ сохраняют особое значение даже в двойных кавычках (3.5. Преобразования). Символ \ сохраняет особое значение лишь в тех случаях, когда за ним следует символ $, ‘, «, \ или newline (в таких случаях символ просто удаляется). Символ \ перед символами, не имеющими особого значения, сохраняется. Двойные кавычки могут применяться внутри двойных кавычек при использовании с символом экранирования \. При включенном преобразовании истории оно будет выполняться, пока символ ! в двойных кавычках не экранирован символом \ (не удаляется перед !). Специальные символы * и @ имеют особую трактовку в двойных кавычках (3.5.3. Преобразование параметров оболочки).

3.1.2.4. Кавычки ANSI-C

Слова в форме $’string’ обрабатываются особо. Слово преобразуется в строку с заменой экранированных \ символов в соответствии со стандартом ANSI C. Escape-последовательности декодируются, как описано ниже.

\a

Сигнал (звонок).

\b

«Забой» (backspace).

\e
\E

Символ экранирования (не ANSI C).

\f

Перевод страницы (form feed).

\n

Новая строка.

\r

Возврат каретки.

\t

Горизонтальная табуляция.

\v

Вертикальная табуляция.

\\

Обратная дробная черта (\).

\’

Одинарная кавычка.

Двойная кавычка.

\?

Знак вопроса.

\nnn

Восьмибитовый символ с восьмеричным кодом nnn (1-3 восьмеричных цифры).

\xHH

Восьмибитовый символ с шестнадцатеричным кодом HH (1-2 шестнадцатеричных цифры).

\uHHHH

Символ Unicode (ISO/IEC 10646) с шестнадцатеричным кодом HHHH (1-4 шестнадцатеричных цифры)

\UHHHHHHHH

Символ Unicode (ISO/IEC 10646) с шестнадцатеричным кодом HHHHHHHH (1-8 шестнадцатеричных цифр)

\cx

Символ control-x.

Преобразованный результат помещается в одинарные кавычки как при отсутствии символа $.

3.1.2.5. Зависимая от языка трансляция

Строка в двойных кавычках с предшествующим символом $ будет преобразовываться в соответствии с текущим языком (locale). Если в качестве locale задан C или POSIX, символ $ игнорируется. Если строка транслируется и заменяется, результат помещается в двойные кавычки. Некоторый системы используют каталог сообщений, определяемый переменной LC_MESSAGES, другие создают имя каталога сообщений из значения переменной окружения TEXTDOMAIN, возможно с добавлением суффикса .mo. При использовании переменной TEXTDOMAIN может потребоваться установка в TEXTDOMAINDIR местоположения файлов каталога сообщений. Иногда используются обе переменные в стиле TEXTDOMAINDIR/LC_MESSAGES/LC MESSAGES/TEXTDOMAIN.mo.

3.1.3. Комментарии

В неинтерактивной оболочке или в интерактивной со включенной опцией interactive_comments внутренней функции shopt (4.3.2. Внутренняя команда shopt) слово, начинающееся с # и последующие символы до конца строки игнорируются. Интерактивная оболочка без включенной опции interactive_comments не поддерживает комментарии. Опция interactive_comments включена по умолчанию в интерактивных оболочках, описание которых приведено в разделе 6.3. Интерактивные оболочки.

3.2. Команды

Простые команды, такие как echo a b c, состоят из слова команды и разделенных пробелами аргументов. Более сложные команды состоят из простых команд, сгруппированных тем или иным способом — в конвейер, где вывод одной команды служит вводом для другой, цикл или конструкцию с условием.

3.2.1. Простые команды

Простые команды применяются наиболее часто и представляют собой последовательность слов, разделенных пробелами, завершающуюся одним из операторов управления (2. Определения). Первое слово обычно задает команду для выполнения, а последующие служат аргументами команды.

Статус возврата (3.7.5. Статус выхода) для простой команды является статусом выхода, возвращенным функцией POSIX 1003.1 waitpid, или 128+n, если команда была прервана сигналом n.

3.2.2. Конвейеры

Конвейер — это одна или несколько команд, разделенных оператором | или |&. Формат конвейера имеет вид

[time [-p]] [!] command1 [ | or |& command2 ] ...

Вывод каждой команды в конвейере соединяется через канал (pipe) со входом следующей команды, т. е. каждая команда читает результат предыдущей команды. Соединение организуется до перенаправлений, заданных командой.

При использовании оператора |& стандартный вывод ошибок command1 вместе со стандартным выводом соединяется со стандартным вводом command2 через канал. Это сокращенно задается в форме 2>&1 |. Неявное перенаправление стандартного вывода ошибок на стандартный вывод выполняется после перенаправлений, заданных командой.

Зарезервированное слово time активизирует вывод статистики для конвейера по завершении. Статистика включает прошедшее время, а также время выполнения команды в пользовательском и системном пространстве. Опция -p устанавливает формат вывода POSIX. При работе оболочки в режиме POSIX (6.11. Режим POSIX) слово time не считается зарезервированным, если за ним следует маркер, начинающийся с символа -. В переменной TIMEFORMAT может быть задана строка, управляющая выводом значений времени (5.2. Переменные Bash). Использование time в качестве зарезервированного слова разрешено во внутренних функциях, функциях оболочки и конвейерах.

При работе оболочки в режиме POSIX (6.11. Режим POSIX) слово time следовать за newline. В этом случае оболочка выводит время в пользовательском и системном пространстве, затраченное оболочкой и ее потомками. Для задания формата вывода времени может применяться переменная TIMEFORMAT.

Если конвейер не выполняется асинхронно (3.2.3. Списки ), оболочка ждет завершения всех команд конвейера.

Каждая команд конвейера выполняется в своей субоболочке, которая является отдельным процессом (3.7.3. Среда выполнения команды). Если включена опция lastpipe при использовании внутренней команды shopt (4.3.2. Внутренняя команда shopt), последний элемент конвейера может запускаться процессом оболочки.

Статусом выход из конвейера служит статус завершения последней команды, пока не включена опция pipefail (4.3.1. Внутренняя команда set). При включенной опции pipefail статусом завершения конвейера будет последний отличный от нуля код завершения команды, или 0, если все команды конвейера завершились успешно. Если перед конвейером указан символ !, статусом завершения будет логическое обращение описанного выше статуса. Оболочка ждет завершения всех команд конвейера перед возвратом значения.

3.2.3. Списки

Список включает один или несколько конвейеров, разделенных операторами ;, &, && или ||, которые могут завершаться символом ;, &, или newline. Операторы списка && и || имеют одинаковый приоритет, за ними следуют ; и &, также имеющие одинаковый приоритет. В списке может присутствовать один или несколько символов newline для разделения команд (эквивалент ;).

Если команда завершается оператором управления &, она выполняется асинхронно в субоболочке. Это называется выполнением команды в фоновом режиме (background), а здесь такие команды называются асинхронными. Оболочка не ждет завершения команды и возвращает статус 0 (true). При активном управлении заданиями (7. Управление заданиями) стандартным вводом асинхронных команд при отсутствии явного перенаправления служит /dev/null.

Команды, разделенные символом ;, выполняются последовательно и оболочка дожидается выполнения каждой команды по очереди. Статусом возврата служит код завершения последней выполненной команды. Списки && и || являются последовательностями из одного или нескольких конвейеров, разделенных символами && или || и выполняемых слева направо.

В списке

command1 && command2

command2 выполняется тогда и только тогда, когда команда command1 вернула статус 0 (успех). А в списке

command1 || command2

command2 выполняется тогда и только тогда, когда команда command1 вернула отличный от 0 статус. Статусом возврата этих списков является статус выхода последней выполненной команды.

3.2.4. Составные команды

Составные команды являются конструкциями языка программирования оболочки. Каждая конструкция начинается зарезервированным словом или оператором и заканчивается соответствующим зарезервированным словом или оператором. Все перенаправления (3.6. Перенаправление) связанные с составной командой, применяются к каждой команде внутри конструкции, если явно не задано иное.

В большинстве случаев список команд в описании составной команды может быть отделен от остальной команды одним или несколькими символами новой строки и может сопровождаться в конце символом newline вместо ;.

Bash поддерживает конструкции с циклами, условиями и группировкой для выполнения команд как единого блока.

3.2.4.1. Конструкции с циклами

Ниже описаны конструкции с циклами, поддерживаемые bash. Отметим, что символ ; в циклах можно заменить одним или несколькими символами новой строки.

until

Синтаксис цикла until имеет вид

until test-commands; do consequent-commands; done

Выполнение consequent-commands продолжается до тех пор, пока test-commands не возвратит отличный от 0 статус выхода. Статусом выхода из цикла является статус выхода последней выполненной команды из consequent-commands или 0, если ничего не выполнялось.

while

Синтаксис цикла while имеет вид

while test-commands; do consequent-commands; done

Выполнение consequent-commands продолжается до тех пор, пока test-commands не возвратит статус выхода 0. Статусом выхода из цикла является статус выхода последней выполненной команды из consequent-commands или 0, если ничего не выполнялось.

for

Синтаксис цикла for имеет вид

for name [ [in [words ...] ] ; ] do commands; done

Происходит преобразование words (3.5. Преобразования) и выполняются команды один раз для каждого элемента в полученном списке с именем, привязанным к текущему элементу. При отсутствии in words цикл for выполняет команды один раз для каждого позиционного параметра, который установлен, как при указании in «$@» (3.4.2. Специальные параметры). Статусом возврата цикла является статус выхода последней выполненной команды. Если нет элементов при преобразовании words, никакие команды не выполняются и возвращается статус 0.

Поддерживается также другая форма цикла for в виде

for (( expr1 ; expr2 ; expr3 )) ; do commands ; done

Сначала вычисляется арифметическое выражение expr1 в соответствии с правилами, описанными ниже (6.5. Арифметика командного процессора). Затем в цикле вычисляется арифметическое выражение expr2, пока оно не даст результат 0 и в каждом цикле с отличным от 0 значением выполняются команды commands и вычисляется арифметическое выражение expr3. Если любое из выражений опущено, оно считается имеющим значение 1. Статусом возврата служит статус выхода последней выполненной команды или false, если какое-либо из выражений недействительно.

Внутренние операторы break и continue (4.1. Внутренние элементы Bourne Shell) могут служить для управления циклом.

3.2.4.2. Конструкции с условием

if

Синтаксис конструкции if показан ниже.

if test-commands; then
	consequent-commands;
[elif more-test-commands; then
	more-consequents;]
[else alternate-consequents;]
fi

Выполняется список test-commands и, если он возвращает 0, выполняется список consequent-commands. Если test-commands возвращает ненулевой статус, выполняется список elif и при нулевом статусе возврата выполняется список more-consequents. При наличии else alternate-consequents и ненулевом статусе возврата в финальном операторе if или elif, выполняется список команд alternate-consequents. Статусом возврата будет статус выхода последней выполненной команды или 0, если ни одно из условий не было выполнено.

case

Синтаксис конструкции case показан ниже.

case word in
	[ [(] pattern [| pattern]...) command-list ;;]...
esac

В конструкции case будет селективно выполняться список command-list, соответствующий первому совпадению. Сопоставление выполняется в соответствии с правилами параграфа 3.5.8.1. Сопоставление с шаблоном. Если включена опция nocasematch (4.3.2. Внутренняя команда shopt), при сопоставлении регистр символов не принимается во внимание. Символ | служит для разделения шаблонов сопоставления, а ) завершает список шаблонов, который вместе со связанным command-list называют clause (условие).

Каждое условие должно завершаться последовательностью ;;, ;& или ;;&. Для word до сравнения выполняется преобразование тильды и параметров, подстановка команд, арифметическое преобразование и удаление кавычек (3.5.3. Преобразование параметров оболочки). Для каждого шаблона pattern выполняется преобразование тильды и параметров, подстановка команд и арифметическое преобразование

В конструкции может использоваться произвольной число условий (clause), каждое из которых завершается последовательностью ;;, ;& или ;;&. Первый соответствующий шаблон pattern определяет выполняемый список command-list. Часто в качестве последнего варианта применяется шаблон *, которому соответствует все.

Ниже приведен пример использования case в сценарии для описания одной интересной особенности животных.

echo -n "Enter the name of an animal: "
read ANIMAL
echo -n "The $ANIMAL has "
case $ANIMAL in
	horse | dog | cat) echo -n "four";;
	man | kangaroo ) echo -n "two";;
	*) echo -n "an unknown number of";;
esac
echo " legs."

При использовании в конце условия оператора ;; после первого совпадения дополнительных сопоставлений не проводится. При использовании ;& вместо ;; продолжается выполнение списка command-list, связанного со следующим условием. Использование ;;& вместо ;; заставляет оболочку проверять шаблоны следующего условия и выполнять связанный с ним список command-list при совпадении.

Если ни один шаблон не подошел, возвращается статус 0, в остальных случаях возвращается статус выхода последнего command-list.

select

С помощью конструкции select легко создавать меню. Синтаксис конструкции похож на синтаксис for.

select name [in words ...]; do commands; done

Список words после in преобразуется, создавая список элементов. Набор преобразованных слов выводится в стандартный выходной поток ошибок с указанием номера каждого слова. При отсутствии in words выводятся позиционные параметры, как будто указано in «$@». Затем выводится приглашение PS3 и считывается строка со стандартного ввода. Если эта строка содержит число, соответствующее одному из выведенных слов, для переменной name устанавливается значение этого слова. Если строка пуста, слова и приглашения выводятся вновь. Если прочитан символ EOF, выполнение select завершается. При всех прочих значениях ввода для name устанавливается пустое значение. Считанная строка сохраняется в переменной REPLY.

Команды commands выполняются после каждого выбора, пока не будет выполнена команда break, после чего работа select завершается.

Ниже приведен пример, позволяющий выбрать имя файла в текущем каталоге и вывести имя и индекс файла.

select fname in *;
do
echo you picked $fname \($REPLY\)
break;
done

((…))

(( expression ))

Арифметическое выражение, вычисляемое в соответствии с правилами параграфа 6.5. Арифметика командного процессора. Если значение отлично от нуля, возвращается статус 0, в противном случае — 1. Это полный эквивалент выражения let «expression» (см. раздел 4.2. Внутренние команды bash).

[[…]]

[[ expression ]]

Возвращает 0 или 1 в зависимости от вычисления условного выражения expression. Выражения состоят из примитивов, описанных в разделе 6.4. Условные выражения bash. Расщепление слов и преобразование имен файлов не выполняется между скобками [[ ]], но выполняется преобразование тильды, параметров и переменных, преобразование арифметических выражений, подстановка команд и процессов, а также удаление кавычек. Условные операторы, такие как -f должны указываться без кавычек.

При использовании с [[ операторы < и > сортируются лексикографически в соответствии с языковыми настройками.

При использовании операторов == и != строка справа от оператора считается шаблоном и сопоставление выполняется по правилам, описанным в параграфе 3.5.8.1. Сопоставление с шаблоном, как при включенной опции extglob. Оператор = идентичен ==. При включенной опции nocasematch (4.3.2. Внутренняя команда shopt) сопоставление выполняется без учета регистра символов. Возвращается значение 0 при соответствии строк для == и несоответствии для !=, в остальных случаях возвращается значение 1. Любая часть шаблона может быть заключена в кавычки для ее сопоставления как строки.

При доступности дополнительного бинарного оператора =~ он имеет такой же порядок применения как == и !=. При его использовании строка справа считается регулярным выражением POSIX и сопоставляется соответствующим образом (как в regex 3). Возвращается 0 при соответствии строки шаблону и 1 в противном случае. Если регулярное выражение синтаксически некорректно, условное выражение возвращает 2. При включенной опции nocasematch (4.3.2. Внутренняя команда shopt) сопоставление выполняется без учета регистра символов. Любая часть шаблона может быть заключена в кавычки для ее сопоставления как строки. Заключенные в скобки части регулярных выражений должны обрабатываться осторожно, поскольку обычные символы кавычек утрачивают свой смысл между скобками. Если шаблон хранится в переменной оболочки, преобразование переменной в кавычках ведет к сопоставлению всего шаблона как строки. Подстроки, соответствующие заключенным в скобки субвыражениям в регулярном выражении сохраняются в массиве переменной BASH_REMATCH. Элемент BASH_REMATCH с индексом 0 является частью строки, соответствующей всему регулярному выражению. Элемент с индексом n является частью строки, соответствующей n-му субвыражению в скобках.

Например, приведенное ниже выражение будет соответствовать строке line (сохраненной в переменной оболочки line), если в значении есть последовательность символов, содержащая любое число (включая 0) пробелов или экземпляров символа a, за которым следует b.

[[ $line =~ [[:space:]]*?(a)b ]]

В результате такие значения, как ‘aab’ и ‘ aaaaaab’ дадут совпадение, как и строки, содержащие лишь символ b.

Сохранение регулярного выражения в переменной оболочки зачастую полезно для предотвращения проблем с кавычками для символов, имеющих в оболочке особое значение. Иногда сложно задать регулярное выражение буквально без использования кавычек или сохранить след применения кавычек регулярным выражением с учетом удаления кавычек оболочкой. Использование переменной для сохранения шаблона снижает вероятность таких проблем. Ниже приведен аналог предыдущего примера с использованием такой переменной.

pattern=’[[:space:]]*?(a)b’
[[ $line =~ $pattern ]]

Если нужно сопоставление с символом, имеющим особое значение в регулярных выражениях, шаблон следует поместить в кавычки. Например в шаблоне xxx.txt точка (.) соответствует любому символу в строке (обычная трактовка в регулярном выражении), а шаблон «xxx.txt» будет требовать точного совпадения. Программистам следует внимательно относиться к символам \, поскольку в оболочке и регулярных выражениях они задают специальную трактовку следующего символа. Например,

pattern=’\.’
[[ . =~ $pattern ]]
[[ . =~ \. ]]
[[ . =~ "$pattern" ]]
[[ . =~ ’\.’ ]]

Первые два сопоставления дадут совпадение, остальные — нет, поскольку в них символ \ является частью шаблона (кавычки). В двух первых примерах символ \ отменяет специальную трактовку точки, поэтому символ точки будет давать совпадение. Если бы строка в двух первых примерах отличалась от ‘.’ (например, ‘a’), совпадения бы не было, поскольку специальная трактовка точки отменена символом \.

Выражения можно комбинировать с помощью приведенных ниже операторов, указанных в порядке применения.

( expression )

Возвращает значение expression и может применяться для изменения порядка применения операторов.

! expression

Возвращает true, если expression имеет значение false.

expression1 && expression2

Возвращает true, если expression1 и expression2 имеют значение true.

expression1 || expression2

Возвращает true, expression1 или expression2 имеет значение true.

С операторами && и || выражение expression2 не будет вычисляться, если expression1 уже определяет результат.

3.2.4.3 Команды группировки

Bash обеспечивает два способа группировки команд с целью выполнения единым блоком. При группировке команд перенаправление может применяться ко всему набору команд. Например, вывод команд может перенаправляться в один поток.

()

( list )

Указание списка команд в круглых скобках вызывает создание среды субоболочки (3.7.3. Среда выполнения команды) и выполнение каждой команды из списка. Выполнение команд в субоболочке ведет к тому, что назначения переменных, выполненные командами, не сохраняются по завершении работы.

{}

{ list; }

Указание списка команд в фигурных скобках вызывает выполнение этих команд в контексте текущей оболочки без создания субоболочек. Список должен завершаться символом ; или newline.

Кроме создания субоболочки эти варианты имеют различие, обусловленное историческими причинами. Символы фигурных скобок являются зарезервированными, поэтому между скобками и списком команд должен присутствовать пробел или другой метасимвол. Круглые скобки являются оператором и воспринимаются как отдельные маркеры даже при отсутствии пробелов между ними и списком. Для обоих вариантов статусом завершения является статус выхода списка команд.

3.2.5. Копроцессы

Копроцесс (coprocess) — это команда оболочки, которой предшествует зарезервированное слово coproc. Копроцесс выполняется асинхронно в субоболочке, как будто команда содержала в конце управляющий оператор &, с двунаправленным каналом между оболочкой и копроцессом. Формат запуска копроцесса показан ниже.

coproc [NAME] command [redirections]

Эта команда создает копроцесс с именем NAME. Если параметр NAME не задан, применяется имя COPROC. Параметр NAME недопустимо применять с простой командой command (3.2.1. Простые команды), поскольку он будет считаться первым словом простой команды.

При выполнении копроцесса оболочка создает переменную массива (6.7. Массивы) с именем NAME в контексте выполняемой оболочки. Стандартный вывод команды соединяется через канал с дескриптором файла в исполняющей оболочке и этот дескриптор назначается переменной NAME[0]. Стандартный ввод команды соединен каналом с дескриптором файла в исполняющей оболочке и этот дескриптор назначен переменной NAME[1]. Этот канал организуется до перенаправлений, заданных командой (3.6. Перенаправление). Дескрипторы файлов могут служить аргументами команд оболочки и перенаправлений с использованием стандартного преобразования слов. Кроме дескрипторов, созданных специально для выполнения подстановок команд и процессов, в субоболочке нет доступных дескрипторов файлов.

Идентификатор процесса вызванной для выполнения копроцесса оболочки доступен как значение переменной NAME_PID. Можно использовать внутреннюю команду wait для ожидания завершения копроцесса.

Поскольку копроцесс создается как асинхронная команда, coproc всегда возвращает успешный результат. Статусом возврата копроцесса является статус выхода команды command.

3.2.6. GNU Parallel

Имеются способы параллельного выполнения команд, не встроенные в Bash и одним из них является GNU Parallel. Как ясно из имени, GNU Parallel может использоваться для сборки и запуска команд в параллель. Можно запустить одну команду с разными аргументами, будь то имена файлов, пользователей и хостов или строки, прочитанные из файлов. GNU Parallel обеспечивает сокращения для большинства базовых операций (строки ввода и их части, способы задания источника ввода и т. п.). Parallel может заменять команды xargs или feed из различных входов в нескольких разных экземплярах Bash. Полное описание пакета можно найти в документации GNU Parallel, а ниже приведено несколько кратких примеров использования.

Легко заменить xargs для упаковки gzip всех файлов html в текущем каталоге и его подкаталогах, как показано ниже.

find . -type f -name ’*.html’ -print | parallel gzip

Если нужно «защитить» в именах специальные символы, такие как newline, можно использовать опцию find -print0 и опцию parallel -0.

Можно применить Parallel для переноса файлов из текущего каталога, когда число файлов слишком велико для обработки командой mv.

ls | parallel mv {} destdir

В этом случае {} заменяется каждой строкой со стандартного ввода. Хотя команда ls будет работать в большинстве случаев, ее недостаточно для работы со всеми возможными именами. Если нужно обрабатывать файлы со специальными символами в именах, можно применить команду вида

find . -depth 1 \! -name ’.*’ -print0 | parallel -0 mv {} destdir

Эта команда запустит столько команд mv, сколько имеется файлов в текущем каталоге. Можно эмулировать параллельное использование xargs с помощью опции -X, как показано ниже.

find . -depth 1 \! -name ’.*’ -print0 | parallel -0 -X mv {} destdir

GNU Parallel может заменить некоторые распространенные выражения для работы со строками, считываемыми из файла. В приведенном ниже примере это имена файлов, указанные по одному в строке. Обычный вариант имеет вид

while IFS= read -r x; do
do-something1 "$x" "config-$x"
do-something2 < "$x"
done < file | process-output

Но это можно выразить более компактно в форме

cat list | parallel "do-something1 {} config-{} ; do-something2 < {}" |
           process-output

Parallel обеспечивает встроенный механизм удаления расширений в именах файлов, пригодный для массового преобразования или переименования файлов. Например,

ls *.gz | parallel -j+0 "zcat {} | bzip2 >{.}.bz2 && rm {}"

Эта команда будет распаковывать все файлы в текущем каталоге, имеющие расширение .gz, используя программу bzip2 с запуском одного задания на процессор (-j+0) в параллель. В примере для краткости использована команда ls, но можно использовать find для обработки файлов со специальными символами в именах. Parallel может принимать аргументы из командной строки и предыдущий пример можно выразить в форме

parallel "zcat {} | bzip2 >{.}.bz2 && rm {}" ::: *.gz

Если команда создает вывод, может оказаться желанным связать порядок ввода с порядком вывода. Например,

{
	echo foss.org.my ;
	echo debian.org ;
	echo freenetproject.org ;
} | parallel traceroute

будет выводить сначала результат traceroute для закончившейся первой трассировки. Если добавить опцию -k

{
	echo foss.org.my ;
	echo debian.org ;
	echo freenetproject.org ;
} | parallel -k traceroute

первым будет выведен результат трассировки foss.org.my.

Кроме того, parallel можно применять для запуска последовательности команд оболочки в параллель, подобно cat file | bash. Нет ничего необычного в том, чтобы взять список имен файлов, создать серию команд для работы с ними и передать этот список команд в оболочку. Parallel позволяет ускорить обработку. В предположении, что file содержит нужный список команд (по одной в строке) это может иметь вид

parallel -j 10 < file

Команды будут выполняться параллельно после их преобразования (поскольку команды не заданы явно) блоками по 10 одновременных заданий.

3.3. Функции оболочки

Shell-функции обеспечивают способ группировки команд для последующего выполнения с использованием одного имени для группы. Функции выполняются подобно «обычным» командам. Когда имя функции применяется как имя простой команды, выполняется список команд, связанных с именем функции. Shell-функции выполняются в контексте текущей оболочки без создания нового процесса.

Синтаксис объявления функции имеет форму

name () compound-command [ redirections ]

или

function name [()] compound-command [ redirections ]

Это определяет функцию с именем name. Зарезервированное слово function является необязательным, а при его указании круглые скобки становятся необязательными. Тело функции составляет набор команд compound-command (3.2.4. Составные команды). Обычно составная команда представляет собой список команд заключенный в фигурные скобки { }, но это может быть любая составная команда с одним исключением — при использовании зарезервированного слова function без круглых скобок фигурные скобки являются обязательными. В режиме POSIX (6.11. Режим POSIX), имя name не может совпадать с именем какой-либо из специальных внутренних функций (4.4. Специальные внутренние команды). Все перенаправления (3.6. Перенаправление), связанные с функцией, применяются при выполнении функции.

Определение функции можно удалить с помощью опции -f внутренней функции unset (4.1. Внутренние элементы Bourne Shell).

Статус выхода при определении функции имеет значение 0, если не возникло синтаксической ошибки и нет уже функции с таким именем, доступной лишь для чтения. При выполнении функции статус определяется статусом выхода последней выполненной в теле функции команды.

Отметим, что в силу исторических причин фигурные скобки вокруг тела функции в большинстве случаев отделены от тела пробелом или символом новой строки. Это связано с тем, что фигурные скобки являются зарезервированными словами и для распознания в таком качестве должны быть отделены пробелом или иным метасимволом. Кроме того, при использовании фигурных скобок список команд должна завершаться символом ;, & или newline.

При выполнении функции ее аргументы становятся позиционными параметрами (3.4.1. Позиционные параметры). Специальный параметр #, который преобразуется в число позиционных параметров, обновляется с учетом изменений. Специальный параметр 0 не меняется. Первому элементу переменной FUNCNAME присваивается имя функции при ее выполнении.

Все остальные аспекты среды выполнения оболочки идентичны для функции и вызвавшего ее процесса, за исключением того, что прерывания DEBUG и RETURN не наследуются, если для функции не задан атрибут трассировки trace с помощью внутренней функции declare или опции -o внутренней функции set, а прерывание ERR не наследуется, пока не задана опция -o errtrace. Внутренняя функция trap описана в разделе 4.1. Внутренние элементы Bourne Shell.

При установке в переменной FUNCNEST численного значения больше 0 она определяет максимальный уровень вложенности функций. Превышение этого уровня ведет к прерыванию команды.

Если в функции выполняется внутренняя команда return, работа функции завершается и выполняется команда, следующая за вызовом функции. Любые команды, связанные с прерыванием RETURN выполняются перед возвратом управления. Когда функция завершается, позиционные параметры и специальный параметр # восстанавливают значения, которые были перед вызовом функции. Если функции return передано числовое значение, оно будет служить статусом возврата. В остальных случаях функция возвращает статус выхода последней выполненной команды.

Локальные переменные функции можно объявить с помощью встроенного оператора local. Эти переменные будут видны только функции и вызываемым ею командам.

Локальные переменные «затеняют» одноименные переменные, объявленные до вызова функции (вне ее). Например, локальная переменная, определенная внутри функции, будет скрывать одноименную глобальную переменную. Ссылки и назначения будут относиться к локальной переменной, не затрагивая глобальную. При возврате из функции глобальная переменная вновь станет видимой.

Оболочка применяет динамическую область действия для управления видимостью переменных и их значения являются результатом последовательности вызовов функций, которые приведи к текущей функции. Значение переменной, которое видит функция, зависит от ее значения у вызывающей стороны. Например, если переменная var объявлена как локальная в func1 и func1 вызывает другую функцию func2, ссылки на var внутри func2 будет относиться к локальной переменной var из func1, затеняя любую глобальную переменную var, если она имеется. Например,

In func2, var = func1 local
func1()
{
	local var=’func1 local’
	func2
}
func2()
{
	echo "In func2, var = $var"
}
var=global
func1

Внутренняя функция unset также имеет динамическую область действия. Если переменная определена локально, unset будет сбрасывать ее, а в противном случае искать эту переменную ы вызывающей области. Если переменная в локальной области действия сброшена, это будет сохраняться до ее установки в этой области или возврата из функции. После возврата из функции все экземпляры переменных вызвавшей функцию области становятся доступными. Если команда unset была применена к переменной вызывающей области, становится доступным экземпляр, затененный этой переменной (если он есть).

Имена функций и определения могут быть перечислены с помощью опции -f внутренней команды declare (typeset) (4.2. Внутренние команды bash). Опция -F в команде declare или typeset будет выводить только имена функций (может также выводить имя файла и номер строки, если включена опция extdebug). Функции можно экспортировать, чтобы субоболочки автоматически получали их определения при указании опции -f в команде export (4.1. Внутренние элементы Bourne Shell).

Функции могут быть рекурсивными, для ограничения уровня рекурсии может применяться переменная FUNCNEST. По умолчанию глубина рекурсии не ограничена.

3.4. Параметры оболочки

Параметр — это элемент, сохраняющий значения. Параметр может быть именем, номером или одним из специальных символов, указанных ниже. Переменные являются именованными параметрами. Переменная имеет значение и может иметь атрибуты, присваиваемые с помощью внутренней команды declare (4.2. Внутренние команды bash).

Параметр установлен, если ему присвоено значение (включая null). Установленная переменная может быть сброшена внутренней командой unset и установлена выражением вида

name=[value]

Если аргумент value не задан, переменной назначается пустая строка (null). Все значения подвергаются преобразованию тильды, параметров и переменных, подстановке команд, арифметическим преобразованиям и удалению кавычек. Если переменная имеет атрибут integer, ее значение определяется арифметическим преобразованием (3.5.5. Арифметическое преобразование) даже при отсутствии выражения $((…)). Расщепление слов не применяется, за исключением описанного ниже случая $@, преобразование имен файлов также не выполняется. Операторы назначения могут присутствовать как аргументы внутренних команд alias, declare, typeset, export, readonly и local. В режиме POSIX (6.11. Режим POSIX) эти встроенные переменные могут присутствовать в команде после одного или нескольких экземпляров внутренней команды command и сохранять свойства операторов присваивания.

В контексте, где оператор присваивание задает значение переменной оболочки или индексу массива (6.7. Массивы), оператор += может служить для добавления в конец или сложения с прежним значением переменной. Это включает аргументы внутренних команд, таких как declare, которые принимают операторы присваивания. При использовании += с переменной, для которой установлен атрибут integer, значение вычисляется путем арифметического преобразования и складывается с текущим значением, которое тоже преобразуется. Когда += применяется к переменной массива с помощью композитного присваивания (6.7. Массивы), переменная не сбрасывается, как при использовании = и новое значение добавляется в конец массива с индексом на 1 больше текущего максимального индекса (массив с индексом) или добавляется новая пара ключ-значение в ассоциативный массив. Для строковой переменной этот оператор просто добавляет строку в конец имеющейся.

Переменной может быть назначен атрибут nameref с помощью опции -n внутренней команды declare или local (4.2. Внутренние команды bash) для создания nameref или ссылки на иную переменную. Это позволяет манипулировать переменными опосредованно. Всякий раз, когда переменная nameref указывается, назначается, отменяется или изменяются ее атрибуты (иные, нежели nameref), реальная операция выполняется над переменной, заданной значением nameref. Обычно nameref применяется в функциях оболочки для ссылки на переменную, имя которой передается как аргумент функции. Например, если имя переменной передается shell-функции как первый аргумент, выполнение declare -n ref=$1 внутри функции создает nameref-переменную ref, значением которой является имя переменной, переданное первым аргументом. Ссылки и назначение переменной ref, а также изменение ее атрибутов будут трактоваться как ссылки, назначение и изменение атрибутов переменной, имя которой передано как $1.

Если переменная управления циклом for имеет атрибут nameref, список слов может содержать переменные оболочки и ссылка на имя будет создаваться для каждого слова списка при выполнении цикла. Для переменных-массивов атрибут nameref не поддерживается, однако переменные nameref могут указывать переменные массива и индексы. Nameref можно отменить с помощью опции -n внутренней команды (4.1. Внутренние элементы Bourne Shell). Если же unset выполняется с именем переменной nameref в качестве аргумента, сброшена будет переменная, указанная nameref.

3.4.1. Позиционные параметры

Позиционные параметры обозначаются одной или несколькими цифрами, обозначение 0 не используется. Позиционные параметры присваиваются из значений аргументов оболочки при вызове и могут переназначаться с помощью внутренней команды set. Параметр N можно указывать как ${N} или $N (если N содержит одну цифру). Позиционные параметры не могут назначаться операторами присваивания. Для установки и сброса позиционных параметров используются внутренние команды set и unset (4. Внутренние команды оболочки). Позиционные параметры временно заменяются при выполнении shell-функций (3.3. Функции оболочки).

Если номер позиционного параметра содержит более одной цифры, параметр должен заключаться в фигурные скобки.

3.4.2. Специальные параметры

Некоторые параметры оболочки имеют особое значение и их можно лишь указывать без возможности назначения.

*

($*)

Преобразуется в позиционные параметры начиная с первого. Если преобразуемый параметр не заключен в двойные кавычки, каждый позиционный параметр становится отдельным словом. В контексте преобразования эти слова подвергаются расщеплению и преобразованию путей. Если преобразуемый параметр заключен в двойные кавычки, он преобразуется в одно слово, где значения параметров разделены первым символом специальной переменной IFS. Таким образом, «$*» преобразуется в «$1c$2c…», где c — первый символ значения переменной IFS. Если IFS не задана, разделителем служит пробел, а при IFS = null параметры не разделяются.

@

($@)

Преобразуется в позиционные параметры начиная с первого. В контексте, где выполняется расщепление слов, каждый позиционный параметр преобразуется в отдельное слово, которое при отсутствии двойных кавычек подвергается расщеплению слов. В контексте без расщепления слов параметр преобразуется в одно слово с разделением позиционных параметров пробелами. Параметр, заключенный в двойные кавычки, преобразуется с расщеплением слов и выделением каждого параметра в отдельное слово. Таким образом, «$@» является эквивалентом «$1» «$2» … Если раскрытие двойных кавычек выполняется внутри слова преобразованное первое слово объединяется с начальной частью исходного слова, а преобразование последнего — с последней частью исходного слова. При отсутствии позиционных параметров преобразования «$@» и $@ не происходит (т. е. параметр удаляется).

#

($#)

Преобразуется в число позиционных параметров в десятичное значение.

?

($?)

Преобразуется в статус выполненного последним не фонового (foreground) конвейера.

($-)

Преобразуется в текущие флаги опций, заданные при вызове внутренней командой set или установленные самой оболочкой (например, опция -i).

$

($$)

Преобразуется в идентификатор процесса оболочки. В субоболочке () указывается идентификатор процесса вызвавшей оболочки, а не субоболочки.

!

($!)

Преобразуется в идентификатор процесса для задания, помещенного последним в фоновый режим и выполняемого как асинхронная команда или с помощью внутренней команды bg (7.2. Внутренние средства управления заданиями).

0

($0)

Преобразуется в имя оболочки или сценария оболочки. Значение устанавливается при инициализации оболочки. Если Bash вызывается с файлом команд (3.8. Сценарии оболочки), в $0 задается имя этого файла. При запуске Bash с опцией -c (6.1. Вызов Bash), в $0 помещается первый аргумент после выполняемой строки, если он имеется. В остальных случаях параметр получает имя файла, использованного для вызова Bash, указанное аргументом 0.

_

($_)

При запуске оболочки для параметра устанавливается абсолютный путь, заданный при вызове оболочки или сценария и переданный в окружении или списке аргументов. Затем параметр преобразуется в последний предыдущей простой команды, выполняемой в режиме foreground, после преобразования. Устанавливается также полный путь, используемый для вызова каждой выполняемой команды, и помещается в окружение экспортируемое этой команде. При проверке почты в этом параметре содержится имя почтового файла.

3.5. Преобразования

Преобразование командной строки выполняется после ее разбиения на маркеры (компоненты). Имеется несколько типов преобразований, указанных в порядке их применения:

  1. преобразование скобок;

  2. преобразование тильды;

  3. преобразование параметров и переменных;

  4. арифметическое преобразование и подстановка команд (слева направо);

  5. расщепление слов;

  6. преобразование имен файлов.

На системах, которые это поддерживают, возможна также подстановка процессов. Она выполняется одновременно с преобразованием тильды, параметров, переменных, арифметическими преобразованиями и подстановкой команд.

Преобразование скобок, расщепление слов и имен файлов могут увеличивать число слов, а в остальных преобразованиях число слов сохраняется. Единственным исключением является преобразование «$@» и $* (3.4.2. Специальные параметры), а также «${name[@]}» и ${name[*]} (6.7. Массивы).

По завершении этих преобразований выполняется удаление кавычек (3.5.9. Удаление кавычек), если сами они на находятся в других кавычках.

3.5.1. Раскрытие скобок

Раскрытие скобок может генерировать произвольные строки символов. Этот механизм похож на преобразование имен файлов (3.5.8. Преобразование имен файлов), но создаваемые имена могут не существовать. Преобразуемая структура может включать преамбулу, за которой следует цепочка разделенных запятыми строк или выражение между парой скобок, затем может следовать дополнение (постскриптум). Преамбула добавляется перед каждой строкой, содержащейся внутри скобок, а постскриптум добавляется в конец ее. Преобразование выполняется слева направо.

Выражения в скобках могут быть вложенными. Полученные в результате преобразования строки не сортируются. Например,

bash$ echo a{d,c,b}e
ade ace abe

Последовательность имеет форму {x..y[..incr]}, где x и y — целые числа и одиночные символы, а необязательный инкремент incr — целое число. При указании целых числе выражение преобразуется в числа всего диапазона x — y, включая эти значения. Представленные значения целых чисел могут использовать префикс 0 для выравнивания числа цифр каждого элемента. Если x или y начинается с 0, оболочка пытается генерировать элементы с одинаковым числом цифр, добавляя при необходимости 0. При указании символов выражение преобразуется в последовательность символов, лексикографически входящих в диапазон x — y (включительно) в соответствии с принятой по умолчанию языковой настройкой C (locale). Отметим, что оба значения x и y должны быть одного типа. При указании инкремента он задает разницу (интервал) между элементами. По умолчанию используется инкремент 1 или -1 (что подходит).

Раскрытие скобок выполняется до всех других преобразований и поэтому все символы, имеющие особое значение в других преобразованиях, сохраняются. Преобразование является строго текстовым и Bash не пытается синтаксически интерпретировать содержимое выражения или текста между скобками.

Для корректного раскрытия скобок выражение должно содержать открывающую и закрывающую скобку без кавычек, а также хотя бы одну запятую без кавычек или корректное выражение последовательности. Некорректное выражение в скобках остается не преобразованным. Символу { или , может предшествовать экранирующий символ \. Для предотвращения конфликтов при преобразовании параметров строка ${ не считается допустимой при раскрытии скобок и блокирует преобразование до закрывающей скобки.

Приведенная ниже конструкция обычно применяется как сокращение в случаях, когда генерируемый общий префикс строки длиннее, чем в приведенном выше примере

mkdir /usr/local/src/bash/{old,new,dist,bugs}

или

chown root /usr/{ucb/{ex,edit},lib/{ex?.?*,how_ex}}

3.5.2. Преобразование тильды

Если слово начинается с символа ~ (тильда) без кавычек, все символы до первого символа / без кавычек (или просто все, если / без кавычек нет) считаются символами с тильда-префиксом. Если ни один из символов последовательности с тильдой не заключен в кавычки, символы после тильды трактуются как возможное имя пользователя (login name). Если это имя является пустой строкой, символ тильды заменяется значением переменной оболочки HOME. Если эта переменная не установлена, используется имя домашнего каталога пользователя, запустившего оболочку. В остальных случаях строка с тильда-префиксом заменяется домашним каталогом, связанным с указанным именем пользователя.

Если строка с префиксом имеет значение ~+, оно заменяется значением переменной оболочки PWD, а строка ~- заменяется значением переменной OLDPWD, если она задана.

Если после тильды следует число N (возможно с префиксом + или -), строка заменяется соответствующим элементом из стека каталогов, который будет выводится внутренней командой dirs при вызове с символами, следующими за тильдой (6.8. Стек каталогов). При отсутствии префикса между тильдой и числом предполагается префикс +.

Если имя пользователя (login) не действительно или преобразование тильды привело к отказу, строка остается прежней.

В каждом назначении переменной проверяется наличие тильда-префиксов без кавычек сразу за : или первым =. В таких случаях также выполняется преобразование тильды. Это позволяет применять имена файлов с тильдой в переменных PATH, MAILPATH, CDPATH и оболочка будет назначать преобразованные значения.

Ниже приведены трактовки в Bash тильда-префиксов без кавычек.

~

Значение переменной $HOME

~/foo

$HOME/foo

~fred/foo

Каталог foo в домашнем каталоге пользователя fred

~+/foo

$PWD/foo

~-/foo

${OLDPWD-’~-’}/foo

~N

Строка, которая будет выведена командой dirs +N

~+N

Строка, которая будет выведена командой dirs +N

~-N

Строка, которая будет выведена командой dirs -N

Bash также выполняет преобразование тильды в словах, удовлетворяющих условиям назначения переменных (3.4. Параметры оболочки), когда они указываются в качестве аргументов простых команд. Bash не делает этого, за исключением перечисленных выше команд объявления при работе в режиме POSIX.

3.5.3. Преобразование параметров оболочки

Символ $ вводит преобразование параметров, подстановку команд или арифметическое преобразование. Преобразуемое имя параметра или символ могут быть заключены в фигурные скобки, которые не обязательны, но позволяют отделить преобразуемую переменную от следующих непосредственно за ней символов, которые могут быть сочтены частью имени. При использовании скобок закрывающей скобкой служит первый символ }, не экранированный с помощью \, не заключенный в кавычки и не входящий во вложенное арифметическое преобразование, подстановку команд или преобразование параметров.

Базовая форма для преобразования параметров имеет вид ${parameter} и выполняется подстановка значения parameter, который является параметром оболочки (3.4. Параметры оболочки) или ссылкой на массив (6.7. Массивы). Скобки требуются для позиционных параметров с несколькими цифрами, а также параметров, за которыми следуют символы, не являющиеся частью имени.

Если первым символом параметра является !, а параметр не является nameref, это задает уровень косвенности (indirection). Bash использует значение, полученное преобразованием остальной части параметра, в качестве нового параметра. Затем этот параметр преобразуется и значение используется в дальнейшем преобразовании вместо преобразования исходного параметра. Для значения выполняется преобразование тильды и параметров, подстановка команд и арифметическое преобразование. Если параметр является nameref, он преобразуется в имя переменной, указанной параметром, вместо полного косвенного преобразования. Исключением являются преобразования ${!prefix*} и ${!name[@]}, описанные ниже. Для введения косвенности восклицательный знак должен быть указан сразу после левой скобки.

В каждом из описанных ниже случаев слово подвергается преобразованию тильды и параметров, подстановке команд и арифметическому преобразованию.

Когда не выполняется преобразование подстрок с использованием описанных ниже форм (например, ‘:-’), Bash проверяет параметры, которые не сброшены (unset) или имеют значение null. Пропуск двоеточия ведет к проверке лишь сброшенных (unset) параметров. Т. е. при наличии двоеточия оператор проверяет наличие параметра и его «непустоту» (not null), а без двоеточия проверяется лишь наличие параметра.

${parameter:−word}

Если parameter не установлен или имеет значение null, подставляется преобразование word. В остальных случаях подставляется значение parameter.

${parameter:=word}

Если parameter не установлен или имеет значение null, ему назначается преобразование word, после чего выполняется подстановка параметра. Такое назначение не применяется для позиционных и специальных параметров.

${parameter:?word}

Если parameter не установлен или имеет значение null, преобразование word (или об отсутствии word) записывается на стандартное устройство вывода ошибок и оболочка, если она не является интерактивной, завершает работу. В остальных случаях подставляется значение parameter.

${parameter:+word}

Если parameter не установлен или имеет значение null, не подставляется ничего. П остальных случаях подставляется преобразование word.

${parameter:offset}

${parameter:offset:length}

Это называется преобразованием подстроки (Substring Expansion). Преобразуется до length символов parameter, начиная с символа, заданного значением offset. Если parameter имеет значение @, для массива применяется индекс @, * или имя ассоциативного массива (результаты будут разными, как описано ниже). Если параметр length не задан, преобразуется подстрока значения parameter, начиная с offset и до конца значения. Параметры length и offset являются арифметическими выражениями (6.5. Арифметика командного процессора).

Если offset преобразуется в значение меньше 0, это значение используется для отсчета от конца значения parameter. Если length преобразуется в значение меньше 0, это значение считается смещением от конца значения parameter, а не числом символов и преобразование выполняется для символов между offset и result. Отметим, что отрицательное значение offset должно отделяться от двоеточия хотя бы одним пробелом, для предотвращения путаницы с преобразованием :-.

Ниже приведено несколько примеров, демонстрирующих преобразование подстрок для параметров и индексированных массивов.

$ string=01234567890abcdefgh
$ echo ${string:7}
7890abcdefgh
$ echo ${string:7:0}
$ echo ${string:7:2}
78
$ echo ${string:7:-2}
7890abcdef
$ echo ${string: -7}
bcdefgh
$ echo ${string: -7:0}
$ echo ${string: -7:2}
bc
$ echo ${string: -7:-2}
bcdef
$ set -- 01234567890abcdefgh
$ echo ${1:7}
7890abcdefgh
$ echo ${1:7:0}
$ echo ${1:7:2}
78
$ echo ${1:7:-2}
7890abcdef
$ echo ${1: -7}
bcdefgh
$ echo ${1: -7:0}
$ echo ${1: -7:2}
bc
$ echo ${1: -7:-2}
bcdef
$ array[0]=01234567890abcdefgh
$ echo ${array[0]:7}
7890abcdefgh
$ echo ${array[0]:7:0}
$ echo ${array[0]:7:2}
78
$ echo ${array[0]:7:-2}
7890abcdef
$ echo ${array[0]: -7}
bcdefgh
$ echo ${array[0]: -7:0}
$ echo ${array[0]: -7:2}
bc
$ echo ${array[0]: -7:-2}
bcdef

Если parameter имеет значение @, результатом будут length позиционных параметров, начиная с offset. Отрицательное значение offset задает отсчет от последнего позиционного параметра (-1). Если length преобразуется в отрицательное значение, это вызывает ошибку. Ниже приведены примеры преобразования подстрок с использованием позиционных параметров.

$ set -- 1 2 3 4 5 6 7 8 9 0 a b c d e f g h
$ echo ${@:7}
7 8 9 0 a b c d e f g h
$ echo ${@:7:0}
$ echo ${@:7:2}
7 8
$ echo ${@:7:-2}
bash: -2: substring expression < 0
$ echo ${@: -7:2}
b c
$ echo ${@:0}
./bash 1 2 3 4 5 6 7 8 9 0 a b c d e f g h
$ echo ${@:0:2}
./bash 1
$ echo ${@: -7:0}

Если parameter является индексированным массивом с индексом @ или *, результатом будет length элементов массива, начиная с ${parameter[offset]}. Отрицательное значение offset задает отсчет от максимального индекса указанного массива назад. Если length преобразуется в отрицательное значение, это вызывает ошибку. Ниже приведены примеры преобразования подстрок с индексированным массивом.

$ array=(0 1 2 3 4 5 6 7 8 9 0 a b c d e f g h)
$ echo ${array[@]:7}
7 8 9 0 a b c d e f g h
$ echo ${array[@]:7:2}
7 8
$ echo ${array[@]: -7:2}
b c
$ echo ${array[@]: -7:-2}
bash: -2: substring expression < 0
$ echo ${array[@]:0}
0 1 2 3 4 5 6 7 8 9 0 a b c d e f g h
$ echo ${array[@]:0:2}
0 1
$ echo ${array[@]: -7:0}

Преобразование подстрок в ассоциативных массивах дает неопределенный результат.

Индексирование подстрок начинается с 0, если не используются позиционные параметры, для которых отсчет по умолчанию начинается с 1. Если для позиционных параметров задано offset = 0, в начале списка выводится $@.

${!prefix*}

${!prefix@}

Преобразуются в имена переменных, начинающиеся с prefix, разделенные первым символом специальной переменной IFS. При использовании @ и наличии двойных кавычек имя каждой переменной преобразуется в отдельное слово.

${!name[@]}

${!name[*]}

Если name является переменной массива, преобразуется в список индексов (ключей), назначенных в name. Если name не является массивом, преобразуется в 0 при установленной переменной name и в null для остальных случаев. При использовании @ и наличии двойных кавычек каждый ключ преобразуется в отдельное слово.

${#parameter}

Подставляется число символов преобразованного значения parameter. Если parameter имеет значение * или @, подставляется число позиционных параметров. Если parameter является именем массива с индексом * или @, подставляется число элементов массива. Если parameter является именем массива с отрицательным индексом, отсчет начинается с конца массива (-1 указывает последний элемент).

${parameter#word}

${parameter##word}

Аргумент word преобразуется для создания шаблона и сопоставления по описанным ниже правилам (3.5.8.1. Сопоставление с шаблоном). Если шаблон соответствует началу преобразованного значения parameter, результатом преобразования будет преобразованное значение с удалением самого короткого (вариант #) или самого длинного (вариант ##) совпадения. Если parameter имеет значение * или @, операция удаления шаблона применяется к каждому позиционному параметру по очереди и результатом преобразования является полученный список. Если parameter является именем массива с индексом * или @, операция удаления шаблона применяется к каждому элементу массива поочередно и результатом преобразования является полученный список.

${parameter%word}

${parameter%%word}

Аргумент word преобразуется для создания шаблона и сопоставления по описанным ниже правилам (3.5.8.1. Сопоставление с шаблоном). Если шаблон соответствует концу преобразованного значения parameter, результатом преобразования будет преобразованное значение с удалением самого короткого (вариант 😉 или самого длинного (вариант %%) совпадения. Если parameter имеет значение * или @, операция удаления шаблона применяется к каждому позиционному параметру по очереди и результатом преобразования является полученный список. Если parameter является именем массива с индексом * или @, операция удаления шаблона применяется к каждому элементу массива поочередно и результатом преобразования является полученный список.

${parameter/pattern/string}

Аргумент pattern преобразуется для создания шаблона как при преобразовании имен, parameter преобразуется и наибольшее совпадение с шаблоном заменяется значением string. Сопоставление выполняется по правилам параграфа (3.5.8.1. Сопоставление с шаблоном). Если pattern начинается с /, все совпадения заменяются на string (обычно замена выполняется лишь для первого совпадения). Если pattern начинается с #, ему соответствует начало преобразованного значения parameter, если pattern начинается с %’, ему соответствует конец преобразованного значения parameter. Если string = null, совпадение с шаблоном удаляется и символ / после pattern может не указываться. При включенной опции оболочки nocasematch (4.3.2. Внутренняя команда shopt) сопоставление выполняется без учета регистра символов. Если parameter имеет значение * или @, подстановка выполняется поочередно для каждого позиционного параметра и результатом преобразования является полученный список. Если parameter является именем массива с индексом * или @, подстановка применяется к каждому элементу массива поочередно и результатом преобразования является полученный список.

${parameter^pattern}

${parameter^^pattern}

${parameter,pattern}

${parameter,,pattern}

Преобразование меняет регистр символов parameter. Аргумент pattern преобразуется для создания шаблона как в преобразовании имен файлов. Каждый символ преобразованного значения parameter сравнивается с шаблоном и при совпадении регистр символа меняется. Не следует сопоставлять шаблон с несколькими символами сразу. Оператор ^ задает преобразование нижнего регистра в верхний, а ‘,’ — обратное преобразование. Преобразования ^^ и ,, конвертируют каждый соответствующий символ в преобразованном значении, ^ и ‘,’ сопоставляют и преобразуют только первый символ преобразованного значения. Если pattern отсутствует, это трактуется как шаблон ?, которому соответствует каждый символ. Если parameter имеет значение * или @, преобразование регистра выполняется поочередно для всех позиционных параметров и результатом преобразования является полученный список. Если parameter является именем массива с индексом * или @, преобразование регистра применяется к каждому элементу массива поочередно и результатом преобразования является полученный список.

${parameter@operator}

Преобразование является изменением значения parameter или информации о parameter в зависимости от оператора operator, задаваемого одной буквой.

Q

Преобразование является строкой заключенного в кавычки значения parameter в пригодном для ввода формате.

E

Преобразование является строкой значения parameter с \-экранированием как в механизме $’…’.

P

Строка, полученная в результате преобразования parameter как будто это строка приглашения (6.9. Управление формой приглашения).

A

Преобразование строки в форме оператора присваивания или объявления, которое при вычислении воссоздает parameter с его атрибутами и значением.

a

Строка значений флагов, представляющих атрибуты parameter.

Если parameter имеет значение * или @, операция поочередно применяется к каждому позиционному параметру и результатом служит полученный список. Если parameter является именем массива с индексом * или @, операция применяется к каждому элементу массива поочередно и результатом является полученный список.

Результат подвергается дальнейшему преобразованию в форме расщепления слов и преобразования путей.

3.5.4. Подстановка команд

Подстановка позволяет заменить команду ее выводом и указывается в форме $(command) или ‘command‘. Bash выполняет преобразование путем выполнения команды command в субоболочке и подстановки ее стандартного вывода в основную оболочку с удалением завершающих символов newline. Символы newline внутри вывода не удаляются, но могут быть исключены при расщеплении слов. Подстановку $(cat file) можно заменить более быстрым эквивалентом $(< file).

При использовании старой формы подстановки с обратными кавычками символ \ сохраняет свое буквальное значение, кроме тех случаев, когда за ним следует $, ‘, или \. Первая обратная кавычка без предшествующего символа \ завершает выражение для подстановки команды. При использовании формы $(command) все символы между скобками являются частью команды без особой трактовки.

Подстановки команд могут быть вложенными. В случае использования формы с обратными кавычками внутренние кавычки экранируются символом \. Если подстановка указана в двойных кавычках, для результата не выполняется расщепление слов и преобразование имен файлов.

3.5.5. Арифметическое преобразование

Арифметическое преобразование позволяет вычислить результат арифметического выражения и подставить вместо него результат. Формат арифметического выражения имеет вид $(( expression )). Здесь expression трактуется как при указании в двойных кавычках, но такие кавычки внутри круглых скобок не имеют специального значения. Все маркеры в expression подвергаются преобразованию параметров и переменных, подстановке команд и удалению кавычек. Результат считается арифметическим выражением для расчета значения. Арифметические выражения могут быть вложенными.

Расчет выполняется в соответствии с правилами раздела 6.5. Арифметика командного процессора. Если выражение не действительно, Bash печатает сообщение об ошибке на стандартном устройстве вывода и не делает подстановки.

3.5.6. Подстановка процессов

Подстановка процессов позволяет указывать ввод или вывод процесса по имени файла. Подстановка имеет вид <(list) или >(list). Список процессов запускается асинхронного и его вход или выход отображается как имя файла. Это имя передается в качестве аргумента текущей команде как результат преобразования. При использовании формы >(list) запись в файл будет служить вводом списка. Если применяется форма <(list), переданный в качестве аргумента файл должен считываться для получения списка. Отметим, что между символом < или > и левой скобкой не может быть пробела, поскольку в этом случае выражение будет задавать перенаправление. Подстановка процессов доступна в системах, поддерживающих именованные каналы (fifo) и метод именования открытых файлов /dev/fd.

При доступности подстановки процессов она выполняется одновременно с преобразованием параметров и переменных, подстановкой команд и арифметическим преобразованием.

3.5.7. Расщепление слов

Оболочка сканирует результат преобразования параметров, подстановки команд и арифметического преобразования, которые выполнялись вне двойных кавычек, на предмет расщепления слов. Оболочка трактует каждый символ переменной $IFS как разделитель слов в результатах предшествующих преобразований. Если переменная IFS не задана или имеет принятое по умолчанию значение <space><tab><newline>, последовательности <space>, <tab>, <newline> в начале и в конце результата игнорируются, а последующие символы IFS считаются разделителями слов. Если значение IFS отличается от принятого по умолчанию, последовательности пробельных символов (<space><tab><newline>), а также пробельные символы IFS в начале и в конце игнорируются. Любой непробельный символ IFS вместе со смежными пробельными символами IFS считается разделителем слов, равно как и последовательность пробельных символов IFS, Если переменная IFS имеет пустое значение (null), слова не разделяются.

Явно пустые аргументы («» или ’’) сохраняются и передаются командам в виде пустых строк. Неявные null-аргументы без кавычек, полученные в результате преобразования параметров, не имеющих значений, удаляются. Если преобразуемый параметр в двойных кавычках имеет пустое значение, полученный в результате null-аргумент сохраняется и передается команде как пустая строка. Когда заключенный в кавычки null-аргумент является частью слова, которое преобразуется в непустое значение, null-аргумент удаляется. Например, слово -d’’ преобразуется в -d.

При отсутствии преобразований расщепления слов не производится.

3.5.8. Преобразование имен файлов

После расщепления слов, если не задана опция -f внутренней команды set (4.3.1. Внутренняя команда set), Bash сканирует каждое слово в поиске символов *, ? и [. При наличии любого из этих символов слово считается шаблоном и заменяется отсортированным по алфавиту списком имен файлов, соответствующих шаблону (3.5.8.1. Сопоставление с шаблоном). Если соответствующих шаблону имен не найдено, а опция оболочки nullglob отключена, слово сохраняется без изменений. При включенной опции nullglob и отсутствии совпадений слово удаляется, выводится сообщение об ошибке и команда не выполняется. Если включена опция оболочки nocaseglob, сопоставление выполняется без учета регистра символов.

При выполнении преобразования, символ ‘.’ в начале имени или сразу после / должен сопоставляться буквально, если не задана опция оболочки dotglob. Имена ‘.’ и ‘..’ всегда должны сопоставляться буквально, даже если включена опция dotglob. В остальных случаях символ ‘.’ не имеет специального значения.

При сопоставлении имен файлов символ / всегда должен точно соответствовать такому же символу в шаблоне, но в ином контексте сопоставления он может соответствовать иным символам, как описано в параграфе 3.5.8.1. Сопоставление с шаблоном.

Опции nocaseglob, nullglob, failglob и dotglob описаны в параграфе 4.3.2. Внутренняя команда shopt.

Переменную оболочки GLOBIGNORE можно применять для ограничения набора имен, соответствующих шаблону. Если эта переменная установлена, каждое совпадающее имя файла сопоставляется также с одним из шаблонов в GLOBIGNORE и удаляется из списка при совпадении. Если установлена опция nocaseglob, сопоставление с GLOBIGNORE выполняется без учета регистра. Имена . и .. игнорируются при установке непустой переменной GLOBIGNORE. Однако установка непустого значения GLOBIGNORE будет включать опцию dotglob, поэтому все имена, начинающиеся с ‘.’, будут совпадать с шаблоном. Для поддержки прежнего поведения с игнорированием имен, начинающихся с точки, следует добавить шаблон ‘.*’ в переменную GLOBIGNORE. Опция dotglob отключена, если переменная GLOBIGNORE не установлена.

3.5.8.1. Сопоставление с шаблоном

Все символы шаблона, за исключением описанных ниже специальных символов, должны совпадать при сопоставлении. Символ nul не может включаться в шаблоны, символ \ экранирует следующий символ, а сам при сопоставлении не учитывается. Специальные символы для буквальной трактовки в шаблоне должны заключаться в кавычки.

Специальные символы шаблонов и их трактовка описаны ниже.

*

Соответствует любой строке, включая пустую. При включенной опции globstar и использовании символа * в контексте преобразования имен файлов, два смежных символа * в одном шаблоне будут соответствовать всем файлам и имеющимся каталогам и подкаталогам. Если перед парой символов * имеется /, соответствовать шаблону будут лишь каталоги и подкаталоги.

?

Соответствует одному (любому) символу.

[…]

Соответствует одному из указанных в скобках символов. Пара символов, разделенных дефисом указывает диапазон, включающий граничные символы, с использованием порядка и набора символов текущего языка. Если после открывающей скобки [указан символ ! или ^, соответствовать шаблону будет любой символ, не входящий в диапазон. Символ − может указываться в качестве первого или последнего в диапазоне, ] — в качестве первого. Порядок сортировки символов в диапазоне определяется текущим значением locale и переменными LC_COLLATE и LC_ALL, если они установлены.

Например, с используемым по умолчанию C диапазон [a-dx-z] будет эквивалентен набору [abcdxyz]. Многие языки (locale) сортируют символы по словарю и для них [a-dx-z] обычно не является эквивалентом [abcdxyz] и может быть, например, эквивалентом [aBbCcDdxXyYz]. Для получения традиционной интерпретации диапазонов в квадратных скобках можно использовать C locale путем установки в переменной LC_COLLATE или LC_ALL значения C или включения опции globasciiranges.

Внутри скобок [] можно указать класс символов в форме [:class:], где class — одно из значений, определенных стандартом POSIX: alnum, alpha, ascii, blank, cntrl, digit, graph, lower, print, punct, space, upper, word, xdigit.

Классу соответствует любой символ указанного класса, например, классу word соответствуют буквы, цифры и _.

Внутри скобок [] можно указать класс эквивалентности с использованием синтаксиса [=c=], которому будут соответствовать все символы с таким весом сравнения (collation) в соответствии с настройкой, как у символа c.

Внутри скобок [] синтаксис [.symbol.] соответствует символу symbol.

Если опция оболочки extglob включена с использованием внутренней команды shopt, применяется несколько расширенных сопоставлений с шаблоном. В последующих описаниях pattern-list — это список, включающий по меньшей мере один шаблон с разделением шаблонов символом |. Могут создаваться композитные шаблоны с использованием одного или нескольких субшаблонов, описанных ниже.

?(pattern-list)

Соответствует не более, чем одному вхождению указанных шаблонов.

*(pattern-list)

Соответствует любому числу вхождений указанных шаблонов.

+(pattern-list)

Соответствует не менее, чем одному вхождению указанных шаблонов.

@(pattern-list)

Соответствует одному вхождению указанных шаблонов.

!(pattern-list)

Соответствует всему, за исключением любого из указанных шаблонов.

Сопоставление расширенных шаблонов с длинными строками является медленным, особенно при наличии в шаблонах чередований а в строках — многочисленных совпадений. Использование отдельных сопоставлений для более коротких строк или применение массива строк вместо одной длинной строки может ускорить процесс.

3.5.9. Удаление кавычек

После выполнения описанных выше преобразований удаляются все не заключенные в кавычки символы \, ’ и «, не являющиеся результатом предшествующих преобразований.

3.6. Перенаправление

Перед выполнением команды ее ввод и вывод могут быть перенаправлены с использованием специальной нотации командного процессора. Перенаправление позволяет дублировать, открывать, закрывать, ссылаться на другие файлы и менять файлы, которые команда читает или записывает. Описанные ниже перенаправления могут предшествовать команде, а также указываться внутри или после команды. Перенаправления обрабатываются в порядке их указания, слева направо.

Для каждого перенаправления, которому может номер дескриптора файла, вместо такого номера может быть указано слово вида {varname}. В этом случае для каждого оператора перенаправления, кроме >&- и <&-, командный процессор может назначить дескриптор файла больше 10 и присвоить его {varname }. Если слову {varname } предшествует >&- или <&-, значение varname определяет дескриптор файла для закрытия. Если указано слово {varname}, перенаправление остается за рамками команды, что позволяет программировать управление дескриптором.

В последующих описаниях при опущенном номере дескриптора файла первый символ перенаправления < задает стандартный ввод (дескриптор 0), а первый символ > — стандартный вывод (дескриптор 1). Для слова за оператором перенаправления в последующих описаниях (если явно не указано иное) выполняется преобразование фигурных скобок, тильды и параметров, подстановка команд, арифметические преобразования, удаление кавычек, преобразование имени файла и расщепление слов. Если в результате получается более одного слова, bash возвращает ошибку.

Порядок перенаправления имеет значение. Например, команда ls > dirlist 2>&1 направляет стандартный вывод (дескриптор 1) и стандартный вывод ошибок (дескриптор 2) в dirlist, а команда ls 2>&1 > dirlist направляет в файл dirlist лишь стандартный вывод, поскольку стандартный вывод ошибок выполняет копирование стандартного вывода до его перенаправления в dirlist.

Bash обрабатывает некоторые имена файлов при перенаправлениях в соответствии с приведенным ниже описанием. Если операционная система, где работает bash, использует такие файлы, bash будет применять их. В остальных случаях будет выполняться внутренняя эмуляция, описанная ниже.

/dev/fd/fd

Если fd является пригодным целым числом, файловый дескриптор fd дублируется.

/dev/stdin

Файловый дескриптор 0 дублируется.

/dev/stdout

Файловый дескриптор 1 дублируется.

/dev/stderr

Файловый дескриптор 2 дублируется.

/dev/tcp/host/port

Если host является действительным именем хоста или адресом Internet, а port — целочисленным номером порта или именем службы bash пытается открыть соответствующий сокет TCP.

/dev/udp/host/port

Если host является действительным именем хоста или адресом Internet, а port — целочисленным номером порта или именем службы bash пытается открыть соответствующий сокет UDP.

Отказ при открытии или создании файла ведет к отказу перенаправления.

Перенаправление с файловыми дескрипторами больше 9 следует применять с осторожностью, поскольку это может вызывать конфликты с дескрипторами, используемыми внутри командного процессора.

3.6.1. Перенаправление ввода

Перенаправление ввода ведет к тому, что открывается для чтения файл, имя которого получено из слова команды, для дескриптора n или стандартного ввода (дескриптор 0), если n отсутствует. Базовый формат перенаправления ввода имеет вид

[n]<word

3.6.2. Перенаправление вывода

Перенаправление ввода ведет к тому, что открывается для записи файл, имя которого получено из слова команды, для дескриптора n или стандартного вывода (дескриптор 1), если n отсутствует. Файл при открытии усекается до нулевого размера. Базовый формат перенаправления вывода имеет вид

[n]>[|]word

Если используется оператор перенаправления > и включена опция noclobber для внутренней команды set, перенаправление будет приводить к отказу, если полученное после преобразования имя указывает реально существующий обычный файл. Если указан оператор перенаправления >| или оператор > с выключенной опцией noclobber, будет выполнена попытка перенаправления даже при наличии указанного словом файла.

3.6.3. Добавление перенаправленного вывода

Перенаправление вывода таким способом ведет к открытию файла, имя которого получено из преобразования word, в режиме добавления в конец для файлового дескриптора n или стандартного вывода (дескриптор 1), если n отсутствует. Если нужного файла нет, он создается. Базовый формат перенаправления в конец файла имеет вид

[n]>>word

3.6.4. Перенаправление стандартного вывода и стандартного вывода ошибок

Эта конструкция позволяет перенаправить стандартный вывод (дескриптор 1) и стандартный вывод ошибок (дескриптор 2) в файл, имя которого определяется преобразованием параметра word. Применяются 2 варианта — &>word и >&word. Первая форма семантически эквивалентна >word 2>&1. При использовании второй формы параметр word может быть преобразован не в число или -. В таких случаях применяются другие операторы перенаправления (3.6.8. Дублирование файловых дескрипторов) для обеспечения совместимости.

3.6.5. Добавление стандартного вывода и стандартного вывода ошибок

Эта конструкция позволяет перенаправить стандартный вывод (дескриптор 1) и стандартный вывод ошибок (дескриптор 2) в конец имеющегося файла, имя которого указывается преобразованием word. Формат добавления вывода в файл имеет вид &>>word, что семантически эквивалентно выражению >>word 2>&1 (см. 3.6.8. Дублирование файловых дескрипторов).

3.6.6. Перенаправление из документа

Этот тип перенаправления задает оболочке чтение файла до строки, содержащей лишь word (без пробелов в конце). Все прочитанные из файла строки затем служат стандартным вводом (или файлом с дескриптором n, если он задан) для команды.

Формат here-document имеет вид

[n]<<[−]word
	here-document
delimiter

Для word не выполняется преобразования параметров и переменных, подстановки команд, арифметического преобразования и преобразования имен файлов. Если какая-либо часть word заключена в кавычки, разделитель delimiter является результатом удаления кавычек из word, а строки here-document не раскрываются. Если word не содержит кавычек, все строки here-document подвергаются преобразованию параметров, подстановке команд и арифметическому преобразованию. Последовательность \newline игнорируется, а символ \ должен применяться для экранирования \, $ и ‘.

Если задан оператор перенаправления <<-, все предшествующие символы табуляции игнорируются во входных строках и строке, содержащей delimiter. Это позволяет работать с shell-сценариями, использующими табуляцию.

3.6.7. Перенаправление из строки

Вариант here-document, имеющий формат [n]<<< word. Параметр word подвергается преобразованию тильды, параметров и переменных, подстановке команд, арифметическому преобразованию и удалению кавычек. Преобразование путей и расщепление слов не применяются. Результат представляется как одна строка с символом newline в конце на стандартный ввод (или файл с дескриптором n, если он задан.

3.6.8. Дублирование файловых дескрипторов

Оператор перенаправления [n]<&word служит для дублирования дескрипторов входных файлов. Если word преобразуется в одну или несколько цифр, дескриптор файла, обозначенный n, становится соответствующим преобразованному числу. Если word преобразуется в -, файл с дескриптором n закрывается. Если n не задано, используется стандартный ввод (дескриптор 0).

Оператор [n]>&word используется аналогичным способом для дублирования дескрипторов выходных файлов. Если n не задано, используется стандартный вывод (дескриптор 1). Если цифры word не задают дескриптора файла, открытого для вывода, возникает ошибка перенаправления. Если word преобразуется в -, файл с дескриптором n закрывается. Особым случаем является отсутствие n и преобразование word, отличное от цифр и -. В этом случае выполняется перенаправление стандартного вывода и стандартного вывода ошибок, описанное выше.

3.6.9. Перемещение файловых дескрипторов

Оператор перенаправления [n]<&digit- перемещает файловый дескриптор digit в файловый дескриптор n или стандартный ввод (дескриптор 0), если параметр n не задан. Файл с дескриптором digit закрывается после дублирования.

Оператор [n]>&digit- перемещает файловый дескриптор digit в файловый дескриптор n или стандартный вывод (дескриптор 1), если параметр n не задан.

3.6.10. Дескрипторы открытия файлов для чтения и записи

Оператор перенаправления [n]<>word вызывает открытие файла, имя которого задано преобразованием word, для чтения и записи с файловым дескриптором n (или 0, n не задано). Если такого файла нет, он создается.

3.7. Выполнение команд

3.7.1. Преобразование простых команд

При вводе простой команды оболочка выполняет перечисленные ниже преобразования, назначения и перенаправления.

  1. Слова, которые анализатор отметил как назначения переменных (до команды), и перенаправления сохраняются для последующей обработки.

  2. Слова, не относящиеся к назначению переменных и перенаправлению преобразуются (3.5. Преобразования). Если после преобразования остаются какие-либо слова, первое из них считается именем команды, а остальные — ее аргументами.

  3. Выполняется перенаправление (3.6. Перенаправление).

  4. Текст после символа = в каждом назначении переменной подвергается преобразованию тильды и параметров, подстановке команд, арифметическому преобразованию и удалению кавычек до назначения его переменной.

Если результат не содержит имени команды, назначения применяются к переменным текущей оболочки. В остальных случаях переменные назначаются в среде выполняемой команды и не влияют на окружение текущей оболочки. При попытке задать значение переменной, доступной лишь для чтения, возникает ошибка и команда возвращает отличных от 0 статус.

Если результат не содержит имени команды, перенаправления выполняются, но не оказывают влияния на текущую среду оболочки. Ошибка перенаправления вызывает завершение с отличным от 0 статусом возврата.

Если после преобразований осталось имя команды, выполнение продолжается, как описано ниже. В противном случае команда завершается. Если какое-либо преобразование включает подстановку команд, статусом возврата команды будет статус выхода последней подстановки команды. Если подстановки команд не было, возвращается статус 0.

3.7.2. Поиск и выполнение команд

Если результатом расщепления команды на слова является простая команда с необязательным списком аргументов, выполняются перечисленные ниже действия.

  1. Если имя команды не содержит символов /, оболочка пытается найти нужную команду. При наличии функции оболочки с нужным именем, эта функция вызывается, как описано в разделе 3.3. Функции оболочки.

  2. Если имя не соответствует функции, оболочка просматривает список внутренних команд и при нахождении нужной команды выполняет ее.

  3. Если имени нет в числе функций и внутренних команд и оно не включает символов /, Bash выполняет поиск исполняемого файла в каталогах переменной $PATH. Bash использует хэш-таблицу для запоминания полных путей к исполняемым файлам для снижения числа обращений к переменной PATH (см. описание hash в параграфе 4.1. Внутренние элементы Bourne Shell). Полный поиск в переменной $PATH выполняется лишь при отсутствии команды в хэш-таблице. Если поиск не дал результата, оболочка пытается найти функцию с именем command_not_found_handle. При наличии такой функции она вызывается в отдельной среде выполнения с использованием исходной команды и ее параметров в качестве аргументов, а статус выхода этой функции служит статусом завершения субоболочки. Если функция не найдена, оболочка выводит сообщение об ошибке и возвращает статус 127.

  4. Если поиск дал результат или имя команды содержит один или несколько символов /, оболочка выполняет указанную именем команду в отдельной среде. Аргументу 0 присваивается имя команды, а остальные аргументы служат аргументами выполняемой команды.

  5. Если при выполнении команды возникает отказ по причине того, что файл не является исполняемым и этот файл не является каталогом, предполагается, что это сценарий оболочки и выполняется процедура, описанная в параграфе 3.8. Сценарии оболочки.

  6. Если команда не была запущена асинхронно, оболочка ждет завершения команды и определяет его статус.

3.7.3. Среда выполнения команды

Среда выполнения оболочки включает ряд элементов, перечисленных ниже.

  • Открытые файлы, наследуемые оболочкой при вызове и измененные путем перенаправления, предоставляемых внутренней функции exec.

  • Текущий рабочий каталог, установленный командой cd, pushd, popd или унаследованный при вызове.

  • Режим создания файлов, установленный umask или унаследованный от родителя оболочки.

  • Текущие прерывания (trap) установленные функцией trap.

  • Параметры оболочки, заданные путем назначения переменных, с помощью команды set или унаследованные от родителя оболочки.

  • Функции оболочки, определенные в процессе работы или унаследованные от родителя.

  • Опции, включенные при вызове (принятые по умолчанию или заданные в команде) или установленные с помощью set.

  • Опции, включенные shopt (4.3.2. Внутренняя команда shopt).

  • Псевдонимы, определенные с помощью alias (6.6. Псевдонимы).

  • Идентификаторы процессов, включая идентификаторы фоновых заданий (3.2.3. Списки ), значения $$ и $PPID.

При выполнении простой команды, не являющейся внутренней, или shell-функции она вызывается в отдельной среде исполнения, включающей указанные ниже элементы (если не указано иное, значения наследуются из оболочки).

  • Открытые файлы оболочки с учетом изменений и дополнений, заданных перенаправлениями команды.

  • Текущий рабочий каталог.

  • Маска режима создания файлов.

  • Переменные и функции оболочки, указанные для экспорта, вместе с переменными экспортированными для команды, которые были переданы в окружении (3.7.4. Окружение)

  • Прерывания, захваченные оболочкой, сбрасываются к значениям, унаследованным от родителя оболочки, а игнорируемые оболочкой прерывания не учитываются.

Команда, вызываемая в этой отдельной среде, не может оказывать влияния на среду оболочки.

Подстановки команд, команды, объединенные круглыми скобками, и асинхронные команды вызываются в среде субоболочки, которая дублирует окружение основной оболочки за исключением того, что установленные оболочкой прерывания сбрасываются к значениям, унаследованным оболочкой при вызове от родителя. Изменения в среде субоболочки не могут влиять на окружение оболочки.

Субоболочки, порожденные для выполнения подстановки команд, наследуют значение опции -e от родительской оболочки. При работе не в режиме POSIX оболочка Bash сбрасывает опцию -e в таких субоболочках.

Если за командой следует символ &, а управление заданиями не активизировано, принятым по умолчанию стандартным вводом для команды служит /dev/null. В остальных случаях вызываемая команда наследует дескрипторы файлов от вызывающей оболочки с учетом перенаправлений.

3.7.4. Окружение

При вызове программы она получает массив строк, называемый окружением или средой. Этот список включает пары «имя-значение» в формате name=value.

Bash обеспечивает несколько способов управления средой. При вызове оболочка сканирует свое окружение и создает параметр для каждого найденного имени, автоматически помечая его для экспорта в дочерние процессы. Выполняемые команды наследуют окружение. Команды export и declare -x позволяют добавлять параметры и функции в среду или удалять их. При изменении параметра в окружении новое значение становится частью среды взамен прежнего. Среда, наследуемая каждой выполняемой командой, состоит из начального окружения оболочки, значения которого можно изменять, за исключением пар, удаляемых командой unset или export -n, а также дополнений, вносимых командами export и declare -x.

Среду для простой команды или функции можно временно дополнить с помощью префиксов с назначением параметров, как описано в параграфе 3.4. Параметры оболочки. Эти назначения влияют лишь на среду, видимую данной командой. Если установлена опция -k (4.3.1. Внутренняя команда set), все назначения параметров помещаются в среду для команды в дополнение к предшествующим имени команды.

Когда Bash вызывает внешнюю команду, в переменной $_ устанавливается полный путь к этой команде и он передается в среду данной команды.

3.7.5. Статус выхода

Статусом завершения выполняемой команды является число, возвращаемое системным вызовом waitpid или эквивалентной функцией. Статус может принимать значения от 0 до 255, а значения более 125 могут иметь особый смысл. Статус вывода внутренних функций и составных команд также ограничен значением 125. Специальные значения используются оболочкой при некоторых обстоятельствах для указания особых вариантов отказа.

В оболочке возврат командой статуса 0 означает успешное выполнение, а отличное от 0 значение говорит об отказе. Эта, на первый взгляд нелогичная, схема обеспечивает однозначную индикацию успеха и различные способы указания отказов. При завершении команды со статусом N оболочка Bash возвращает в качестве статуса значение 128+N.

Если команда не найдена, дочерний процесс, созданный для ее выполнения, возвращает статус 127. Если найденная команда не является исполняемой, статус возврата будет иметь значение 126. При отказе команды в результате ошибки при преобразовании или перенаправлении возвращается статус больше 0.

Статус выхода используется условными командами Bash (3.2.4.2. Конструкции с условием) и некоторыми списками (3.2.3. Списки ).

Все внутренние команды Bash возвращают статус выхода 0 при успешном выполнении и отличных от 0 статус при отказе, что может применяться в условных выражениях и списках. Все внутренние команды возвращают статус 2 для индикации некорректного использования, что обычно связано с непригодными опциями или отсутствием аргументов.

3.7.6. Сигналы

При работе Bash в интерактивном режиме в отсутствие каких-либо прерываний оболочка игнорирует сигнал SIGTERM (поэтому kill 0 не прерывает активную оболочку), а SIGINT перехватывается и обрабатывается (с прерыванием функции ожидания). Когда Bash получает SIGINT, выполнение всех имеющихся циклов прерывается. Сигнал SIGQUIT игнорируется во всех случаях. При включенном управлении заданиями (7. Управление заданиями) Bash игнорирует SIGTTIN, SIGTTOU и SIGTSTP.

Для внешних команд, запускаемых Bash, значения обработчиков сигналов наследуются оболочкой от родителя. Когда управления заданиями нет, асинхронные команды игнорируют сигналы SIGINT и SIGQUIT в дополнение к унаследованным обработчикам. Команды, выполняемые в результате подстановки, игнорируют полученные от клавиатуры сигналы управления заданиями SIGTTIN, SIGTTOU, SIGTSTP.

По умолчанию оболочка завершает работу по сигналу SIGHUP. Перед выходом интерактивная оболочка повторяет SIGHUP для всех заданий (работающих и остановленных). Остановленные задания передают SIGCONT, подтверждающий получение SIGHUP. Чтобы оболочка не передавала SIGHUP конкретному заданию, следует удалить его из таблицы заданий с помощью внутренней команды disown (7.2. Внутренние средства управления заданиями) или пометить его как не получающее сигнал SIGHUP с помощью disown -h.

Если была установлена опция huponexit с помощью внутренней команды shopt (4.3.2. Внутренняя команда shopt), Bash передает SIGHUP всем заданиям при завершении интерактивной оболочки (login shell).

Если Bash ожидает завершения команды и получает сигнал, для которого установлена ловушка, прерывание не будет выполняться до завершения команды. Когда Bash ждет завершения асинхронной команды с помощью внутренней команды wait, получение сигнала, для которого установлена ловушка, будет приводить к незамедлительному возврату из внутренней команды wait со статусом 128, после чего сразу выполняется прерывание.

3.8. Сценарии оболочки

Сценарий оболочки (shell script) представляет собой текстовый файл с командами оболочки. При использовании такого файла в качестве первого аргумента, не являющегося опцией в вызове Bash и отсутствии опций -c и -s (6.1. Вызов Bash) Bash считывает и выполняет команды из этого файла, затем возвращает управление. Такой режим работы называется неинтерактивным. Файл ищется сначала в текущем каталоге, затем в каталогах $PATH.

При выполнении сценария Bash устанавливает в специальном параметре 0 имя файла вместо имени оболочки, а позиционными параметрами становятся оставшиеся аргументы. Если их нет, позиционные параметры не устанавливаются.

Сценарий можно сделать исполняемым с помощью команды chmod. Когда Bash такой файл в $PATH, порождается субоболочка для его выполнения. Т. е. команда filename arguments эквивалентна bash filename arguments, если filename является исполняемым файлом сценария. Эта субоболочка инициализирует себя, как будто для сценария вызвана новая оболочка, за исключением того, что расположение команд, запомненных родителем (см. описание hash в параграфе 4.1. Внутренние элементы Bourne Shell), сохраняется потомком.

Большинство версий Unix делают это частью механизма выполнения команд. Если первая строка сценария начинается символами #!, остальная часть этой строки задает интерпретатор команд для сценария. Это позволяет выбрать интерпретатор Bash, awk, Perl и т. п., а оставшуюся часть сценария написать на соответствующем языке.

Аргументы интерпретатора состоят из одного необязательного аргумента в первой строке файла сценария, следующего за именем интерпретатора, за которым может следовать имя файла сценария и остальные аргументы. Bash выполнит нужные действия в операционной систем, которая сама не справляется с этим. Отметим, что некоторые старые версии Unix ограничивают размер строки с именем интерпретатора и аргументами 32 символами.

Сценарии Bash часто начинаются строкой #! /bin/bash (в предположении установки Bash в каталоге /bin), поскольку это обеспечивает выполнение команд интерпретатором Bash даже при запуске сценария из иной оболочки.

4. Внутренние команды оболочки

Встроенные команды реализованы в самой оболочке. При использовании внутренней команды в качестве первого слова простой команды (3.2.1. Простые команды) оболочка напрямую выполняет команду без вызова других программ. Внутренние команды нужны для реализации функций, которые невозможно или неудобно выполнять внешними утилитами. В этой главе кратко описаны встроенные функции Bash, унаследованные от Bourne Shell, а также внутренние команды, присущие Bash или расширенные в этой оболочке.

Некоторые внутренние команды описаны в других параграфах — команды интерфейса Bash для управления заданиями (7.2. Внутренние средства управления заданиями), стек каталогов (6.8.1. Внутренние команды стека каталогов), команды истории (9.2. Внутренние команды истории Bash) и программируемые инструменты завершения команд (8.7. Внутренние функции программируемого дополнения). Многие из этих команд были расширены в POSIX или Bash.

Если явно не указано иное, каждая из внутренних команд, описанная как воспринимающая опции с префиксом -, принимает — для обозначения конца опций. Внутренние элементы :, true, false и test/[ не принимают опций и не применяют специальной трактовки —. Внутренние функции exit, logout, return, break, continue, let и shift воспринимают и обрабатывают аргументы с префиксом -, не требуя —. Остальные встроенные функции, которые принимают аргументы, но не указаны как принимающие опции, трактуют аргументы с префиксом — как ошибки и требуют — для предотвращения такой интерпретации.

4.1. Внутренние элементы Bourne Shell

Приведенные ниже внутренние операторы и команды унаследованы от Bourne Shell и реализованы в соответствии со стандартом POSIX.

: (двоеточие)

: [arguments]

Не делает ничего, кроме преобразования аргументов и выполнения перенаправлений. Статус возврата 0.

. (точка)

. filename [arguments]

Считывает и выполняет команды из файла filename в контексте текущей оболочки. Если filename не начинается с символа /, для поиска файла применяется переменная PATH. Когда bash работает не в режиме POSIX, просматривается также текущий каталог, если файл не найден в $PATH. Если представлены какие-либо аргументы, они становятся позиционными параметрами при выполнении filename. В остальных случаях позиционные параметры остаются неизменными. При включенной опции -T source наследует все ловушки (прерывания) DEBUG, а если это не так, любая строка DEBUG trap сохраняется перед вызовом source и восстанавливается после него, а source отменяет DEBUG trap при выполнении. Если опция -T не задана и выполняемый файл меняет DEBUG, по завершении source сохраняется новое значение. Статусом возврата является статус выхода последней выполненной команды или 0, если команды не выполнялись. Если файл filename не найден или его не удалось причитать, статус возврата будет отличен от 0. Этот оператор эквивалентен команде source.

break

break [n]

Выход из цикла for, while, until или select loop. При наличии параметра n выполняется выход из n-го вложенного цикла. Значение n должно быть не меньше 1. Возвращает статус 0, пока n не меньше 1.

cd

cd [-L|[-P [-e]] [-@] [directory]

Меняет текущий рабочий каталог на directory. Если параметр directory не указан, применяется значение переменной HOME. Все аргументы после directory игнорируются. При наличии переменной оболочки CDPATH она используется как путь поиска — каждое имя в CDPATH просматривается на предмет directory. Имена каталогов в CDPATH разделяются символом :. Если параметр directory начинается с символа /, CDPATH не используется.

Опция -P отключает следование по символьным ссылкам. Символьные ссылки преобразуются, когда cd проходит directory и до обработки экземпляра .. в directory. По умолчанию или при задании опции -L символьные ссылки в directory преобразуются после того, как cd обработает экземпляр .. в directory. Если .. присутствует в directory, это значение обрабатывается путем удаления непосредственно предшествующего элемента пути в направлении / или начала directory.

При наличии опций -e и -P и невозможности определения текущего каталога после смены cd будет возвращать статус отказа.

В системах, поддерживающих опцию -@, она задает расширенные атрибуты, связанные с файлом в качестве directory.

Если directory имеет значение -, оно преобразуется в $OLDPWD до попытки смены каталога.

При использовании непустого имени каталога из CDPATH или первом аргументе — и успешной смене каталога абсолютное имя нового рабочего каталога передается на стандартный вывод.

При смене каталога возвращается статус 0, при неудаче — отличное от нуля значение.

continue

continue [n]

Возобновляет следующую итерацию цикла for, while, until или select. Если указан параметр n, возобновляется n-й цикл. Значение n должно быть не меньше 1. Возвращает статус 0, если не было задано значение n меньше 1.

eval

eval [arguments]

Аргументы (arguments) объединяются в одну команду, которая считывается и выполняется, Статус завершения команды будет статусом выхода eval. При отсутствии arguments или пустых аргументах возвращается статус 0.

exec

exec [-cl] [-a name] [command [arguments]]

При наличии параметра command команда заменяет оболочку без создания нового процесса. Если задана опция -l, оболочка помещает тире в начале нулевого аргумента, передаваемого команде (это то, что делает программа login). Опция -c задает выполнение команды с пустым окружением. При наличии опции -a оболочка передает name в качестве нулевого аргумента для command. Если команда не может быть выполнена по какой-либо причине, неинтерактивная оболочка завершается, пока не включена опция execfail и возвращается статус отказа. Интерактивная оболочка возвращает отказ при невозможности выполнить файл (команду). Субоболочка завершается безусловно при отказе exec. Если команда не задана, могут использоваться перенаправления для воздействия на среду текущей оболочки. Если перенаправления не приводят к ошибке, возвращается статус 0, в случае ошибки статус будет ненулевым.

exit

exit [n]

Выход из оболочки с возвратом родителю статуса n. Если параметр n не задан, возвращается статус завершения последней команды. Все прерывания EXIT выполняются до завершения оболочки.

export

export [-fn] [-p] [name[=value]]

Помечает каждое имя name для передачи дочерним процессам в среде. Наличие опции -f указывает, что имена относятся к функциям оболочки, без этой опции они указывают переменные оболочки. Опция -n отменяет пометки для экспорта name. Если имена не указаны или задана опция -p, выводится список всех экспортируемых переменных в форме, пригодной для ввода. Если после имени переменной следует значение (=value), это значение устанавливается для переменной.

Возвращается статус 0, если не было задано непригодных опций или имен переменных (name), а также опция -f не была указана с недействительным именем функции оболочки.

getopts

getopts optstring name [args]

Команда getopts используется сценариями оболочки для разбора позиционных параметров. Аргумент optstring содержит символы опции для распознавания. Если за символом следует двоеточие, предполагается наличие у опции аргумента, который должен быть отделен пробелом. Двоеточие и знак вопроса не могут использоваться как символы опций. При каждом вызове getopts помещает следующую опцию в переменную оболочки name, инициализируя переменную при ее отсутствии, а индекс следующего обрабатываемого элемента — в переменную OPTIND. Переменная OPTIND инициализируется значением 1 при каждом вызове оболочки или shell-сценария. Когда опции нужен аргумент, getopts помещает его в переменную OPTARG. Оболочка не сбрасывает OPTIND автоматически и переменную нужно сбрасывать вручную между вызовами getopts в рамках одного вызова оболочки, если будет применяться новый набор параметров.

При достижении конца опций getopts завершает работу с кодом возврата, отличным от 0. В OPTIND указывается индекс первого аргумента, не являющегося опцией, а для name устанавливается значение ‘?’.

Команда getopts обычно анализирует позиционные параметры, но при наличии дополнительных аргументов в args разбираются эти аргументы.

Ошибки getopts могут возвращаться двумя способами. Если первым символом optstring является двоеточие, используется «тихое» уведомление об ошибках, а при обычной работе выводится диагностическое сообщение с указанием непригодных или пропущенных опций. Если OPTERR = 0, сообщения об ошибках не выводятся даже при отсутствии двоеточия в первом символе optstring.

При обнаружении недействительной опции getopts помещает ? в name и в обычном (не «тихом») режиме выводит сообщение об ошибке и сбрасывает OPTARG. В «тихом» режиме символ опции помещается в OPTARG без вывода диагностического сообщения.

Если нужный аргумент не найден и для getopts не задан «тихий» режим, в name помещается ?, OPTARG сбрасывается и выводится диагностическое сообщение. Если getopts работает в «тихом» режиме, в name помещается :, а в OPTARG — найденный символ опции.

hash

hash [-r] [-p filename] [-dt] [name]

При каждом вызове hash запоминаются полные пути к командам, указанным в качестве аргументов, поэтому их уже не нужно искать при последующих вызовах. Поиск команд выполняется путем просмотра каталогов, указанных в переменной $PATH. Все ранее запомненные пути отбрасываются. Опция -p отключает поиск пути а filename служит для указания местоположения name. Опция -r заставляет оболочку забыть все запомненные местоположения, опция -d заставляет забыть запомненное местоположение каждого значения name. При наличии опции -t выводится полный путь, которому соответствует каждое значение name. При указании множества аргументов name с опцией -t, значения name выводятся перед хэшированными путями. Опция -l обеспечивает вывод в формате, пригодном для ввода. Если опция -l задана без каких-либо других аргументов команды, выводится информация о запомненных командах.

Статус возврата имеет значение 0, если команда не содержит недействительной опции и name найдено.

pwd

pwd [-LP]

Выводит абсолютный (полный) путь к текущему каталогу. Опция -P исключает вывод символьных ссылок в пути, опция -L включает. Статусом возврата будет 0, если не возникло ошибок при определении пути к текущему каталогу или не была задана недействительная опция.

readonly

readonly [-aAf] [-p] [name[=value]] ...

Помечает каждую переменную name как доступную лишь для чтения. Значения этой переменной невозможно будет изменить путем назначения. При наличии опции -f параметр name относится к функциям оболочки. Опция -a связывает name с переменными индексированных массивов, -A — с переменными ассоциативных массивов. При наличии обеих опций будет применяться -A. Если аргументов name не задано или указана опция -p, выводится список переменных, доступных только для чтения, в формате пригодном для ввода. Могут применяться другие опции для ограничения выводимого множества имен readonly. Если имя задано в форме name=value, для переменной устанавливается значение value. Команда возвращает статус 0, если не указано недействительных опций, параметр name не задает недействительную переменную или функцию оболочки и опция -f не указана с параметром name, не соответствующим функции оболочки.

return

return [n]

Вызывает остановку функции оболочки с возвратом статуса n. Если параметр n не указан, статусом возврата будет статус выхода последней команды, выполненной в функции. Если команда return вызывается обработчиком прерываний (trap), для определения статуса используется последняя команда, вызванная перед обработчиком прерывания. При вызове return в процессе обработки прерывания DEBUG статус возврата определяется последней командой, выполненной обработчиком прерывания перед вызовом return. Команду return можно применять для прерывания сценариев, выполняемых с помощью внутренней команды . (source), возвращая n или статус выхода последней выполненной команды сценария. При указанном значении n возвращаются 8 младших битов этого значения. Любая команда, связанная с прерыванием RETURN, выполняется до возобновления исполнения после функции или сценария. Статус возврата отличается от 0, если команда return вызвана с аргументом, не являющимся числом, использована за пределами функции или не в процессе выполнения сценария с помощью внутренней команды . или source.

shift

shift [n]

Сдвигает позиционные параметры влево на n позиций, в результате чего параметры $n+1 — $# становятся $1 — $#-n, а параметры $# — $#-n+1 сбрасываются. Значение n должно быть неотрицательным целым числом или $#. Если n=0 или больше $#, позиционные параметры не меняются. По умолчанию предполагается n=1. Возвращается статус 0, если n не превышает $# и не является отрицательным.

test

[

test expr

Вычисляется условное выражение expr и возвращается статус 0 (true) или 1 (false). Каждый оператор и операнд должен быть отдельным аргументом. Выражения состоят из примитивов, описанных в разделе 6.4. Условные выражения bash. Команда test не принимает опций, а также не воспринимает (игнорирует) аргумент —, указывающий завершение опций.

При использовании формы [ последним аргументом команды должна быть закрывающая скобка ].

Выражения могут комбинироваться с использованием перечисленных ниже операторов (в порядке снижения предпочтения). Результат зависит от числа аргументов, как описано ниже. При 5 и более аргументах используется порядок применения операторов.

! expr

True, если expr дает false.

( expr )

Возвращает значение expr и может использоваться для переопределения порядка применения операторов.

expr1 -a expr2

True, если оба выражения expr1 и expr2 дают true.

expr1 -o expr2

True, если любое их выражений expr1 и expr2 дает true.

Внутренние функции test и [ оценивают условные выражения на основе правил, учитывающих число аргументов.

0

Выражение дает false.

1

Выражение дает true тогда и только тогда, когда аргумент отличен от null.

2

Если первым аргументом является !, выражение дает true тогда и только тогда, когда второй аргумент имеет значение null. Если первым аргументом является один из унарных условных операторов (6.4. Условные выражения bash), выражение дает true, если унарная проверка дает true. Если первый аргумент не является действительным унарным оператором, выражение дает false.

3

Применяются приведенные ниже правила в указанном порядке.

  1. Если вторым аргументом является один из бинарных условных операторов (6.4. Условные выражения bash), результатом выражения является результат применения бинарного оператора к первому и третьему аргументам. При наличии у команды 3 аргументов операторы -a и -o считаются бинарными.

  2. Если первым оператором является !, значение является отрицанием теста с использованием второго и третьего аргументов.

  3. Если первым аргументом является (, а третьим — ), результатом будет тест для второго аргумента (внутри скобок).

  4. В остальных случаях выражение дает false.

4

Если первым оператором является !, результатом будет отрицание трехаргументного выражения, образуемого оставшимися аргументами. В остальных случаях выражение анализируется и оценивается с использованием порядка применения операторов и приведенных выше правил.

5 и более

Выражение анализируется и оценивается с использованием порядка применения операторов и приведенных выше правил.

При использовании с test или [ операторы < и > работают с лексикографической сортировкой на базе ASCII.

times

times

Выводит пользовательское и системное время, применяемое оболочкой и ее потомками. Статус возврата 0.

trap

trap [-lp] [arg] [sigspec ...]

Команды, указанные параметром arg, будут считываться и выполняться при получении оболочкой сигнала sigspec. Если параметр arg не задан (и есть один сигнал sigspec) или имеет значение -, каждое заданное размещение сигнала сбрасывается к значению перед запуском оболочки. Если arg является пустой строкой (null), сигнал, заданный каждым параметром sigspec, игнорируется оболочкой и вызываемыми ею командами. Если arg отсутствует и задана опция -p, оболочка выводит команды прерывания, связанные с каждым sigspec. Если аргументы не заданы или указана лишь опция -p, команда trap выводит список команд, связанных с каждым номером сигнала в форме, которая может служить вводом для оболочки. Опция -l заставляет оболочку выводить список имен сигналов с их номерами. Каждый параметр sigspec является именем или номером сигнала. Регистр символов в именах сигналов не принимается во внимание, а префикс SIG не обязателен.

Если sigspec имеет значение 0 или EXIT, команда arg выполняется при выходе из оболочки. Если sigspec = DEBUG, команда arg выполняется перед каждой простой командой, for, case, select, каждым арифметическим преобразованием для команды и перед выполнением первой команды в функции оболочки. В описании опции extdebug внутренней команды shopt (4.3.2. Внутренняя команда shopt) рассмотрено влияние на прерывание DEBUG. Если sigspec = RETURN, команда arg выполняется каждый раз, когда завершается shell-функция или сценарий, выполняемые с использованием внутренних функций . или source.

Если sigspec = ERR, команда arg выполняется всякий раз, когда конвейер (может состоять из одной простой команды), список или составная команда возвращает отличный от нуля статус завершения при соблюдении перечисленных далее условий. Прерывание ERR не выполняется, если отказавшая команда является частью списка, следующего сразу за ключевым словом until или while, частью проверки, следующей сразу за ключевым словом if или elif, частью команды, выполняемой в списке && или ||, кроме команды, следующей за последним && или ||, не последней командой конвейера или командой, статус возврата которой инвертируется символом !. Этим же условия действуют для опции errexit (-e).

Сигналы, игнорируемые на входе в оболочку, не могут быть перехвачены или сброшены. Перехваченные сигналы, которые не игнорируются, возвращаются к исходным значениям субоболочки или среды, где они были созданы.

Статус возврата равен 0, пока sigspec не задает действительный сигнал.

umask

umask [-p] [-S] [mode]

Задает для процессов создания файлов маску mode. Если значение mode начинается с цифры, оно считается восьмеричным числом, в противном случае — символьной маской, аналогичной используемой в команде chmod. Если параметр mode не указан, выводится текущее значение маски. Если задана опция -S без аргумента, маска выводится в символьном формате. Если задана опция -p, а параметр mode не указан, маска выводится в форме, пригодной для ввода. При изменении маски или отсутствии параметра mode команда возвращает 0.

Отметим, что при задании маски восьмеричным числом каждая цифра маски вычитается из 7, т. е. маска 022 задает режим доступа к файлу 755.

unset

unset [-fnv] [name]

Удаляет каждую переменную или функцию с именем name. При наличии опции -v удаляются переменные оболочки с соответствующим именем, опция -f задает удаление определений функций оболочки. Если задана опция -n, а name является переменной с атрибутом nameref, будет сбрасываться name, а не переменная, которую указывает name. Опция -n не работает вместе с -f. Если опций не задано, каждое значение name указывает переменную, а если такой переменной нет, сбрасывается функция с именем name. Доступные лишь для чтения переменные и функции не могут быть сброшены командой unset. Команда возвращает 0, если не было попытки сбросить доступный лишь для чтения элемент.

4.2. Внутренние команды bash

В этом разделе описаны внутренние команды, которые уникальны для Bash или были расширены в этой оболочке. Некоторые из этих команд относятся к стандарту POSIX.

alias

alias [-p] [name[=value] ...]

Без аргументов или с опцией -p команда alias печатает список псевдонимов на стандартном устройстве вывода в форме, подходящей для ввода в другие команды. При наличии аргументов определяется псевдоним для каждого параметра name, значение которого указано. Если значение не задано, выводится name и value имеющегося псевдонима. Псевдонимы описаны в разделе 6.6. Псевдонимы

bind

bind [-m keymap] [-lpsvPSVX]
bind [-m keymap] [-q function] [-u function] [-r keyseq]
bind [-m keymap] -f filename
bind [-m keymap] -x keyseq:shell-command
bind [-m keymap] keyseq:function-name
bind [-m keymap] keyseq:readline-command

Выводит текущие привязки ключей и функций Readline (8. Редактирование командной строки), привязывает последовательность-ключ к функции или макросу Readline или устанавливает переменную Readline. Каждый аргумент, не являющийся опцией, служит командой в том виде, как она указана в файле инициализации Readline (8.3. Файл инициализации Readline), но каждая привязка или команда должна передаваться как отдельный аргумент, например, ‘»\C-x\C-r»:re-read-init-file’. Значение опций описано ниже.

-m keymap

Задает использование keymap в качестве раскладки, на которую будут влиять последующие привязки. Пригодными именами привязок являются emacs, emacs-standard, emacs-meta, emacs-ctlx, vi, vi-move, vi-command, vi-insert. Привязка vi эквивалентна vi-command (vi-move также является синонимом), emacs эквивалентна emacs-standard.

-l

Список имен всех функций Readline.

-p

Выводит имена функций Readline и привязки в форме, пригодной для ввода или файла инициализации Readline.

-P

Выводит имена функций Readline и привязки.

-v

Выводит имена и значения переменных Readline в форме, пригодной для ввода или файла инициализации Readline.

-V

Выводит имена и значения переменных Readline.

-s

Выводит последовательности нажатия клавиш Readline, привязанные к макросам и строкам вывода в форме, пригодной для ввода или файла инициализации Readline.

-S

Выводит последовательности нажатия клавиш Readline, привязанные к макросам и строкам вывода.

-f filename

Считывает привязки клавиш из файла.

-q function

Запрос клавиш вызова указанной функции.

-u function

Отвязка всех клавиш для указанной функции.

-r keyseq

Удаление всех текущих привязок для keyseq.

-x keyseq:shell-command

Вызывает выполнение shell-command при вводе keyseq. При выполнении команды оболочка устанавливает в переменной READLINE_LINE текущее содержимое буфера строк Readline, а в READLINE_POINT — текущую точку вставки. Если выполненная команда изменила значение READLINE_LINE или READLINE_POINT, новые значения будут отражены в состоянии редактирования.

-X

Выводит все последовательности клавиш, привязанные к командам оболочки в пригодном для ввода формате.

Команда возвращает статус 0, если не было ошибок или непригодных опций.

builtin

builtin [shell-builtin [args]]

Запускает внутреннюю команду оболочки, передавая ей аргументы и возвращая статус завершения. Это полезно при определении функции оболочки, имя которой совпадает со внутренней командой, для сохранения функциональности команды внутри функции. Статус возврата будет ненулевым, если параметр shell-builtin не задает внутреннюю команду оболочки.

caller

caller [expr]

Возвращает контекст любого активного вызова подпрограммы (функции оболочки или сценария, выполняемого со внутренней командой . или source).

При запуске без параметра expr вызывающая сторона выводит номер строки и имя файла для текущего вызова подпрограммы. Если expr содержит неотрицательное целое число, выводится номер строки, имя подпрограммы и файл, соответствующие данной позиции в стеке вызовов. Эта информация может применяться, например, для вывода трассировки стека. Текущим является кадр 0.

Команда возвращает статус отличный от 0, если оболочка не выполняет вызов подпрограммы или expr не соответствует действительной позиции в стеке вызовов.

command

command [-pVv] command [arguments ...]

Запускает команду command с аргументами arguments, игнорируя функцию оболочки с именем command. Выполняются лишь внутренние команды и команды, найденные по пути PATH. Т. е. при наличии функции ls команда command ls внутри этой функции будет выполнять внешнюю команду ls, а не вызывать функцию рекурсивно. Опция -p задает использование принятого по умолчанию значения PATH, обеспечивающего нахождение всех стандартных утилит. Статус возврата в этом случае будет 127, если command не удается найти или возникает ошибка. В остальных случаях возвращается статус выхода command.

При наличии опции -V или -v выводится описание command. Опция -v обеспечивает вывод одного слова, указывающего команду, а -V дает более подробный вывод. В этом случае статус возврата будет 0, если команда найдена.

declare

declare [-aAfFgilnrtux] [-p] [name[=value] ...]

Объявляет переменные и задает их атрибуты. Если параметров name не задано, команда выводит значения переменных.

Опция -p задает вывод значений и атрибутов для каждого параметра name. При использовании -p с аргументами name все другие опции, за исключением -f и -F, игнорируются. При указании опции -p без name будут выводиться значения и атрибуты переменных, имеющих атрибуты, заданные другими опциями. Если других опций нет, -p обеспечивает вывод значений и атрибутов всех переменных оболочки. Опция -f ограничивает вывод shell-функциями.

Опция -F предотвращает вывод определений функций и печатаются лишь имена и атрибуты. Если включена опция extdebug с помощью внутренней команды shopt (4.3.2. Внутренняя команда shopt), будут также выводиться имена файлов и номера строк, где определена каждая переменная name. Опция -F подразумевает наличие -f. Опция -g задает создание и изменение переменных в глобальном масштабе даже при выполнении declare из функции оболочки. В других случаях опция игнорируется.

Ниже приведен список опций, которые могут служить для ограничения числа выводимых переменных.

-a

Каждое имя, являющееся переменной индексированного массива (6.7. Массивы).

-A

Каждое имя, являющееся переменной ассоциативного массива (6.7. Массивы).

-f

Только имена функций.

-i

Переменная трактуется как целое число, при установке значения выполняются арифметические преобразования (6.5. Арифметика командного процессора).

-l

При установке значения символы верхнего регистра переводятся в нижний. Атрибут upper-case отключен.

-n

Задает для каждой переменной name атрибут nameref, делая ее ссылкой на другую переменную. Эта переменная указывается значение value для name. Все ссылки, назначения и изменения атрибутов name, кроме использующих или меняющих сам атрибут -n, выполняются для переменной, указанной value. Атрибут nameref не применим к переменным массивов.

-r

Делает переменные name доступными лишь для чтения. Этим переменным не могут быть присвоены или сброшены значения в последующих операторах или командах unset.

-t

Задает для каждого name атрибут trace. Трассируемые функции наследуют ловушки DEBUG и RETURN из вызывающей оболочки. Атрибут trace не имеет специального значения для переменных.

-u

При установке значения символы нижнего регистра переводятся в верхний. Атрибут lower-case отключен.

-x

Помечает каждую переменную name для экспорта в последующие команды через окружение.

Использование + вместо — отключает атрибут, за исключением того, что +a и +A не могут использоваться для уничтожения переменных массива, а +r не будет удалять атрибут readonly. При использовании в функции команда declare делает каждое имя name локальным как при использовании команды local, за исключением случаев наличия опции -g. Если за name следует =value, для переменной устанавливается значение value.

При использовании -a или -A и синтаксиса составного назначения для создания переменных массивов дополнительные атрибуты не будут работать до последующих назначений. Статусом возврата будет 0, если нет непригодных опций, попыток определить функцию с помощью -f foo=bar, попыток задать значение доступной лишь для чтения переменной, попыток назначить значения переменной массива без использования синтаксиса составного назначения (6.7. Массивы), указания в name недействительной переменной оболочки, попыток отключить статус readonly для переменной readonly, попыток отключить статус массива для переменной массива или попыток вывести несуществующую функцию с помощью опции -f.

echo

echo [-neE] [arg ...]

Выводит аргументы (arg), разделенные пробелами и завершающиеся символом новой строки. Статус возврата имеет значение 0, если не возникло ошибок. При наличии опции -n символ newline в конце строки подавляется. Опция -e включает \-экранирование последующих символов. Опция -E отключает экранирование символов даже в системах, где оно включено по умолчанию. Опция оболочки xpg_echo может служить для динамического управления преобразованием экранируемых символов в эхо-строке. Команда echo не интерпретирует последовательность — (конец опций).

Интерпретируемые командой echo escape-последовательности приведены ниже.

\a

Сигнал (звонок).

\b

«Забой» (backspace).

\c

Подавление последующего вывода.

\e
\E

Символ экранирования (не ANSI C).

\f

Перевод страницы (form feed).

\n

Новая строка.

\r

Возврат каретки.

\t

Горизонтальная табуляция.

\v

Вертикальная табуляция.

\\

Обратная дробная черта (\).

\0nnn

Восьмибитовый символ с восьмеричным кодом nnn (1-3 восьмеричных цифры).

\xHH

Восьмибитовый символ с шестнадцатеричным кодом HH (1-2 шестнадцатеричных цифры).

\uHHHH

Символ Unicode (ISO/IEC 10646) с шестнадцатеричным кодом HHHH (1-4 шестнадцатеричных цифры)

\UHHHHHHHH

Символ Unicode (ISO/IEC 10646) с шестнадцатеричным кодом HHHHHHHH (1-8 шестнадцатеричных цифр)

enable

enable [-a] [-dnps] [-f filename] [name ...]

Включает и отключает внутренние команды оболочки. Запрет внутренней команды позволяет использовать взамен одноименную внешнюю команду (файл) без указания полного пути, хотя обычно оболочка выбирает сначала внутреннюю команду. При указании опции -n заданные аргументами name команды отключаются. В противном случае команды name включаются. Например, для использования двоичного исполняемого файла test, доступного в пути $PATH, вместо внутренней функции можно использовать команду enable -n test.

Если задана опция -p или нет аргумента name, выводится список внутренних команд оболочки. При отсутствии других аргументов список будет включать все включенные внутренние команды оболочки. С опцией -a указывается включена команда или выключена.

Опция -f задает загрузку новой внутренней команды name из общего объекта filename в системе, поддерживающей динамическую загрузку. Опция -d удаляет внутреннюю команду, загруженную с -f.

Если опций не задано, выводится список внутренней команд оболочки. Опция -s ограничивает включение специальными внутренними командами POSIX. Если опции -s и -f указаны вместе, новая внутренняя команда становится специальной (4.4. Специальные внутренние команды).

Команда возвращает статус 0, пока name задает внутреннюю команду оболочки и при загрузке новой внутренней команды из общего объекта не возникает ошибки.

help

help [-dms] [pattern]

Выводит информацию о встроенных командах. Если задан аргумент pattern, будет выводиться подробная информация о всех командах , соответствующих шаблону. В остальных случаях выводится список внутренних команд. Опции команды описан ниже.

-d

Выводить краткое описание для каждого значения pattern.

-m

Выводить описание для каждого значения pattern в формате, похожем на вывод man.

-s

Выводить лишь краткий синтаксис применения для каждого значения pattern.

Команда возвращает статус 0, если хотя бы одна команда соответствует pattern.

let

let expression [expression ...]

Внутренняя команда let позволяет выполнять арифметические операции с переменными оболочки. Каждый аргумент expression преобразуется в соответствии с правилами раздела 6.5. Арифметика командного процессора. Если последнее преобразование дает 0, команда let возвращает статус 1, в остальных случаях возвращается 0.

local

local [option] name[=value] ...

Для каждого аргумента создается локальная переменная с именем name и значением value. Аргумент option может задавать любые опции, пригодные для команды declare. Команда local может применяться лишь в функциях, она делает переменную name видимой только в этой функции и ее потомках. Если указано имя -, набор параметров оболочки делается локальным для функции, где вызвана команда local. Опции оболочки, измененные внутри функции, восстанавливают свои значения при возврате из функции. Команда возвращает статус 0, пока она применяется внутри функции, значение name действительно и переменная name доступна для записи.

logout

logout [n]

Выход из оболочки login с возвратом родителю статуса n.

mapfile

mapfile [-d delim] [-n count] [-O origin] [-s count]
    [-t] [-u fd] [-C callback] [-c quantum] [array]

Читает строки в переменную индексированного массива со стандартного ввода или из файла с дескриптором fd, если задана опция -u. По умолчанию массив задан переменной MAPFILE. Опции команды описаны ниже.

-d

Первый символ аргумента delim служит разграничителем строк вместо символа newline. Если delim является пустой строкой, mapfile будет завершать строку при считывании символа NUL.

-n

Максимальное число копируемых строк (count). По умолчанию число строк не ограничено (0).

-O

Начинать заполнение массива с индекса origin (по умолчанию 0).

-s

Отбрасывать первые count прочитанных строк.

-t

Удалять символ delim (по умолчанию newline) в конце каждой строки.

-u

Читать строки из файла с дескриптором fd вместо стандартного ввода.

-C

Оценивать обратный вызов (callback) при считывании каждых quantum строк. Значение задает -c quantum.

-c

Задает число строк, считываемых между вызовами callback.

Если опция -C задана без указания -c, по умолчанию применяется quantum = 5000. При оценке обратного вызова ему представляется индекс назначаемого следующим элемента массива и строка для присвоения этому элементу как добавочные аргументы. Оценка callback выполняется после чтения строки но до назначения элемента массива.

Если в команде явно не указано значение origin, команда mapfile очищает массив перед присвоением значений.

Команда mapfile возвращает 0, если не заданы непригодные опции или их аргументы, массив корректен и допускает назначение, а также является индексированным.

printf

printf [-v var] format [arguments]

Записывает форматированные аргументы на стандартный вывод в соответствии с аргументом format. Опция -v задает присваивание значений переменной var вместо печати на стандартном устройстве вывода.

Аргумент format — строка символов, содержащая 3 типа объектов: обычные символы, которые просто копируются на стандартный вывод, escape-последовательности, которые преобразуются и копируются на стандартный вывод, а также спецификации формата, каждая из которых вызывает печать следующего аргумента. В дополнение к стандартным форматам printf(1) команда printf интерпретирует описанные ниже расширения.

%b

Заставляет printf преобразовывать escape-последовательности с \ в соответствующем аргументе, как это делается в echo -e (4.2. Внутренние команды bash).

%q

Заставляет printf выводить соответствующий аргумент в формате, пригодном для ввода.

%(datefmt)T

Заставляет printf выводить строку даты и времени, полученную с использованием datefmt как строки формата для strftime. Соответствующий аргумент является целым числом секунд с начала эпохи. Могут применяться два специальных значения аргумента: -1 представляет текущее время, -2 — время вызова оболочки. Если аргумент не задан, предполагается -1. Это расширяет обычное поведение printf.

Аргументы для нестроковых спецификаторов формата трактуются как константы языка C, за исключением того, что допускаются начальные знаки + и -, а в случае первого символа одинарных или двойных кавычек значением является ASCII-код следующего символа.

Аргумент format при необходимости применяется многократно для всех arguments. Если format требует больше arguments, чем представлено, дополнительные спецификации формата ведет себя как при представлении значения 0 или пустой строки. Команда возвращает статус 0 при успешном выполнении и отличное от нуля значение при отказе.

read

read [-ers] [-a aname] [-d delim] [-i text] [-n nchars]
    [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...]

Считывает одну строку со стандартного ввода или из файла с дескриптором fd, указанного в опции -u, выделяет слова, как описано в параграфе 3.5.7. Расщепление слов и назначает первое слово первой переменной name, второе — следующей и т. д. Если слов больше, чем аргументов name, оставшиеся слова и разделители между ними назначаются последнему аргументу name. Если слов меньше, чем аргументов name, соответствующим переменным name присваиваются пустые значения. Для разделения слов используются символы значения переменной IFS как при расщеплении слов (3.5.7. Расщепление слов). Символ \ может служить для отмены специальной трактовки следующего символа или для продолжения строки. Если аргументы name не указаны, считанная строка назначается переменной REPLY. Команда возвращает статус 0, если не было получен символ конца файла, не исчерпано время ожидания (в этом случае возвращается статус больше 128), не было ошибок при назначении переменных (например, попытка записи в переменную, доступную лишь для чтения) и не был указан непригодный дескриптор файла в опции -u.

Опции команды описаны ниже.

-a aname

Слова присваиваются последовательным элементам массива aname, начиная с индекса 0. Все элементы aname удаляются перед назначением. Аргументы name игнорируются.

-d delim

Первый символ delim используется для завершения строки ввода вместо newline. Если delim является пустым, чтение строки будет прерываться NUL-символом.

-e

Для получения строки используется команда Readline (8. Редактирование командной строки) с текущими (или принятыми по умолчанию, если редактирование строк еще не применялось) настройками, и принятого в Readline по умолчанию дополнения имен файлов.

-i text

Если для редактирования строк будет применяться Readline, текст помещается в буфер редактирования.

-n nchars

Команда read возвращает управление после считывания nchars символов, не ожидая ввода всей строки, но учитывает разделитель, если он встретился до считывания nchars символов.

-N nchars

Команда read возвращает управление после считывания в точности nchars символов, не ожидая ввода всей строки, если раньше не был получен символ EOF или истекло время ожидания. Ограничители не трактуются в качестве таковых и не приводят к возврату управления, пока не будет прочитано nchars символов. Результат не расщепляется по символам IFS, это делается для того, чтобы переменной назначался весь набор прочитанных символов (кроме \, как указано ниже).

-p prompt

Выводит приглашение без завершающего символа newline перед попыткой чтения ввода. Приглашение отображается лишь при вводе с терминала.

-r

Эта опция отменяет действие \ в качестве символа экранирования и он считается частью строки. В частности, \newline не используется как продолжение строки.

-s

«Тихий» режим. При вводе символов с терминала они не выводятся на экране.

-t timeout

Задает считывание по времени и возвращает отказ, если строка (или заданное число символов) не была считана за timeout секунд. Аргумент timeout может быть десятичным числом с дробной частью, отделенной точкой. Эта опция действует лишь при чтении с терминала, из канала или иного специального файла, но не действует при чтении из обычного файла. При возникновении тайм-аута считанные данные сохраняются в переменной, заданной параметром name. Если timeout = 0, время команда завершает работу сразу, без попытки считывания данных. Команда возвращает статус 0, если данные доступны в указанном дескрипторе файла. При тайм-ауте возвращается значение больше 128.

-u fd

Чтение данных из файла с дескриптором fd.

readarray

readarray [-d delim] [-n count] [-O origin] [-s count]
    [-t] [-u fd] [-C callback] [-c quantum] [array]

Читает строки в переменную индексированного массива со стандартного ввода или из файла с дескриптором fd, если задана опция -u.

Синоним mapfile.

source

source filename

Синоним команды . (4.1. Внутренние элементы Bourne Shell).

type

type [-afptP] [name ...]

Для каждого аргумента name указывает способ интерпретации при использовании как имени команды.

При указании опции -t команда type выводит одно слово, которое задает псевдоним, функцию, внутреннюю команду, файл или ключевое слово, соответствующее аргументу name. Если соответствующего name элемента не найдено, ничего не выводится и возвращается статус отказа.

Опция -p option задает вывод имени дискового файла, который будет выполнен, или ничего, если -t не будет возвращать файл. Опция -P задает поиск в пути для каждого name, даже если -t не будет возвращать файл. Если команда хэширована, опции -p и -P будут выводить хэшированное имя, которое не обязательно соответствует первому файлу, найденному в $PATH.

При указании опции -a команда type возвращает все полные пути к исполняемым файлам name. При отсутствии опции -p будут выведены также псевдонимы и функции.

При указании опции -f команда type не пытается найти функции оболочки.

Статусом возврата будет 0, если найдены все name.

typeset

typeset [-afFgrxilnrtux] [-p] [name[=value] ...]

Команда typeset поддерживается для совместимости в оболочкой Korn и является синонимом внутренней команды declare.

ulimit

ulimit [-HSabcdefiklmnpqrstuvxPT] [limit]

Команда ulimit обеспечивает контроль ресурсов, доступных запускаемому оболочкой процессу, в системах, поддерживающих такой контроль. Опции команды описаны ниже.

-S

Изменение и отчет о мягком ограничении, связанном с ресурсом.

-H

Изменение и отчет о жестком ограничении, связанном с ресурсом.

-a

Вывод всех установленных ограничений.

-b

Максимальный размер буфера сокетов.

-c

Максимальный размер создаваемых core-файлов.

-d

Максимальный размер сегмента данных процесса.

-e

Максимальный приоритет при планировании (nice).

-f

Максимальный размер файлов, записываемых оболочкой и ее потомками.

-i

Максимальное число ожидающих сигналов.

-k

Максимальное число выделяемых очередей kqueue.

-l

Максимальный размер блокируемой памяти.

-m

Максимальный размер резидентного блока (многие системы не соблюдают это ограничение).

-n

Максимальное число дескрипторов открытых файлов (большинство систем не поддерживает это ограничение).

-p

Размер буфера канала (pipe).

-q

Максимальное число байтов в очереди сообщений POSIX.

-r

Максимальный приоритет при планировании в реальном масштабе времени.

-s

Максимальный размер стека.

-t

Максимальное время процессора в секундах.

-u

Максимальное число процессов для одного пользователя.

-v

Максимальный объем виртуальной памяти, доступной оболочке (на некоторых системах также потомкам).

-x

Максимальное число файловых блокировок.

-P

Максимальное число псевдотерминалов.

-T

Максимальное число потоков (thread).

Если аргумент limit задан и опция -a не используется, команда устанавливает новое ограничение для указанного ресурса. Специальные значения hard, soft и unlimited указывают текущие значения жестких и мягких ограничений или отсутствие ограничений. Жесткий предел не может быть увеличен пользователем (кроме root), а мягкий предел может быть увеличен до значения не более жесткого предела.

В остальных случаях выводится текущее мягкое ограничение для ресурса, если не задана опция -H. При установке новых ограничений и отсутствии опции -H или -S задается сразу мягкий и жесткий предел. Если опции не заданы, предполагается -f. Значения увеличиваются с шагом 1024 байта, за исключением -t (секунды), -p (блоки по 512 байтов), -P, -T, -b, -k, -n и -u (произвольные), а в режиме POSIX (6.11. Режим POSIX) -c и -f (блоки по 512 байтов).

Команда возвращает отличный от 0 статус, если указана непригодная опция или аргумент, а также при возникновении ошибки в случае установки ограничения.

unalias

unalias [-a] [name ... ]

Удаляет name из списка псевдонимов. Опция -a задает удаление всех псевдонимов.

4.3. Изменение поведения оболочки

4.3.1. Внутренняя команда set

Эта команда весьма сложна и заслуживает отдельного рассмотрения. Команда позволяет менять значения параметров оболочки, устанавливать позиционные параметры, выводить имена и значения переменных среды.

set [--abefhkmnptuvxBCEHPT] [-o option-name] [argument ...]
set [+abefhkmnptuvxBCEHPT] [+o option-name] [argument ...]

При отсутствии опций и аргументов команда set выводит имена и значения всех переменных оболочки и функций с сортировкой в соответствии с текущим языком (locale) в формате, пригодном в качестве ввода для установки или сброса уже установленных переменных. Переменные с доступом только для чтения не могут быть сброшены. В режиме POSIX выводятся лишь переменные оболочки.

Опции командной строки служат для установки или сброса атрибутов оболочки. Описание опций приведено ниже.

-a

Каждой переменной или функции, которая создается или изменяется, назначается атрибут экспорта и она помечается для экспорта в среду последующих команд.

-b

Задает незамедлительный возврат статуса прерванных фоновых заданий вместо вывода перед следующим основным приглашением.

-e

Немедленно завершить работу, если конвейер (3.2.2. Конвейеры), который может включать одну простую команду (3.2.1. Простые команды), список (3.2.3. Списки ) или составную команду (3.2.4. Составные команды), возвращает отличный от 0 статус. Работа оболочки не завершается, если вызвавшая отказ команда является частью списка, следующего сразу после ключевого слова while или until, частью проверочного выражения в операторе if, частью любой команды, выполняемой в списке && или || (кроме последней в списке), любой командой в конвейере (кроме последней) или статус возврата команды инвертируется оператором !. Если составная команда, не являющаяся субоболочкой, возвращает ненулевой статус в результате отказа при игнорировании опции -e, работа оболочки не завершается. Если установлено прерывание ERR, оно выполняется перед завершением работы оболочки. Эта опция применяется раздельно к среде оболочки и каждой субоболочки (3.7.3. Среда выполнения команды) и может приводить к завершению работы субоболочки до выполнения в ней всех команд.

Если составная команда или shell-функция выполняется в контексте, где опция -e не принимается во внимание, ни одна из команд, выполняемых внутри составной команды или в теле функции, не будет зависеть от опции -e даже при ее наличии и возврате командой отказа. Если составная команда или функция оболочки задает опцию -e в контексте, где эта опция игнорируется, эта установка не будет оказывать влияния, пока не завершится составная команда или команда, включающая функцию.

-f

Отключает преобразование имен файлов (globbing).

-h

Поиск и запоминание (хэш) команд, которые отыскивались для выполнения (включено по умолчанию).

-k

Все параметры в форме операторов присваивания помещаются в среду для команды в дополнение к параметрам перед именем команды.

-m

Управление заданиями включено (7. Управление заданиями). Все процессы работают в отдельной группе. По завершении фонового задания оболочка выводит строку со статусом завершения.

-n

задает чтение команд без их выполнения. Это можно применять для проверки сценариев на предмет ошибок. Опция игнорируется в интерактивной оболочке.

-o option-name

Задает опцию, соответствующую option-name.

allexport

Совпадает с -a.

braceexpand

Совпадает с -B.

emacs

Задает использование интерфейса редактирования командной строки в стиле emacs (8. Редактирование командной строки). Влияет также на интерфейс редактирования для read -e.

errexit

Совпадает с -e.

errtrace

Совпадает с -E.

functrace

Совпадает с -T.

hashall

Совпадает с -h.

histexpand

Совпадает с -H.

history

Включает историю команд, как описано в разделе 9.1. Средства Bash History. Опция включена по умолчанию в интерактивных оболочках.

ignoreeof

Интерактивная оболочка не будет завершать работу при считывании EOF.

Keyword

Совпадает с -k.

monitor

Совпадает с -m.

noclobber

Совпадает с -C.

noexec

Совпадает с -n.

noglob

Совпадает с -f.

nolog

А настоящее время игнорируется.

notify

Совпадает с -b.

nounset

Совпадает с -u.

onecmd

Совпадает с -t.

physical

Совпадает с -P.

pipefail

При установке возвращаемым значением конвейера будет значение статуса последней (самой правой) команды или 0, если все команды выполнены успешно. Опция по умолчанию отключена.

posix

Меняет поведение Bash, если принятые по умолчанию установки отличаются от стандарта POSIX, в соответствии с этим стандартом (6.11. Режим POSIX). Опция предназначена для обеспечения поведения Bash в строгом соответствии с надмножеством этого стандарта.

privileged

Совпадает с -p.

verbose

Совпадает с -v.

vi

Задает использование стиля vi при редактировании строк. Влияет также на интерфейс редактирования команды read -e.

xtrace

Совпадает с -x.

-p

Включает привилегированный режим, в котором файлы $BASH_ENV и $ENV не обрабатываются, функции оболочки не наследуются из среды, а переменные SHELLOPTS, BASHOPTS, CDPATH и GLOBIGNORE, при наличии их в окружении, игнорируются. Если оболочка запущена с действующим идентификатором пользователя (группы), отличным от идентификатора реального пользователя (группы), а опция -p не задана, эти действия выполняются и для действующего идентификатора пользователя устанавливается идентификатор реального пользователя. Если опция -p указана при запуске, идентификатор пользователя не меняется. Выключение этой опции ведет к установке действующих идентификаторов пользователя и группы в соответствии с реальными.

-t

Выход после считывания и выполнения одной команды.

-u

Задает трактовку неустановленных переменных и параметров (кроме @ и *) как ошибку при преобразовании параметров. Сообщение об ошибке отображается на стандартном устройстве вывода и работа неинтерактивной оболочки завершается.

-v

Выводит входные строки оболочки по мере их чтения.

-x

Выводит трассировку простых команд для команд, команд case и select, а также арифметики для команд и аргументов или связанных списков слов после преобразования, но до выполнения. Значение переменной PS4 преобразуется и выводится результат перед командой и ее преобразованными аргументами.

-B

Оболочка выполняет раскрытие скобок (3.5.1. Раскрытие скобок). Опция включена по умолчанию.

-C

Предотвращает переписывание имеющихся файлов при перенаправлении вывода с использованием >, >&, и <>.

-E

При установке опции все прерывания (trap) в ERR наследуются функциями оболочки, подстановками команд и командами, выполняемыми в среде субоболочки. Обычно прерывания ERR в таких случаях не наследуется.

-H

Включает стиль ! в подстановке истории (9.3. Преобразование истории). Опция включена по умолчанию для интерактивных оболочек.

-P

Установленная опция отключает преобразование символьных ссылок при выполнении команд, меняющих текущий каталог (таких как cd). Вместо этого будет использоваться реальный каталог. По умолчанию Bash следует логической цепочке каталогов при выполнении команд, меняющих текущий каталог.

Например, если /usr/sys является символьной ссылкой на /usr/local/sys

$ cd /usr/sys; echo $PWD
/usr/sys
$ cd ..; pwd
/usr

При установке опции -P

$ cd /usr/sys; echo $PWD
/usr/local/sys
$ cd ..; pwd
/usr/local

-T

При установленной опции любые прерывания в DEBUG и RETURN наследуются функциями оболочки, подстановками команд и командами, выполняемыми в среде субоболочки. Обычно прерывания DEBUG и RETURN в таких случаях не наследуется.

Если за этой опцией не следует аргумент, позиционные параметры не устанавливаются. В противном случае позиционные параметры устанавливаются в соответствии со значениями аргументов, даже если некоторые из них начинаются с символа -.

Указывает завершение опции и назначение оставшихся аргументов позиционным параметрам. Опции -x и -v выключаются. Если аргументов нет, позиционные параметры не меняются.

Использование символа + вместо — отключает соответствующую опцию. Опции могут также применяться при вызове оболочки. Текущий набор опций хранится в переменной $-.

Оставшиеся N аргументов являются позиционными параметрами $1, $2, . . . $N. Для специального параметра # устанавливается значение N.

Команда всегда возвращает статус 0, если не задана недействительная опция.

4.3.2. Внутренняя команда shopt

Эта команда позволяет изменить необязательное поведение оболочки.

shopt [-pqsu] [-o] [optname ...]

Команда меняет значения, контролирующие поведение дополнительной оболочки. Это могут быть перечисленные ниже параметры или (при использовании опции -o) параметры, доступные с опцией -o внутренней команде set (4.3.1. Внутренняя команда set). При вызове без опций или с опцией -p команда выводит список всех доступных для установки опций с индикацией уже установленных. Если при этом задан параметр optname, вывод ограничивается указанными опциями. Опция -p обеспечивает вывод в форме, которая может использоваться в качестве входных данных.

-s

Включает (set) каждую опцию из optname.

-u

Выключает (unset) каждую опцию из optname.

-q

Подавляет обычный вывод. Статус возврата указывает были опция optname установлена или сброшена. При наличии нескольких аргументов optname с опцией -q статус возврата будет 0, если установлены все optname.

-o

Ограничивает значения optname заданными для опции -o внутренней команды set (4.3.1. Внутренняя команда set).

Если опция -s или -u используется без аргумента optname, команда shopt показывает лишь установленные или сброшенные опции, соответственно.

Если явно не указано иное, опции shopt по умолчанию отключены.

Статусом возврата при просмотре опций является 0, если все опции из optname включены и отличное от 0 значение в противном случае. При установке или сбросе опций возвращается статус 0, если optname указывает действительную опцию оболочки.

assoc_expand_once

При установке опции оболочка подавляет многократное вычисление индексов ассоциативных массивов в процессе вычисления арифметических выражений при выполнении внутренних команд, которые могут назначать переменные и разыменовывать массивы.

autocd

При установке этой опции команда, являющаяся именем каталога, будет восприниматься как аргумент команды cd. Опция может применяться лишь в интерактивных оболочках.

cdable_vars

При установленной опции аргумент внутренней команды cd, не являющийся каталогом, считается именем переменной, значение которой задает каталог для перехода.

cdspell

При включенной опции незначительные ошибки при указании каталога в команде cd будут исправляться. Проверяется перестановка символов, пропуски и избыточные символы. Если исправление найдено, выводится корректный путь и команда выполняется. Опция применяется только в интерактивных оболочках.

checkhash

При установке опции Bash проверяет наличие команды, найденной в хэш-таблице, перед попыткой ее выполнения. Если хэшированной команды больше не существует, выполняется обычный поиск в заданных путях.

checkjobs

При установке опции Bash выводит состояния всех остановленных и работающих заданий, имеющихся в интерактивной оболочке. Если какие-то задания выполняются, это откладывает выход до второй попытки выхода без промежуточной команды (7. Управление заданиями). Оболочка всегда откладывает завершение при наличии остановленных заданий.

checkwinsize

При установленной опции Bash проверяет размер терминального окна после каждой внешней команды и при необходимости обновляет значения LINES и COLUMNS. По умолчанию опция включена.

cmdhist

При установленной опции Bash пытается сохранить все строки многострочной команды в одной записи истории. Это позволяет впоследствии редактировать такие команды. Опция включена по умолчанию, но работает лишь при включенной истории команд (9.1. Средства Bash History).

compat31

При установленной опции Bash меняет свое поведение в соответствии с версией 3.1 применительно к аргументам в кавычках для оператора условных команд =~ и зависимого от языка сравнения строк при использовании команды [[ с операторами < и >. Версии до bash-4.1 используют сортировку ASCII и strcmp(3), а bash-4.1 и более поздние версии используют сортировку установленного языка и strcoll(3).

compat32

При установленной опции Bash меняет свое поведение в соответствии с версией 3.2 применительно к сравнению строк на основе языка (locale) в операторах < и > условных команд [[ и прерыванию списка команд. В Bash версий 3.2 и меньше выполнялся переход к следующей команде в списке после завершения команды прерыванием.

compat40

При установленной опции Bash меняет свое поведение в соответствии с версией 4.0 применительно к сравнению строк на основе языка (locale) в операторах < и > условных команд [[ и прерыванию списка команд. В Bash версий 4.0 и выше список прерывается как при получении прерывания оболочкой, а в более ранних продолжается со следующей командой из списка.

compat41

При установленной опции Bash в режиме POSIX трактует одинарные кавычки при преобразовании параметров в двойных кавычках как специальный символ. Одинарные кавычки должны быть парными, а символы между ними считаются заключенными в кавычки. Это поведение относится к режиму POSIX до версии 4.1. По умолчанию Bash ведет себя как в предшествующих версиях.

compat42

При установленной опции Bash не обрабатывает строку замены в преобразовании слова подстановки шаблона с использованием удаления кавычек.

compat43

При установленной опции Bash не выводит предупреждения при попытке использовать в качестве аргумента заключенное в кавычки назначение составного массива, считает ошибки преобразования слов не критическими (по умолчанию они являются критическими и ведут к завершению работы оболочки) и не сбрасывает состояние цикла при выполнении функции оболочки (это позволяет прервать или продолжить цикл в функции оболочки для воздействия на цикл в контексте вызывающего элемента).

compat44

При установленной опции Bash сохраняет позиционные параметры в переменных BASH_ARGV и BASH_ARGC до их использования, независимо от включения режима расширенной отладки.

complete_fullquote

При установленной опции Bash заключает в кавычки все метасимволы в именах файлов и каталогов при дополнении. Если опция не задана, Bash удаляет метасимволы, такие как $, из числа помещаемых в кавычки в дополненных именах файлов, когда эти метасимволы появляются в ссылках на переменные оболочки в словах, которые нужно дополнить. Это означает, что символ $ в именах переменных, которые преобразуются в каталоги, не будет заключаться в кавычки, однако он не будет заключаться в кавычки и в именах файлов. Это действует лишь в тех случаях, когда bash использует символ \ для дополненных имен файлов. Опция установлена по умолчанию, что соответствует принятому по умолчанию поведению Bash до версии 4.2.

direxpand

При установленной опции Bash заменяет имена каталогов результатами преобразования слов при дополнении имен файлов. Это меняет содержимое буфера редактирования readline. Если опция не задана, Bash пытается сохранить пользовательский ввод.

dirspell

При установленной опции Bash пытается корректировать имена каталогов при дополнении, если заданного пользователем каталога не существует.

dotglob

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

execfail

При установленной опции неинтерактивная оболочка не будет завершаться при невозможности выполнить файл, указанный как аргумент внутренней команды exec. Интерактивная оболочка не завершается при отказах exec.

expand_aliases

При установленной опции псевдонимы преобразуются в соответствии с разделом 6.6. Псевдонимы. Эта опция по умолчанию включена для интерактивной оболочки.

extdebug

Если опция установлена при вызове оболочки, организуется выполнение профиля отладчика до запуска оболочки как при указании опции —debugger. При установке опции после вызова оболочки, включается поведение, предназначенное для отладчиков, как описано ниже.

  1. Опция -F внутренней команды declare (4.2. Внутренние команды bash) выводит имя файла с исходным кодом и номер строки, соответствующие каждому имени функции, заданному в качестве аргумента.
  2. Если команда, запускаемая прерыванием DEBUG, возвращает отличный от 0 статус, следующая команда пропускается.
  3. Если команда, запускаемая прерыванием DEBUG, возвращает 2 и оболочка выполняется в подпрограмме (функция оболочки или сценарий, запущенный с помощью . или source), имитируется вызов return.
  4. Переменные BASH_ARGC и BASH_ARGV обновляются, как указано в параграфе 5.2. Переменные Bash.
  5. Трассировка функций включена, подстановка команд, функции оболочки и субоболочки, вызываемые с помощью ( command ), наследуют ловушки DEBUG и RETURN.
  6. Трассировка ошибок включена, подстановка команд, функции оболочки и субоболочки, вызываемые с помощью ( command ), наследуют ловушку ERR.

extglob

Опция включает функции расширенного сопоставления с шаблонами (3.5.8.1. Сопоставление с шаблоном).

extquote

Включает поддержку кавычек $’string’ и $»string» в преобразовании выражений ${parameter}. По умолчанию включена.

failglob

При включенной опции отсутствие совпадений с шаблоном при преобразовании имен файлов ведет к ошибке.

force_fignore

При включенной опции суффиксы, заданные переменной оболочки FIGNORE (5.2. Переменные Bash), ведут к игнорированию слов при дополнении, даже когда игнорируемое слово является единственным вариантом дополнения. Опция включена по умолчанию.

globasciiranges

При включенной опции выражения диапазонов, используемые в выражениях сопоставления с шаблоном, содержащих скобки (3.5.8.1. Сопоставление с шаблоном), ведут себя как при сравнении с традиционной языковой установкой C. Т. е. порядок символов текущей языковой установки не принимается во внимание и символы верхнего и нижнего регистра ASCII будут сравниваться вместе.

globstar

При включенной опции шаблон ** в контексте преобразования имен файлов будет соответствовать всем файлам, а также каталогам и подкаталогам. Если за шаблоном следует символ /, соответствовать будут лишь (под)каталоги.

gnu_errfmt

При включенной опции сообщения оболочки об ошибках выводятся в стандартном формате сообщений gnu.

histappend

При включенной опции список истории добавляется в конец файла, указанного значением переменной HISTFILE, вместо переписывания файла при выходе из оболочки.

histreedit

При включенной опции и использовании Readline пользователь может повторно редактировать неудачную подстановку истории.

histverify

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

hostcomplete

При включенной опции и использовании Readline интерпретатор Bash будет пытаться дополнять имя хоста, когда при дополняется слово с символом @ (8.4.6. Завершение строк из Readline). Опция включена по умолчанию.

huponexit

При включенной опции Bash будет передавать сигнал SIGHUP всем заданиям при выходе из интерактивной (login) оболочки (3.7.6. Сигналы).

inherit_errexit

При включенной опции подстановка команд наследует опцию errexit вместо ее сброса в среде субоболочки. Опция включена в режиме POSIX.

interactive_comments

Позволяет интерактивной оболочке игнорировать содержимое строки, начиная с символа # и до конца строки (включена по умолчанию).

lastpipe

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

lithist

Если опция включена вместе с опцией cmdhist, многострочные команды сохраняются в списке истории с символами новой строки вместо ;.

localvar_inherit

При включенной опции локальные переменные наследуют значения и атрибуты одноименных переменных из предыдущей области действия до присвоения новых значений. Атрибут nameref не наследуется.

localvar_unset

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

login_shell

Оболочка устанавливает эту опцию при запуске в режиме входа в систему — login (6.1. Вызов Bash). Изменить значение невозможно.

mailwarn

При включенной опции выводится сообщение «The mail in mailfile has been read», если к файлу, который Bash проверяет на предмет почты, было обращение с момента последней проверки.

no_empty_cmd_completion

При включенной опции и использовании Readline оболочка Bash не пытается искать в PATH возможные дополнения при попытке дополнения пустой строки.

nocaseglob

При включенной опции Bash сопоставляет имена файлов без учета регистра символов для преобразования имен.

nocasematch

При включенной опции Bash сравнивает шаблон без учета регистра символов при сопоставлении во время выполнения условных команд case или [[ conditional, при подстановке шаблонов в преобразовании слов и при фильтрации возможных дополнений как части программируемого дополнения.

nullglob

При включенной опции Bash позволяет преобразование шаблонов имен, которым ничего не соответствует, в пустую строку, а не в себя.

progcomp

При включенной опции разрешены средства программируемого дополнения (8.6. Программируемое дополнение). Опция включена по умолчанию.

progcomp_alias

При включенной опции и включенном программируемом дополнении Bash трактует имя команды, не имеющее дополнения, как возможный псевдоним и пытается его преобразовать. Если это псевдоним, Bash пытается выполнить программируемое дополнение, используя слово команды из преобразованного псевдонима.

promptvars

При включенной опции строки приглашения подвергаются преобразованию параметров, подстановке команд, арифметическому преобразованию и удалению кавычек, как описано ниже (6.9. Управление формой приглашения). Опция включена по умолчанию.

restricted_shell

Оболочка устанавливает эту опцию при запуске в ограниченном режиме (6.10. Ограниченная оболочка). Изменить значение нельзя и оно не сбрасывается при выполнении стартовых файлов, что позволяет им обнаруживать ограниченный режим оболочки.

shift_verbose

При включенной опции внутренняя команда используется source использует переменную PATH для поиска каталога, содержащего файл, указанный как аргумент. Опция включена по умолчанию.

xpg_echo

При включенной опции внутренняя команда echo по умолчанию преобразует \-экранирование.

Статус возврата при перечислении параметров имеет значение 0, если все все имена опций (optname) включены и отличен от 0 в противном случае. При установке или сбросе опций статус возврата имеет значение 0, если опция действительна для оболочки.

4.4. Специальные внутренние команды

В силу исторических причин стандарт POSIX выделяет некоторые внутренние команды оболочки как специальные. При работе Bash в режиме POSIX специальные команды отличаются от прочих в 3 аспектах:

  1. при поиске специальные команды отыскиваются до функций оболочки;

  2. при возврате специальной внутренней функцией отличного от 0 статуса интерактивная оболочка завершается;

  3. предшествующие команде операторы назначения продолжают действовать в среде оболочки после выполнения команды.

При работе Bash не в режиме POSIX специальные внутренние команды ведут себя как обычные внутренние команды Bash. Режим Bash POSIX описан в разделе 6.11. Режим POSIX.

Специальные команды POSIX включают break, :, ., continue, eval, exec, exit, export, readonly, return, set, shift, trap, unset.

5. Переменные оболочки

В этом разделе описаны параметры оболочки, используемые Bash. Многим переменным Bash автоматически присваивает используемые по умолчанию значения.

5.1. Переменные Bourne Shell

Bash использует некоторые переменные оболочки так же, как это делает Bourne shell. В некоторых случаях Bash поддерживает для переменных заданные по умолчанию значения.

CDPATH

Разделенный двоеточиями список каталогов, используемых в качестве пути поиска внутренней команды cd.

HOME

Домашний каталог текущего пользователя. применяется по умолчанию внутренней командой cd без аргументов. Значение переменной также используется при преобразовании тильды (3.5.2. Преобразование тильды).

IFS

Список символов, служащих разделителями полей. Применяется при расщеплении слов в преобразованиях.

MAIL

Если этот параметр указывает файл или каталог и переменная MAILPATH не задана, Bash информирует пользователя о приходе почты в указанный файл или каталог в формате Maildir.

MAILPATH

Разделенный двоеточиями список файлов, которые оболочка периодически проверяет на предмет новых почтовых сообщений. Каждый элемент списка может задавать сообщение, выводимое при появлении новой почты в файле, которое указывается через ? после имени файла. При использовании в тексте сообщения символы $_ преобразуются в имя текущего файла почты.

OPTARG

Значение последнего аргумента опции, обработанного внутренней командой getopts.

OPTIND

Индекс последнего аргумента опции, обработанного внутренней командой getopts.

PATH

Разделенный двоеточиями список каталогов, которые оболочка просматривает в поиске команд. Пустое (null) имя в переменной PATH указывает текущий каталог и указывается двумя двоеточиями подряд или двоеточием в начале или в конце списка каталогов.

PS1

Строка основного приглашения (по умолчанию (‘\s-\v\$ ’). Полный список escape-последовательностей, преобразуемых перед выводом PS1, приведен в разделе 6.9. Управление формой приглашения.

PS2

Строка вторичного приглашения (по умолчанию ‘> ’), преобразуемого так же, как PS1 перед выводом.

5.2. Переменные Bash

Эти переменные устанавливаются и используются в Bash, но обычно не имеют значения в других оболочках. Некоторые переменные, используемые Bash описаны в разделе 7.3. Переменные управления заданиями.

BASH

Полный путь, использованный для запуска данного экземпляра Bash.

BASHOPTS

Список разделенных двоеточиями включенных опций оболочки. Каждое слово в этом списке является допустимым аргументом опции -s внутренней команды shopt (4.3.2. Внутренняя команда shopt). Опциями в BASHOPTS являются те, для которых shopt показывает значение on. Если эта переменная присутствовала в окружении при запуске Bash, каждая из опций списка будет включена до считывания каких-либо стартовых файлов. Переменная доступна лишь для чтения.

BASHPID

Выводит идентификатор текущего процесса Bash. Это отличается от $$ в некоторых случаях, таких как субоболочки, которым не требуется повторная инициализация Bash. Назначение BASHPID эффекта не дает. Если переменная сброшена, она теряет особые свойства даже в случае последующей переустановки.

BASH_ALIASES

Переменная ассоциативного массива, элементы которого соответствуют внутреннему списку псевдонимов, поддерживаемому внутренней командой alias (4.1. Внутренние элементы Bourne Shell). Добавляемые в массив элементы появляются в списке псевдонимов, однако их сброс (unset) в настоящее время не ведет к удалению из списка. Если переменная сброшена, она теряет особые свойства даже в случае последующей переустановки.

BASH_ARGC

Переменная массива, значения которого указывают число параметров в каждом кадре текущего стека вызовов при выполнении bash. На вершине стека находится число параметров текущей подпрограммы (shell-функции или сценария, выполняемого с . или source). Когда подпрограмма выполняется, число параметров передается в BASH_ARGC. Оболочка устанавливает BASH_ARGC только в режиме расширенной отладки (4.3.2. Внутренняя команда shopt). Установка extdebug после запуска оболочки для выполнения сценария или ссылка на эту переменную, когда extdebug не установлена, может давать несогласованный результат.

BASH_ARGV

Переменная массива, содержащая все параметры в текущем стеке вызовов исполнения bash. На вершине стека находится последний параметр последней подпрограммы, а первый параметр начального вызова находится на дне. При выполнении подпрограммы переданные ей параметры вталкиваются в BASH_ARGV. Оболочка устанавливает BASH_ARGV только в режиме расширенной отладки (4.3.2. Внутренняя команда shopt). Установка extdebug после запуска оболочки для выполнения сценария или ссылка на эту переменную, когда extdebug не установлена, может давать несогласованный результат.

BASH_ARGV0

При ссылке на эту переменную она преобразуется в имя оболочки или сценария оболочки (идентично $0, как описано в 3.4.2. Специальные параметры). Назначение BASH_ARGV0 вызывает присвоение этого же значения переменной $0. При сбросе BASH_ARGV0 переменная теряет свои особые свойства даже в случае переустановки.

BASH_CMDS

Переменная ассоциативного массива, элементы которого соответствуют внутренней хэш-таблице команд, поддерживаемой внутренней командой hash (4.1. Внутренние элементы Bourne Shell). Добавляемые в массив элементы появляются в хэш-таблице, однако сброс (unset) элемента массива не ведет к удалению имени команды из хэш-таблицы. При сбросе BASH_CMDS переменная теряет свои особые свойства даже в случае переустановки.

BASH_COMMAND

Команда, выполняемая или готовящаяся к выполнению в данный момент, если только оболочка не выполняет команду в результате прерывания (trap), когда это будет команда, выполнявшаяся в момент прерывания.

BASH_COMPAT

Значение, используемое для установки уровня совместимости оболочки (4.3.2. Внутренняя команда shopt). Значение может быть десятичным (например, 4.2) или целым (например, 42) числом, соответствующим желаемому уровню совместимости. Если переменная BASH_COMPAT сброшена или установлена пустая строка, для уровня совместимости устанавливается текущая версия. Если в BASH_COMPAT установлено значение, не являющееся одним из действительных уровней совместимости, оболочка выводит сообщение об ошибке и устанавливает для уровня совместимости текущую версию. Действительные уровни совместимости соответствуют опциям совместимости, воспринимаемым внутренней командой shopt (например, compat42 означает, что значения 4.2 и 42 являются действительными). Текущая версия также является пригодным значением.

BASH_ENV

Если эта переменная установлена при вызове Bash для выполнения shell-сценария, она преобразуется и используется как имя стартового файла, считываемого до выполнения сценария (6.2. Стартовые файлы Bash).

BASH_EXECUTION_STRING

Аргумент команды для опции вызова -c.

BASH_LINENO

Переменная массива, элементами которого являются номера строк в исходных файлах, где вызывается каждый соответствующий элемент FUNCNAME. ${BASH_LINENO[$i]} — номер строки в исходном файле (${BASH_SOURCE[$i+1]}), где была вызвана ${FUNCNAME[$i]} (или ${BASH_LINENO[$i-1]} при указании с другой shell-функцией). Для получения номера текущей строки используется LINENO.

BASH_LOADABLES_PATH

Список разделенных двоеточиями каталогов, которые оболочка просматривает в поиске динамически загружаемых внутренних команд, указанных командой enable.

BASH_REMATCH

Переменная массива, элементы которого назначены бинарным оператором =~ условной команды [[ (3.2.4.2. Конструкции с условием). Элемент с индексом 0 является частью строки, соответствующей всему регулярному выражению. Элемент с индексом n является частью строки, соответствующей n-му параметризованному субвыражению. Переменная доступна лишь для чтения.

BASH_SOURCE

Переменная массива, элементы которого являются именами исходных файлов, где определена соответствующая shell-функция, названная в массиве FUNCNAME. Функция оболочки ${FUNCNAME[$i]} определена в файле ${BASH_SOURCE[$i]} и вызывается из ${BASH_SOURCE[$i+1]}

BASH_SUBSHELL

Инкрементируется на 1 в каждой субоболочке или среде субоболочки, когда оболочка начинает выполняться в этой среде. Начальное значение равно 0.

BASH_VERSINFO

Доступный лишь для чтения массив (6.7. Массивы), элементы которого содержат данные о версии этого экземпляра Bash.

BASH_VERSINFO[0]

Старший номер версии (выпуск — release).

BASH_VERSINFO[1]

Младший номер версии (версия).

BASH_VERSINFO[2]

Уровень исправлений (patch level).

BASH_VERSINFO[3]

Версия сборки.

BASH_VERSINFO[4]

Статус выпуска (например, beta1).

BASH_VERSINFO[5]

Значение MACHTYPE.

BASH_VERSION

Номер версии текущего экземпляра Bash.

BASH_XTRACEFD

При установке целого значения, соответствующего действительному дескриптору файла, Bash будет записывать трассировку вывода, генерируемую при включении set -x для этого дескриптора. Это позволяет отделить вывод трассировки от диагностики и сообщений об ошибках. Дескриптор файла закрывается при сбросе или установке нового значения BASH_XTRACEFD. Сброс или назначение пустой строки BASH_XTRACEFD вызывают передачу трассировки на стандартный вывод ошибок. Установка BASH_XTRACEFD = 2 (стандартный вывод ошибок) и последующий сброс приводят к закрытию стандартного вывода ошибок.

CHILD_MAX

Задает число выходных дочерних состояний, запоминаемых оболочкой. Bash не позволяет снижать это значение меньше описанного ниже минимума, заданного POSIX, а также задан максимум (в настоящее время 8192). Минимальное значение зависит от системы.

COLUMNS

Используется командой select для определения ширины терминала при выводе списков выбора. При включенной опции checkwinsize (4.3.2. Внутренняя команда shopt) и в интерактивной оболочке при получении сигнала SIGWINCH устанавливается автоматически.

COMP_CWORD

Индекс в ${COMP_WORDS} слова, содержащего текущую позицию курсора. Переменная доступна лишь в функциях оболочки, вызываемых средствами программируемого дополнения (8.6. Программируемое дополнение).

COMP_LINE

Текущая строка команды, доступная лишь в функциях оболочки и внешних командах, вызываемых средствами программируемого дополнения (8.6. Программируемое дополнение).

COMP_POINT

Индекс текущей позиции курсора относительно начала текущей команды. Если курсор находится в конце команды, переменная имеет значение ${#COMP_LINE}. Переменная доступна лишь в функциях оболочки, вызываемых средствами программируемого дополнения (8.6. Программируемое дополнение).

COMP_TYPE

Целое число, соответствующее типу предпринятого дополнения, которое вызвало функцию завершения, — TAB для обычного завершения, ? Для списка завершений после последовательных нажатий TAB, ! Для списка вариантов при частичном завершении слова, @ для списка завершений если слово не изменено, % для завершения меню. Переменная доступна лишь в функциях оболочки, вызываемых средствами программируемого дополнения (8.6. Программируемое дополнение).

COMP_KEY

Клавиша (финальная клавиша или комбинация), используемая для вызова текущей функции завершения.

COMP_WORDBREAKS

Набор символов, трактуемых библиотекой Readline как разделители слов при дополнении слова. При сбросе переменной она теряет свои особые свойства даже после переустановки.

COMP_WORDS

Переменная массива, состоящая из отдельных слов текущей строки команды. Строка делится на слова, как ее будет расщеплять Readline, с использованием COMP_WORDBREAKS, как описано выше. Переменная доступна лишь в функциях оболочки, вызываемых средствами программируемого дополнения (8.6. Программируемое дополнение).

COMPREPLY

Переменная массива, из которой Bash считывает возможные дополнения, созданные shell-функцией, вызванной средством программируемого дополнения (8.6. Программируемое дополнение). Каждый элемент массива содержит одно возможное дополнение.

COPROC

Переменная массива, созданная для хранения дескрипторов файлов для ввода и вывода безымянных процессов (3.2.5. Копроцессы).

DIRSTACK

Переменная массива, содержащая текущий стек каталогов в порядке их отображения внутренней функцией dirs. Назначение элементов массива может служить для изменения включенных в стек каталогов, но для добавления и удаления должны применяться внутренние команды pushd и popd. Назначение этой переменной не меняет текущего каталога. При сбросе переменной она не восстанавливает особые свойства даже после переустановки.

EMACS

Если Bash находит эту переменную в среде при запуске оболочки со значением t, предполагается работа оболочки в буфере Emacs с запретом редактирования строк.

ENV

Похожа на BASH_ENV и применяется при вызове оболочки в режиме POSIX (6.11. Режим POSIX).

EPOCHREALTIME

При каждой ссылке на параметр он преобразуется в число секунд эпохи Unix, выраженное действительным значением с микросекундной точностью (см. описание библиотеки C). Назначение EPOCHREALTIME игнорируется. При сбросе переменной ее свойства не восстанавливаются даже после переустановки.

EPOCHSECONDS

При каждой ссылке на этот параметр он преобразуется в число секунд эпохи Unix (см. описание библиотеки C). Назначение EPOCHSECONDS игнорируется. При сбросе переменной она не восстанавливает особые свойства даже после переустановки.

EUID

Эффективный числовой идентификатор текущего пользователя, доступный лишь для чтения.

EXECIGNORE

Список разделенных двоеточиями шаблонов (3.5.8.1. Сопоставление с шаблоном), определяющий имена файлов при поиске с помощью команды search в PATH. Файлы, имена путей для которых полностью соответствуют одному из шаблонов, не считаются исполняемыми для дополнения и запуска команд через поиск в PATH. Это не влияет на поведение команд [, test и [[. Полные имена в хэш-таблице команд не учитываются EXECIGNORE. Переменную следует использовать для игнорирования файлов общих библиотек, у которых установлен бит выполнения, но они не являются исполняемыми файлами. При сопоставлении учитывается опция оболочки extglob.

FCEDIT

Редактор, используемый по умолчанию внутренней командой fc с опцией -e .

FIGNORE

Разделенный двоеточиями список суффиксов, которые игнорируются при дополнении имен файлов. Имя файла, в котором суффикс совпадает с одним из элементов FIGNORE, исключается из числа совпадений (например, .o:~)

FUNCNAME

Переменная массива, содержащая имена всех shell-функций в стеке исполняемых вызовов. С индексом 0 в массиве размещается имя выполняемой в данный момент функции, нижним элементом (наибольший индекс) является main. Переменная существует только при выполнении shell-функции. Назначение FUNCNAME эффекта не дает. При сбросе переменной она не восстанавливает особые свойства даже после переустановки.

Переменная может использоваться с BASH_LINENO и BASH_SOURCE, каждый элемент FUNCNAME имеет соответствующие элементы в BASH_LINENO и BASH_SOURCE для описания стека вызовов. Например, ${FUNCNAME[$i]} была вызвана из файла ${BASH_SOURCE[$i+1]}, строка ${BASH_LINENO[$i]}. Внутренняя функция caller выводит текущий стек вызовов, используя эту информацию.

FUNCNEST

При установке положительного числа определяет максимальный уровень вложенности функций. В случае превышения заданного уровня текущая команда прерывается.

GLOBIGNORE

Список разделенных двоеточиями шаблонов, определяющий набор имен файлов, игнорируемых при преобразовании имен. Если имя, соответствующее шаблону, соответствует также одному из шаблонов GLOBIGNORE, оно удаляется из списка совпадений. При сопоставлении учитывается опция оболочки extglob.

GROUPS

Переменная массива, содержащая список групп, в которые входит текущий пользователь. Назначение переменной не дает эффекта. При сбросе переменной она не восстанавливает особые свойства даже после переустановки.

histchars

До трех символов, управляющих преобразованием истории, быстрой постановкой и маркировкой (9.3. Преобразование истории). Первым служит символ преобразования истории (обычно !), который указывает начало преобразования. Второй символ указывает «быструю подстановку», когда этот символ является первым в строке (обычно ^). Необязательный третий символ (обычно #) указывает, что остальная часть строки является комментарием и пропускается в процессе подстановки. Это не обязательно ведет к трактовке оставшейся части строки как комментария синтаксическим анализатором оболочки.

HISTCMD

Номер в истории или индекс списка истории для текущей команды. При сбросе переменной она не восстанавливает особые свойства даже после переустановки.

HISTCONTROL

Список разделенных двоеточиями значений, которые управляют способом хранения в списке истории. Если список включает ignorespace, начинающиеся с пробела строки не включаются в список. Значение ignoredups отключает сохранение строк, совпадающих с предшествующими записями. Значение ignoreboth является сокращением для комбинации ignorespace и ignoredups. Значение erasedups задает удаление из списка записи, совпадающей с текущей строкой, перед сохранением этой строки. Все прочие значения игнорируются. Если переменная сброшена (unset) или не содержит действительных значений, все строки, прочитанные анализатором оболочки, сохраняются в списке истории в зависимости от значения HISTIGNORE. Вторая и последующие строки многострочной команды не проверяются и включаются в список истории независимо от значения HISTCONTROL.

HISTFILE

Имя файла для записи списка истории. По умолчанию ~/.bash_history.

HISTFILESIZE

Максимальное число строк в файле истории, при достижении которого наиболее старая запись удаляется. Отсечка файла по этому значению происходит также при выходе из оболочки. Значение 0 задает пустой файл. Нечисловые и отрицательные значения блокируют отсечку. Оболочка устанавливает используемое по умолчанию значение HISTSIZE после считывания стартовых файлов.

HISTIGNORE

Список разделенных двоеточиями, служащих для выбора команд, сохраняемых в списке истории. Каждый шаблон привязывается к началу строки и должен соответствовать всей строке (без добавления неявного символа *). Каждый шаблон сопоставляет со строкой после проверок, заданных HISTCONTROL. В дополнение к обычным шаблонам оболочки символу & соответствует предыдущая строка списка истории. Символ & может экранироваться символом \, который исключается перед сопоставлением. Вторая и последующие строки многострочной команды не проверяются и добавляются в список истории независимо от значения HISTIGNORE. При сопоставлении учитываются настройки опции extglob.

HISTIGNORE включает функции переменной HISTCONTROL. Шаблон & идентичен ignoredups, а [ ]* — ignorespace. Комбинация этих шаблонов, разделенных двоеточием, обеспечивает функциональность ignoreboth.

HISTSIZE

Максимальное число команд, запоминаемых в списке истории. При значении 0 команды не сохраняются в списке. Отрицательные значения задают сохранение каждой команды (нет ограничения). Оболочка устанавливает по умолчанию значение 500 после считывания всех стартовых файлов.

HISTTIMEFORMAT

Непустое значение переменной задает строку формата для strftime при выводе временных меток, связанных с записями, выводимыми по команде history. При заданной переменной метки записываются в файл истории и будут доступны в другой сессии оболочки. При записи меток применяется символ комментария для обозначения меток.

HOSTFILE

Имя файла в формате /etc/hosts, которые оболочке следует считывать при дополнении имен хостов. Список возможных дополнений имен можно менять во время работы оболочки и при следующем дополнении имени Bash добавит содержимое нового файла к имеющемуся списку. Если переменная пуста или не указывает читаемый файл, Bash пытается использовать /etc/hosts. При сброшенной переменной список имен хостов очищается.

HOSTNAME

Имя текущего хоста.

HOSTTYPE

Строка описания машины, на которой работает Bash.

IGNOREEOF

Управляет реакцией оболочки на получение символа EOF как единственного ввода. Установленное значение указывает число последовательных символов EOF, которые могут быть прочитаны в качестве первых символов строк ввода до завершения работы оболочки. Если переменная содержит нечисловое значение или не имеет значения, используется число 10. Если переменной не существует, символ EOF обозначает конец ввода в оболочку. Переменная действует только для интерактивных оболочек.

INPUTRC

Имя файла инициализации Readline, используемого вместо принятого по умолчанию ~/.inputrc.

INSIDE_EMACS

Если Bash находит эту переменную в среде при запуске оболочки, предполагается работа в shell-буфере Emacs с возможностью отключения редактирования строк в зависимости от значения TERM.

LANG

Служит для определения категории языковой установки, не заданной явно переменной, начинающейся с LC_.

LC_ALL

Переопределяет значение LANG и любой другой переменной LC_, задающей категорию языковой установки.

LC_COLLATE

Определяет порядок сортировки, используемой для результатов преобразования имен файлов, а также поведение преобразования диапазонов, классов эквивалентности и порядка сортировки при преобразовании имен файлов и сопоставлении с шаблонами (3.5.8. Преобразование имен файлов).

LC_CTYPE

Задает интерпретацию символов и поведение классов символов при преобразовании имен файлов и сопоставлении с шаблонами (3.5.8. Преобразование имен файлов).

LC_MESSAGES

Задает языковую установку, используемую для трансляции строк в двойных кавычках с префиксом $ (3.1.2.5. Зависимая от языка трансляция).

LC_NUMERIC

Задает категорию языковой установки, применяемую для форматирования чисел.

LC_TIME

Задает категорию языковой установки, применяемую для форматирования даты и времени.

LINENO

Номер строки в выполняемом сценарии или функции оболочки.

LINES

Используется командой select для определения размера строки при выводе списков для выбора. Устанавливается автоматически при включенной опции checkwinsize (4.3.2. Внутренняя команда shopt) или в интерактивной оболочке при получении SIGWINCH.

MACHTYPE

Строка, полностью описывающая тип системы, где выполняется Bash, в формате gnu cpu-company-system.

MAILCHECK

Интервал (в секундах, по умолчанию 60) проверки оболочкой новых сообщений в файлах, заданных переменными MAILPATH и MAIL. Оболочка проверяет почту перед выводом текущего основного приглашения. Если переменная не установлена или не содержит неотрицательного целого числа, проверка почты не происходит.

MAPFILE

Переменная массива, создаваемая для хранения текста, считываемого внутренней командой mapfile, когда имя переменной не задано.

OLDPWD

Предыдущий рабочий каталог, установленный командой cd.

OPTERR

При установке значения 1 Bash будет выводить сообщения об ошибках, создаваемые командой getopts.

OSTYPE

Строка, описывающая операционную систему, в которой работает Bash.

PIPESTATUS

Переменная массива (6.7. Массивы), содержащая список состояний выхода (exit) для процессов в недавнем (последнем) foreground-конвейере (который мог содержать единственную команду).

POSIXLY_CORRECT

Если Bash находит эту переменную в среде при запуске оболочки, оболочка переходит в режим POSIX mode (6.11. Режим POSIX) до считывания стартовых файлов, как будто была задана опция —POSIX. Если переменная установлена при работе оболочки, Bash включает режим POSIX как при выполнении команды set -o POSIX. При переходе оболочки в режим POSIX переменная устанавливается, если она еще не задана.

PPID

Идентификатор родительского процесса оболочки, доступный лишь для чтения.

PROMPT_COMMAND

Установленное значение считается командой, выполняемой перед выводом основного приглашения ($PS1).

PROMPT_DIRTRIM

Положительное значение считается числом компонент каталога, сохраняемых при преобразовании \w и \W в приглашениях (6.9. Управление формой приглашения). Удаленные символы заменяются многоточием.

PS0

Значение параметра преобразуется подобно PS1 и выводится интерактивной оболочкой после считывания команды и перед ее выполнением.

PS3

Значение переменной используется в качестве приглашения для команды select (по умолчанию ‘#? ’).

PS4

Значение параметра (по умолчанию ‘+ ’) преобразуется подобно PS1 и преобразованное значение служит приглашением, выводимым перед эхо-выводом команды, когда установлена опция -x (4.3.1. Внутренняя команда set). Первый символ преобразованного значения может повторяться для указания множества уровней косвенности.

PWD

Текущий рабочий каталог, установленный командой cd.

RANDOM

При каждой ссылке на параметр генерируется случайное число от 0 до 32767, которое служит «затравкой» (seed) для генератора случайных чисел.

READLINE_LINE

Содержимое буфера строки Readline для использования с bind -x (4.2. Внутренние команды bash).

READLINE_POINT

Положение точки вставки в буфер строки Readline для использования с bind -x (4.2. Внутренние команды bash).

REPLY

Переменная, используемая по умолчанию внутренней командой read.

SECONDS

Преобразуется в число секунд с момент запуска оболочки. Назначение переменной меняет прошлое значение на указанное и далее будет выводиться сумма заданного значения с числом секунд после установки.

SHELL

Полный путь к оболочке. Если при запуске оболочки переменная не задана, Bash назначает ей полное имя файла текущей пользовательской оболочки login.

SHELLOPTS

Список разделенных двоеточиями включенных опций оболочки. Каждое слово в списке является действительным аргументом опции -o внутренней команды set (4.3.1. Внутренняя команда set). Опции из списка SHELLOPTS выводятся с пометкой on по команде set -o. Если эта переменная была установлена в среде при запуске Bash, каждая из опций списка включается до прочтения стартовых файлов. Переменная доступна лишь для чтения.

SHLVL

Инкрементируется при запуске каждого нового экземпляра Bash для учета глубины вложенности оболочки.

TIMEFORMAT

Значение этого параметра служит строкой формата при выводе времени для конвейеров с зарезервированным словом time. Символ % указывает escape-последовательность, преобразуемую в значение времени или иную информацию, как показано ниже (в квадратных скобках указаны необязательные параметры).

%%

Литерал %.

%[p][l]R

Прошедшее время в секундах.

%[p][l]U

Затраченное процессором время в пользовательском режиме.

%[p][l]S

Затраченное процессором время в системном режиме.

%P

Процент загрузки CPU, рассчитанный как (%U + %S) / %R.

Параметр p указывает размер дробной части. Значение 0 задает вывод только целой части. Можно вывести до 3 знаков после точки и при задании большего числа будет использовано 3. Необязательный параметр l задает «длинный» формат с указанием минут в виде MM mSS.FFs. Значение p управляет дробной частью. Если переменная не задана, Bash использует значение $’\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS’. При пустой переменной данные о времени не выводятся. При выводе времени в конце строки формата добавляется символ новой строки.

TMOUT

Положительное значение трактуется как принятый по умолчанию тайм-аут внутренней команды read (4.2. Внутренние команды bash). Команда select (3.2.4.2. Конструкции с условием) прерывается, если не получен ввод в течение TMOUT секунд при ожидании данных с терминала. В интерактивной оболочке значение считается числом секунд ожидания ввода строки после вывода основного приглашения. Если полная строка не введена за это время, работа Bash прерывается.

TMPDIR

Установленное значение Bash использует как имя каталога для создания временных файлов оболочки.

UID

Числовой идентификатор текущего реального пользователя, доступный лишь для чтения.

6. Свойства Bash

В этой главе описаны свойства, присущие только Bash.

6.1. Вызов Bash

bash [long-opt] [-ir] [-abefhkmnptuvxdBCDHP] [-o option]
	[-O shopt_option] [argument ...]
bash [long-opt] [-abefhkmnptuvxdBCDHP] [-o option]
	[-O shopt_option] -c string [argument ...]
bash [long-opt] -s [-abefhkmnptuvxdBCDHP] [-o option]
	[-O shopt_option] [argument ...]

Все односимвольные опции внутренней команды set (4.3.1. Внутренняя команда set) могут служить опциями при вызове оболочки. Кроме того, может применяться часть многосимвольных опций, которые должны указываться в командной строке до односимвольных опций.

—debugger

Задает профиль отладчика, запускаемого перед вызовом оболочки, включая режим расширенной отладки (см. описание опции extdebug внутренней команды shopt в параграфе 4.3.2. Внутренняя команда shopt).

—dump-po-strings

Выводит список всех заключенных в двойные кавычки строк с префиксом $ на стандартное устройство вывода в формате gnu gettext PO1. Эквивалент опции -D для формата вывода.

—dump-strings

Эквивалент -D.

—help

Выдает сообщение об использовании на стандартный вывод и завершает работу.

—init-file filename

—rcfile filename

Выполняет команды из filename (вместо ~/.bashrc) для интерактивной оболочки.

—login

Эквивалент -l.

—noediting

Отключает использование библиотеки gnu Readline (8. Редактирование командной строки) для чтения строк команд в интерактивной оболочке.

—noprofile

Отменяет загрузку системного стартового файла /etc/profile и всех персональных файлов инициализации (~/.bash_profile, ~/.bash_login, ~/.profile) при вызове Bash в качестве оболочки для регистрации в системе (login).

—norc

Отменяет чтение файла инициализации ~/.bashrc интерактивной оболочки. Принято по умолчанию для вызова sh.

—POSIX

Меняет поведение Bash в тех аспектах, где принятые по умолчанию операции отличаются от стандарта POSIX. Это сделано для того, чтобы оболочка вела себя как строгое надмножество стандарта (6.11. Режим POSIX).

—restricted

Делает оболочку ограниченной (6.10. Ограниченная оболочка).

—verbose

Эквивалент -v. Выводит прочитанные строки ввода оболочки.

—version

Выводит информацию о версии данного экземпляра Bash на стандартный вывод и завершает работу.

Имеются односимвольные опции, которые могут быть указаны при вызове, но не доступны внутренней команде set.

-c

Считывание и выполнение команд с первого аргумента, не являющегося опцией, и завершение работы. При наличии аргументов после строки команды первый из них назначается переменной $0, а остальные — позиционным параметрам. Назначение $0 задает имя оболочки, используемое в предупреждениях и сообщениях об ошибках.

-i

Переводит оболочку в интерактивный режим (6.3. Интерактивные оболочки).

-l

Заставляет оболочку действовать как при прямом вызове для входа в систему (login). Для интерактивной оболочки это эквивалентно запуску login-оболочки с помощью exec -l bash, в остальных случаях будут выполняться стартовые файлы login-оболочки. Команды exec bash -l и exec bash —login будут менять текущую оболочку на Bash login (см. 6.2. Стартовые файлы Bash).

-r

Делает оболочку ограниченной (6.10. Ограниченная оболочка).

-s

При наличии этой опции или отсутствии аргументов после обработки опций команда считывается со стандартного ввода, что позволяет задать позиционные параметры для интерактивной оболочки или при вводе из конвейера.

-D

Выводит список всей заключенных в двойные кавычки строк с префиксом $ на стандартное устройство вывода. К этим строкам применяются языковые преобразования, когда текущая настройка языка отличается от C и POSIX (3.1.2.5. Зависимая от языка трансляция). Подразумевается опция -n, команды не выполняются.

[-+]O [shopt_option]

Опция shopt является одной из опций оболочки, воспринимаемых командной shopt (4.3.2. Внутренняя команда shopt). При наличии такой опции -O устанавливает значение, +O отменяет. Если опция shopt не задана, выводятся имена и значения опций оболочки, воспринимаемые shopt, на стандартное устройство вывода. При использовании опции вызова +O формат вывода пригоден для использования в качестве ввода.

Символы — указывают завершение опций и отключают дальнейшую их обработку. Все аргументы после — считаются именами файлов и аргументами.

Оболочкой входа (login) является оболочка с первым символом аргумента «-» или вызванная с опцией —login.

Интерактивной является оболочка, запущенная без аргументов, не являющихся опциями (если не задана опция -s), без опции -c и соединенная с терминалами по входу и выходу (как определено isatty(3)), или запущенная с опцией -i (см. 6.3. Интерактивные оболочки).

Если после обработки опций остаются аргументы и не было задано ни одной из опций -c и -s, первый аргумент считается именем файла с командами оболочки (3.8. Сценарии оболочки). При таком вызове Bash параметру $0 назначается имя этого файла, а остальные аргументы передаются в позиционные параметры. Bash читает и выполняет команды из файла, а затем завершает работу. Статусом завершения Bash будет статус выхода последней выполненной в сценарии команды. При отсутствии команд статус выхода будет 0.

6.2. Стартовые файлы Bash

В этом разделе описано использование стартовых файлов в Bash. Если файл имеется, но не может быть прочитан, Bash сообщает об ошибке. Символ ~ преобразуется, как указано в параграфе 3.5.2. Преобразование тильды.

Интерактивные оболочки описаны в параграфе 6.3. Интерактивные оболочки.

Вызов как интерактивной входной оболочки или с опцией —login

При вызове Bash как интерактивной оболочки входа в систему (login) или неинтерактивной оболочки с опцией —login сначала считываются и выполняются команды из файла /etc/profile, если он имеется. После этого отыскиваются в указанном порядке файлы ~/.bash_profile, ~/.bash_login, ~/.profile и первый найденный и читаемый файл считывается, а команды из него выполняются. Для блокировки такого поведения можно задать при запуске опцию —noprofile.

При завершении интерактивной login-оболочки или при выполнении в неинтерактивной login-оболочке внутренней команды exit интерпретатор Bash считывает файл ~/.bash_logout (при наличии) и выполняет команды из него.

Вызов как неинтерактивной и невходной оболочки

При запуске интерактивной оболочки, не являющейся входом в систему (login) Bash считывает файл ~/.bashrc (при его наличии) и выполняет команды из него. Это поведение можно блокировать опцией —norc, а опция —rcfile заставляет Bash читать и выполнять команды из файла ~/.bashrc.

Обычно файл ~/.bash_profile содержит строку

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

после (или до) связанной со входом в систему инициализации.

Вызов как неинтерактивной оболочки

При запуске Bash в неинтерактивном режиме (например, для выполнения сценария) отыскивается переменная среды BASH_ENV, ее значение преобразуется и результат используется в качестве имени файла для считывания и выполнения. Bash ведет себя как при выполнении команды

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

При этом значение переменной PATH не применяется для поиска файла. Как отмечено выше, при вызове неинтерактивной оболочки с опцией —login интерпретатор Bash пытается читать и выполнять команды из стартовых файлов login-оболочки.

Вызов с именем sh

При вызове Bash с именем sh предпринимается попытка поведения при старте в соответствии с исторической оболочкой sh и стандартом POSIX. При запуске в качестве интерактивной оболочки входа (login) или неинтерактивной оболочки с опцией —login сначала предпринимается попытка выполнить команды из файлов /etc/profile и ~/.profile в указанном порядке. Это можно блокировать опцией —noprofile.

При вызове в качестве интерактивной оболочки с именем sh интерпретатор Bash отыскивает переменную ENV, преобразует ее (при наличии) и использует результат как имя файла для считывания и выполнения. Поскольку при вызове по имени sh оболочка не пытается считывать и выполнять команды из других стартовых файлов, опция —rcfile не будет работать. При вызове неинтерактивной оболочки по имени sh не предпринимается попыток чтения и выполнения других стартовых файлов. При вызове по имени sh интерпретатор Bash переходит в режим POSIX после чтения стартовых файлов.

Вызов в режиме POSIX

При запуске Bash в режиме POSIX (с опцией —POSIX) применяются стартовые файлы в соответствии со стандартом POSIX. В этом режиме интерактивная оболочка преобразует переменную ENV, считывая и выполняя команды из файла, имя которого получено в результате преобразования. Другие стартовые файлы не считываются.

Вызов удаленным демоном shell

Bash пытается определить запуск со стандартным вводом, подключенным к сетевому соединению, как при выполнении демоном удаленной оболочки (обычно rshd) или sshd. Если Bash идентифицирует такой режим, считываются и выполняются команды из файла ~/.bashrc при его наличии и доступности для чтения (это не будет происходить при вызове оболочки по имени sh). Можно блокировать считывание и выполнение команд опцией —norc или указать —rcfile для чтения и выполнения другого файла, но демоны rshd и sshd обычно не используют и не поддерживают эти опции.

Вызов с неэквивалентными эффективными и реальными uid/gid

При запуске Bash с эффективным идентификатором пользователя (группы), не совпадающим с реальным, и без опции -p стартовые файлы не будут использоваться, функции оболочки не наследуются из среды, переменные SHELLOPTS, BASHOPTS, CDPATH и GLOBIGNORE (при их наличии в среде) игнорируются, а эффективный идентификатор пользователя устанавливается в соответствии с реальным. При наличии опции -p эффективный идентификатор пользователя не будет меняться.

6.3. Интерактивные оболочки

6.3.1. Что такое интерактивная оболочка?

Интерактивной считается оболочка, запущенная без аргументов, не являющихся опциями (если не задана опция -s), без опции -c, со вводом и выводом (ошибок), подключенными к терминалу (в соответствии с isatty(3)), или запущенная с опцией -i. Интерактивные оболочки обычно применяют для ввода и вывода терминал пользователя. Можно использовать вызов с опцией -s для задания позиционных параметров при старте оболочки.

6.3.2. Является ли оболочка интерактивной?

Для определения в сценарии интерактивного режима Bash можно проверять значения специального параметра ‘-’, который в интерактивном режиме содержит i. Например,

case "$-" in
*i*) echo This shell is interactive ;;
*) echo This shell is not interactive ;;
esac

Можно также проверять переменную PS1, которая устанавливается только в интерактивной оболочке. Например,

if [ -z "$PS1" ]; then
	echo This shell is not interactive
else
	echo This shell is interactive
fi

6.3.3. Поведение интерактивной оболочки

При работе оболочки в интерактивном режиме меняется ряд аспектов поведения, описанных ниже.

  1. Стартовые файлы считываются и выполняются как описано в параграфе 6.2. Стартовые файлы Bash.

  2. Управление заданиями по умолчанию включено (7. Управление заданиями) и Bash игнорирует сигналы управления заданиями с клавиатуры (SIGTTIN, SIGTTOU, SIGTSTP).

  3. Bash преобразует и выводит переменную PS1 перед считыванием первой строки команды, а также преобразует и выводит PS2 перед считыванием второй и последующих строк многострочной команды. Bash преобразует и выводит переменную PS0 после чтения команды, но до ее выполнения. Полное описание escape-последовательностей строк приглашения приведено в разделе 6.9. Управление формой приглашения.

  4. Bash использует значение переменной PROMPT_COMMAND как команду, выполняемую перед выводом основного приглашения $PS1 (5.2. Переменные Bash).

  5. Для чтения команд с пользовательского терминала служит Readline (8. Редактирование командной строки).

  6. Bash проверяет значение опции ignoreeof для установки -o вместо незамедлительного выхода при получении символа EOF со стандартного ввода во время чтения команд (4.3.1. Внутренняя команда set).

  7. История команд (9.1. Средства Bash History) и ее преобразование (9.3. Преобразование истории) включены по умолчанию. Bash сохраняет историю команд в файле, указанном $HISTFILE, при завершении работы со включенной историей.

  8. Преобразование псевдонимов (6.6. Псевдонимы) выполняется по умолчанию.

  9. При отсутствии ловушек (trap) Bash игнорирует SIGTERM (3.7.6. Сигналы).

  10. При отсутствии ловушек сигнал SIGINT считывается и обрабатывается (3.7.6. Сигналы), прерывая некоторые внутренние функции оболочки.

  11. Интерактивная оболочка входа (login) передает сигнал SIGHUP всем заданиям при выходе, если включена опция huponexit (3.7.6. Сигналы).

  12. Опция вызова -n игнорируется, а set -n не оказывает влияния (4.3.1. Внутренняя команда set).

  13. Bash периодически проверяет почту в соответствии со значениями переменных MAIL, MAILPATH и MAILCHECK (5.2. Переменные Bash).

  14. Ошибки прерывания, обусловленные ссылками на несвязанные переменные оболочки после включения set -u не будут приводить к завершению работы (4.3.1. Внутренняя команда set).

  15. Оболочка не будет завершать работу при ошибках преобразования, вызванных отменой или пустым значением var в ${var:?word} (3.5.3. Преобразование параметров оболочки).

  16. Ошибки перенаправления для внутренних команд оболочки не будут приводить к завершению работы.

  17. В режиме POSIX специальная встроенная функция возврата статуса ошибок не будет вызывать прекращение работы (6.11. Режим POSIX).

  18. Отказ exec не будет вызывать прекращение работы (4.1. Внутренние элементы Bourne Shell).

  19. Синтаксические ошибки при анализе не будут вызывать прекращение работы.

  20. Простая корректировка ввода каталогов для внутренней команды cd включена по умолчанию (см. описание опции cdspell в параграфе 4.3.2. Внутренняя команда shopt).

  21. Оболочка проверяет значение переменной TMOUT и будет завершать работу, если команда не считана в течение заданного числа секунд после вывода $PS1 (5.2. Переменные Bash).

6.4. Условные выражения bash

Условные выражения используются составной командой [[, а также внутренними командами test и [, поведение которых зависит от числа аргументов. Выражения могут быть унарными или бинарными и состоят из примитивов. Унарные выражения часто применяются для проверки статуса файлов. Имеются операторы сравнения строк и числовых выражений. Bash применяет особую обработку для некоторых имен файлов в выражениях. Если операционная система, где работает Bash, поддерживает такие файлы, Bash будет использовать их. В остальных случаях применяется внутренняя эмуляция — если аргумент file имеет форму /dev/fd/N, проверяется файл с дескриптором N, для /dev/stdin, /dev/stdout, /dev/stderr используются дескрипторы 0, 1, 2.

При использовании с [[ операторы < и > работают на основе лексикографической сортировки для установленного языка (locale). Команда test использует сортировку ASCII.

Если явно не указано иное, работающие с файлами примитивы следуют по символьным ссылкам и действуют на целевой файл, а не на саму ссылку.

-a file

True, если file существует.

-b file

True, если file существует и является специальным блочным файлом.

-c file

True, если file существует и является специальным символьным файлом.

-d file

True, если file существует и является каталогом.

-e file

True, если file существует.

-f file

True, если file существует и является обычным файлом.

-g file

True, если file существует и для него установлен бит set-group-id.

-h file

True, если file существует и является символьной ссылкой.

-k file

True, если file существует и для него установлен бит sticky.

-p file

True, если file существует и является именованным каналом (FIFO).

-r file

True, если file существует и доступен для чтения.

-s file

True, если file существует и его размер больше 0.

-t fd

True, если дескриптор fd открыт и указывает на терминал.

-u file

True, если file существует и для него установлен бит set-user-id.

-w file

True, если file существует и доступен для записи.

-x file

True, если file существует и является исполняемым.

-G file

True, если file существует и принадлежит действующей группе.

-L file

True, если file существует и является символьной ссылкой.

-N file

True, если file существует и был изменен с момента последнего чтения.

-O file

True, если file существует и принадлежит действующему пользователю.

-S file

True, если file существует и является сокетом.

file1 -ef file2

True, если file1 и file2 указывают одно устройство и номер inode.

file1 -nt file2

True, если file1 новее (по времени изменения) чем file2 или file1 существует, а file2 — нет.

file1 -ot file2

True, если file1 старше чем file2 или file2 существует, а file1 — нет.

-o optname

True, если включена опция оболочки optname (4.3.1. Внутренняя команда set).

-v varname

True, если переменная оболочки varname установлена (имеет значение).

-R varname

True, если переменная оболочки varname установлена и ссылается на имя.

-z string

True, если размер string равен 0.

-n string
string

True, если размер string не равен 0.

string1 == string2

string1 = string2

True, если строки совпадают. При использовании с командой [[ выполняется сопоставление с шаблоном, как описано в параграфе 3.2.4.2. Конструкции с условием.
Оператор = следует использовать с командой test для соответствия POSIX.

string1 != string2

True, если строки не совпадают.

string1 < string2

True, если string1 лексикографически предшествует строке string2.

string1 > string2

True, если string1 лексикографически следует после строки string2.

arg1 OP arg2

OP может быть -eq, -ne, -lt, -le, -gt или -ge. Операторы возвращают true, если arg1 равен, не равен, меньше, не больше, больше, не меньше arg2. Arg1 и arg2 могут быть положительными или отрицательными целыми числами. При использовании с командой [[ аргументы arg1 и arg2 считаются арифметическими выражениями (6.5. Арифметика командного процессора).

6.5. Арифметика командного процессора

Командный процессор позволяет вычислять арифметические выражения как один из видов преобразования или с использованием композитной команды ((, внутренней команды let или опции -i для внутренней команды declare.

Вычисление производится с целыми числами фиксированного размера без проверки переполнения, хотя деление на 0 отслеживается и помечается как ошибка. Операторы, порядок их применения, ассоциативность и значения совпадают с принятыми в языке C. Ниже приведен список операторов, сгруппированных по уровням предпочтения (порядку применения) в порядке снижения.

id++ id—

Пост-инкрементирование и пост-декрементирование переменной

++id —id

Предварительное инкрементирование и декрементирование переменной

+ —

Унарный + и —

! ~

Логическое и побитовое отрицание

**

Возведение в степень

*/%

Умножение, деление, остаток

+ —

Сложение, вычитание

<< >>

Побитовый сдвиг влево и вправо

<= >= < >

Сравнение

== !=

Равенство и неравенство

&

побитовая операция AND

^

Побитовая операция XOR (исключительное ИЛИ)

|

Побитовая операция OR (ИЛИ)

&&

Логическая операция AND (И)

||

Логическая операция OR (ИЛИ)

expr ? expr : expr

Условный оператор

= *= /= %= += -= <<= >>= &= ^= |=

Назначение

expr1 , expr2

Запятая

Переменные оболочки могут служить операндами, преобразование параметров выполняется до расчета выражения. В выражении переменные оболочки могут задаваться именами без применения синтаксиса преобразования параметров. Переменная оболочки, имеющая значение null или не установленная, преобразуется в 0 при указании именем без использования синтаксиса преобразования. Значение переменной вычисляется как арифметическое выражения, когда на нее ссылаются или присвоено значение переменной, объявленной с атрибутом integer, с помощью declare -i. Значение null трактуется как 0. Переменная не обязана иметь атрибут integer для использования в выражении.

Константы, начинающиеся с 0, считаются восьмеричными значениями, а 0x или 0X в начале указывает шестнадцатеричное значение. В остальных случаях числа имеют форму [base#]n, где необязательный элемент base является десятичным числом от 2 до 64, представляющим основание, а n указывает значение по этому основанию. Если base# отсутствует, предполагается основание 10. При указании n цифры больше 9 указываются заглавными буквами, буквами нижнего регистра, а также символами @ и _ в указанном порядке. Если основание не превышает 36, в качестве цифр 10 — 35 могут применяться буквы в верхнем и нижнем регистре без его учета.

Операторы при расчете применяются в соответствии с порядком действий, субвыражения в скобках вычисляются заранее и могут менять порядок действий.

6.6. Псевдонимы

Псевдонимы позволяют заменить строку словом для использования в качестве первого слова простой команды. Оболочка поддерживает список псевдонимов, которые можно задавать и отменять с помощью внутренних команд alias и unalias.

Первое слово простой команды, если оно не заключено в кавычки, проверяется на предмет наличия псевдонима. Если псевдоним найден, слово заменяется текстом соответствующей строки. Символы /, $, ‘, = и все метасимволы оболочки, а также символы кавычек, указанные выше, не могут включаться в имена псевдонимов. Текст, заменяющий псевдоним, может содержать любой действительный ввод оболочки, включая метасимволы. Первое слово текста проверяется на предмет наличия псевдонима, но идентичное преобразуемому псевдониму слово второй раз не преобразуется. Это значит, например, что в псевдониме ls для текста «ls -F» Bash не будет пытаться рекурсивно подставлять замену ls. Если последний символ псевдонима является пробельным (blank), следующее слово команды также проверяется на предмет наличия и преобразования псевдонима.

Псевдонимы создаются и просматриваются с помощью команды alias, а удаляются командой unalias.

Механизма использования аргументов в тексте подстановки (как в csh) не поддерживается. Если аргументы нужны, следует использовать не псевдоним, а функцию оболочки (3.3. Функции оболочки).

Псевдонимы не преобразуются в неинтерактивной оболочке, если для нее не установлена опция expand_aliases с помощью внутренней команды shopt (4.3.2. Внутренняя команда shopt).

Правила определения и использования псевдонимов несколько запутаны. Bash всегда читает по меньшей мере одну полную строку ввода и все строки, образующие композитную команду, перед выполнением любой команды в строке или составной команды. Псевдонимы преобразуются при считывании команды, а не ее выполнении. Поэтому определение псевдонима в одной строке с командой не будет работать до ввода следующей строки. Команда, следующая за определением псевдонима, в той же строке не сможет использовать псевдоним. Это также может вызывать проблемы при выполнении функций. Псевдонимы преобразуются при считывании определения функции, а не при ее выполнении, поскольку определение функции само является командой. В результате псевдонимы, определенные в функции, недоступны, пока функция не будет выполнена. В целях безопасности следует помещать определения псевдонимов в отдельную строку и не применять псевдонимы в составных командах.

Практически во всех случаях функции оболочки предпочтительней, нежели псевдонимы.

6.7. Массивы

Bash поддерживает одномерные массивы с индексом и ассоциативные массивы. Внутренний оператор declare служит для явного объявления массива. Размер массивов не ограничен и не задается требований к непрерывности индексов. Индексированные массивы указываются с использованием целочисленных индексов, которые могут быть арифметическими выражениями (6.5. Арифметика командного процессора). Отсчет индексов начинается с 0. Если явно не указано иное, индексы массива должны быть неотрицательными целыми числами. Ассоциативные массивы используют произвольные строки ключей.

Индексированный массив создается автоматически, если любая переменная задана с использованием синтаксиса

name[subscript]=value

Элемент subscript считается арифметическим выражением, которое должно преобразовываться в число. Для явного объявления массива служит форма, приведенная ниже.

declare -a name

Приемлем также синтаксис

declare -a name[subscript]

где значение subscript игнорируется.

Ассоциативные массивы создаются в форме

declare -A name.

Атрибуты могут быть заданы для переменной массива с использованием внутренней команды declare или readonly. Каждый атрибут применяется ко всем элементам массива.

Значения массивов указываются с помощью компонентного оператора присваивания в форме

name=(value1 value2 ... )

где каждый аргумент value имеет форму [subscript]=string. Индексированные массивы не требуют ничего, кроме строки. При задании значений таких массивов с указанием необязательного индекса значение присваивается с этим индексом, иначе назначается элемент, следующий за последним с увеличением индекса на 1. Индексы начинаются с 0.

При задании значения в ассоциативном массиве требуется указание индекса. Такой синтаксис принимается также внутренней командой declare. Отдельные элементы массива могут задаваться в форме name[subscript]=value.

Если при назначении в индексированный массив имя задано отрицательным индексом, значение интерпретируется относительно максимального индекса (вычитается), т. е. отрицательные индексы отсчитываются от конца массива и -1 указывает последний элемент.

Любой элемент массива можно указать в форме ${name[subscript]}. Скобки нужны для предотвращения конфликтов с операторами преобразования имен файлов. Если индекс subscript имеет значение @ или *, слово преобразуется во все элементы массива name. Эти индексы различаются лишь для слов в двойных кавычках. В этом случае ${name[*]} преобразуется в одно слово с разделением элементов массива первым символом переменной IFS, а ${name[@]} преобразуется в отдельные слова для каждого элемента массива. Если в массиве нет элементов, ${name[@]} преобразуется в пустое значение. Если происходит преобразование двойных кавычек внутри слова, первый преобразованный символ объединяется с началом исходного слова, а последний — с концом этого слова. Это аналогично преобразованию специальных символов @ и *. ${#name[subscript]} преобразуется в размер ${name[subscript]}. Если subscript имеет значение @ или *, результатом преобразования будет число элементов массива. Если индекс массива преобразуется в число меньше 0, он интерпретируется относительно максимального индекса в массиве (т. е. -1 указывает последний элемент массива).

Ссылка на переменную массива без указания индекса эквивалентна ссылке с индексом 0. Любая ссылка на переменную с действительным индексом корректна и bash при необходимости будет создавать массив. Переменная массива считается установленной, если назначено значение индекса. Пустая строка является допустимым значением.

Можно получить ключи (индексы) массива, а также значения. ${!name[@]} и ${!name[*]} преобразуются в индексы, назначенные в переменной массива name. Трактовка значений в двойных кавычках похожа на преобразование специальных символов @ и * внутри двойных кавычек.

Для уничтожения массивов служит внутренняя команда unset. Для уничтожения элемента в индексном массиве служит unset name[subscript]. Интерпретация отрицательных значений индекса описана выше. Уничтожение последнего (единственного) элемента в переменной массива не уничтожает саму переменную, а команда unset name, где name указывает имя массива, удаляет весь массив. Индекс * или @ также позволяет удалить массив целиком.

При указании имени переменной с индексом в качестве аргумента команды (например, unset) без использования синтаксиса преобразования слов, описанного выше, для аргумента будет выполняться принятое в оболочке преобразование имен файлов. Если такое преобразование не желательно, аргумент следует поместить в кавычки.

Внутренние команды declare, local, readonly воспринимают опцию -a для указания индексированных массивов и -A для ассоциативных массивов. При наличии обеих опций приоритет отдается -A. Внутренняя команда read принимает опцию -a для назначения списка слов со стандартного ввода элементам массива. Внутренние команды set и declare выводят значения массивов в форме, пригодной для ввода.

6.8. Стек каталогов

Стек каталогов представляет собой список недавно посещенных каталогов. Внутренняя команда pushd добавляет каталоги в стек при изменении текущего каталога, а внутренняя команда popd удаляет каталоги из стека и меняет текущий каталог при удалении каталога. Внутренняя команда dirs выводит содержимое стека каталогов, указывая текущий каталог на вершине стека. Содержимое стека каталогов доступно также в переменной DIRSTACK.

6.8.1. Внутренние команды стека каталогов

dirs

dirs [-clpv] [+N | -N]

Выводит текущий список запомненных каталогов. Каталоги добавляются в список командой pushd и удаляются из него командой popd. Текущий каталог всегда является первым в стеке.

-c

Очищает стек каталогов, удаляя из него все элементы.

-l

Выводит в списке каталогов полные пути. По умолчанию домашний каталог заменяется тильдой (~).

-p

Вывод стека каталогов по одной записи в строке.

-v

Вывод стека каталогов по одной записи в строке с номером записи в начале каждой строки.

+N

Выводит N-й каталог из списка (отсчет с 0, слева направо).

-N

Выводит N-й каталог из списка (отсчет с 0, справа налево).

popd

popd [-n] [+N | -N]

При отсутствии аргументов popd удаляет верхний каталог из стека и выполняет команду cd для нового верхнего каталога. Элементы нумеруются с 0, начиная с первого каталога в списке dirs, т. е. popd эквивалентно popd +0.

-n

Подавляет обычную смену каталога при удалении каталогов из стека.

+N

Удаляет N-й каталог (слева направо в списке, выводимом dirs, считая с 0).

-N

Удаляет N-й каталог (справа налево в списке, выводимом dirs, считая с 0).

pushd

pushd [-n] [+N | -N | dir]

Сохраняет текущий каталог на вершине стека, затем выполняет команду cd dir. При отсутствии аргументов меняет местами два верхних каталога в стеке и делает новый каталог текущим.

-n

Подавляет обычную смену каталога при ротации или добавлении каталогов в стек.

+N

Помещает N-й каталог (слева направо в списке, выводимом dirs, считая с 0) на вершину путем ротации стека.

-N

Помещает N-й каталог ( справа налево в списке, выводимом dirs, считая с 0) на вершину путем ротации стека.

dir

Делает dir вершиной стека и новым текущим каталогом, как при указании его в качестве аргумента команды cd.

6.9. Управление формой приглашения

Значение переменной PROMPT_COMMAND проверяется непосредственно перед каждым выводом основного приглашения Bash. Если переменная установлена и значение отличается от null, оно выводится, как будто было набрано в командной строке. Символы, имеющие специальное значение в переменных приглашения PS0, PS1, PS2 и PS4 описаны ниже.

\a

«Звонок»

\d

Дата в формате «день недели, месяц, число(например, Tue May 26).

\D{format}

Значение format передается strftime(3) и результат помещается в строку приглашения. Пустое значение format задает представление времени в соответствии с языком (разделителями служат пробелы).

\e

Символ экранирования (escape).

\h

Имя хоста до первой точки.

\H

Полное имя хоста.

\j

Число заданий, обслуживаемых в данный момент оболочкой.

\l

Базовое имя терминального устройства оболочки.

\n

Новая строка.

\r

Возврат каретки.

\s

Имя оболочки, базовое имя $0 (часть после финального символа /).

\t

Время в 24-часовом формате HH:MM:SS.

\T

Время в 12-часовом формате HH:MM:SS.

\@

Время в 12-часовом формате am/pm.

\A

Время в 24-часовом формате HH:MM.

\u

Имя текущего пользователя.

\v

Версия Bash (например, 2.00)

\V

Выпуск Bash, версия + patchlevel (например, 2.00.0)

\w

Текущий рабочий каталог с заменой значения $HOME тильдой (используется переменная $PROMPT_DIRTRIM).

\W

Базовое имя $PWD с заменой значения $HOME тильдой.

\!

Номер текущей команды в истории.

\#

Номер этой команды.

\$

Задает символ # для пользователя с uid =0, и $ для остальных.

\nnn

Символ с восьмеричным кодом ASCII nnn.

\\

\.

\[

Начало последовательности непечатаемых символов. Может использоваться для задания символов управления терминалом в приглашении.

\]

Конец последовательности непечатаемых символов.

Номер команды и номер в истории обычно различаются — номер в истории указывает позицию в списке истории, который может включать восстановленные из файла истории команды (9.1. Средства Bash History), а номер команды указывает позицию в последовательности команд, выполненных в данном сеансе оболочки.

После декодирования строки выполняется преобразование параметров, подстановка команд, арифметические преобразования и удаление кавычек в соответствии со значением опции promptvars (4.3.2. Внутренняя команда shopt).

6.10. Ограниченная оболочка

Если Bash запускается по имени rbash или при вызове задана опция —restricted или -r, оболочка становится ограниченной для организации среды, более управляемой по сравнению со стандартной оболочкой. Поведение ограниченной оболочки отличается от bash в перечисленных ниже аспектах, которые запрещены или не выполняются.

  • Смена каталогов внутренней командой cd.

  • Установка и отмена значений переменных SHELL, PATH, ENV, BASH_ENV.

  • Ввод команд, имена которых содержат символ /.

  • Указание в качестве аргументов внутренней команды . имен файлов с символом /.

  • Указание имен файлов с символом / в качестве аргументов опции -p внутренней команды hash.

  • Импорт определений функций из среды оболочки при старте.

  • Разбор значения SHELLOPTS из среды оболочки при старте.

  • Перенаправление вывода с помощью операторов >, >|, <>, >&, &> и >>.

  • Использование внутренней функции exec для замены оболочки другой командой.

  • Добавление или удаление внутренних команд с помощью опций -f и -d внутренней команды enable.

  • Использование внутренней команды enable для включения отключенных внутренних функций оболочки.

  • Задание опции -p для внутренней команды command.

  • Отключение ограниченного режима с помощью set +r или set +o restricted.

Эти ограничения применяются после чтения всех стартовых файлов.

При выполнении команд, которые считаются сценариями оболочки (3.8. Сценарии оболочки), rbash отключает все ограничения в оболочке, вызванной для выполнения сценария.

6.11. Режим POSIX

Запуск Bash с опцией —POSIX или выполнение команды set -o POSIX в процессе работы Bash будет переводить оболочку в режим более точного соответствия стандарту POSIX путем смены поведения для соответствия POSIX в тех областях, где принятое по умолчанию поведение Bash отличается от стандарта.

При вызове по имени sh оболочка Bash входит в режим POSIX после считывания стартовых файлов.

Ниже приведен список изменений, обусловленных переходом в режим POSIX.

  1. Bash обеспечивает установку переменной POSIXLY_CORRECT.

  2. Когда команды больше нет в хэш-таблице, Bash будет заново просматривать $PATH для поиска нового местоположения. Это доступно также по команде shopt -s checkhash.

  3. Сообщение, выводимое кодом управления заданиями и внутренними функциями при завершении задания с ненулевым статусом, имеет вид Done(статус).

  4. Сообщение, выводимое кодом управления заданиями и внутренними функциями при остановке задания, имеет вид Stopped(signame), где signame указывает имя сигнала (например, SIGTSTP).

  5. Преобразование псевдонимов выполняется всегда (даже в неинтерактивном режиме).

  6. Зарезервированные слова в контексте, где они распознаются, не подвергаются преобразованию псевдонимов.

  7. В POSIX преобразование в PS1 и PS2 символа ! в номер истории и !! в ! включено и преобразование параметров для PS1 и PS2 не зависит от опции promptvars.

  8. Выполняются стартовые файлы POSIX ($ENV) вместо обычных файлов Bash.

  9. Преобразование тильды выполняется лишь в назначениях, предшествующих имени команды, а не во всех.

  10. По умолчанию история записывается в файл ~/.sh_history (принятое по умолчанию значение $HISTFILE).

  11. Операторы перенаправления не преобразуют имена файлов в word, если оболочка не является интерактивной.

  12. Операторы перенаправления не расщепляют слова в word.

  13. Имена функций должны быть действительными именами оболочки, т. е. они не могут содержать символов, не являющихся буквами, цифрами или знаком подчеркивания, а также не могут начинаться с цифры. Объявление функции с непригодным именем приводит к критической ошибке синтаксиса в неинтерактивных оболочках.

  14. Имена функций могут не совпадать с именами специальных внутренних команд POSIX.

  15. Специальные внутренние команды POSIX отыскиваются до функций оболочки.

  16. При выводе определений функций оболочки (например, с помощью type) Bash не печатает ключевое слово function.

  17. Символ ~ в качестве первого символа в элементах PATH не преобразуется, как описано в параграфе 3.5.2. Преобразование тильды.

  18. Зарезервированное слово time может применяться в качестве команды. В этом случае выводится временная статистика оболочки и завершенных потомков. Формат вывода задает переменная TIMEFORMAT.

  19. При анализе и преобразовании ${ . . . } для выражений в двойных кавычках одинарные кавычки уже не имеют особого значения и не могут служить для «экранирования» закрывающей скобки или других специальных символов, пока оператор не является одним из тех, которые указаны для удаления шаблона. В этом случае они не обязаны быть парными.

  20. Анализатор не распознает time как зарезервированное слово, если следующий маркер начинается с -.

  21. Символ ! не вводит преобразования истории для строки в двойных кавычках даже при включенной опции histexpand.

  22. Если внутренняя команда POSIX special возвращает статус ошибки, неинтерактивная оболочка завершает работу. Критические ошибки указаны в стандарте POSIX и включают передачу некорректных опций, ошибки перенаправления, ошибки назначения переменных для присвоений до имени команды и т. п.

  23. Неинтерактивная оболочка завершается со статусом ошибки, если при назначении переменной имя команды не указано после оператора присваивания. Такие ошибки могут возникать, например, при попытке задать значение переменной, доступной лишь для чтения.

  24. Неинтерактивная оболочка завершается со статусом ошибки, если при назначении переменной оператор присваивания предшествует специальной встроенной команде, а не другой простой команде.

  25. Неинтерактивная оболочка завершается со статусом ошибки, если переменная цикла for или переменная выбора в операторе select доступна лишь для чтения.

  26. Неинтерактивная оболочка завершается, если не найден файл из . filename.

  27. Неинтерактивная оболочка завершается, если синтаксическая ошибка в арифметическом выражении приводит к некорректному выражению.

  28. Неинтерактивная оболочка завершается, если возникает ошибка преобразования параметров.

  29. Неинтерактивная оболочка завершается, если имеется синтаксическая ошибка в сценарии, прочитанном встроенной командой . или source, или при обработке строки внутренней командой eval.

  30. Подстановка процессов не доступна.

  31. Косвенность переменных доступна, но не может применяться к специальным параметрам # и ?.

  32. При преобразовании специального параметра * в контексте шаблона, где преобразуется выражение в двойных кавычках, не считающее последовательность $* заключенной в двойные кавычки.

  33. Операторы присваивания, предшествующие специальным внутренним командам POSIX, сохраняются в среде оболочки после выполнения внутренней команды.

  34. Операторы присваивания, предшествующие вызовам функций оболочки, сохраняются в среде оболочки после возврата из функции как при исполнении специальных внутренних команд POSIX.

  35. Внутренняя команда command не препятствует внутренним командам, которые принимают операторы присваивания в качестве аргументов, преобразовывать их как операторы присваивания. В иных режимах внутренние операторы присваивания, заданные как аргументы, теряют свои свойства при обработке command.

  36. Внутренняя команда bg использует для описания каждого задания, помещаемого в фоновый режим, обязательный формат, не указывающий, является задание текущим или предыдущим.

  37. Вывод kill -l включает имена всех сигналов в одной строке через пробелы без суффикса SIG.

  38. Внутренняя команда kill не воспринимает имена сигналов с префиксом SIG.

  39. Внутренние команды export и readonly используют для вывода формат, требуемый POSIX.

  40. Внутренняя команда trap выводит имена сигналов без префикса SIG.

  41. Внутренняя функция trap проверяет первый аргумент на предмет спецификации сигнала и сохраняет исходную обработку сигналов (при наличии), если этот аргумент не включает только цифры действительного номера сигнала. Если пользователь хочет сбросить обработчик для данного сигнала в исходное состояние, следует использовать — в качестве первого аргумента.

  42. Внутренние команды . и source не просматривают текущий каталог для аргумента filename, если файл не найден в PATH.

  43. Включение режима POSIX ведет к установке опции inherit_errexit, поэтому субоболочки, вызываемые для выполнения подстановки команд, наследуют значение опции -e от родительской оболочки. При выключенной опции inherit_errexit интерпретатор Bash сбрасывает -e в таких субоболочках.

  44. Включение режима POSIX ведет к установке опции shift_verbose option, поэтому числовые аргументы shift, выходящие за пределы числа позиционных параметров, приводят к сообщениям об ошибке.

  45. При выводе определений псевдонимов внутренняя команда alias не использует ‘alias ’, если нет опции -p.

  46. При вызове внутренней команды set без опций не выводится имен и определений функций оболочки.

  47. При вызове внутренней команды set без опций она выводит значения переменных без кавычек, если они не включают метасимволов, даже если в результате возникают непечатаемые символы.

  48. Когда внутренняя команда cd вызывается в логическом режиме, а путь, созданный из $PWD и указанного в аргументе имени каталога, не указывает существующий каталог, cd будет давать отказ вместо перехода в физический режим.

  49. Когда внутренняя команда cd не может сменить каталог в результате того, что имя, созданное из $PWD и указанного аргументом каталога, превышает по размеру PATH MAX при преобразовании символьных ссылок, cd будет давать отказ вместо попытки использовать лишь предоставленное имя каталога.

  50. Внутренняя команда pwd проверяет совпадение выводимого значения с текущим каталогом, даже если такая проверка не запрошена с помощью опции -P.

  51. При выводе истории внутренняя команда fc не указывает наличие изменений в записях истории.

  52. По умолчанию fc использует редактор ed.

  53. Внутренние команды type и command не сообщают о нахождении неисполняемого файла, хотя оболочка будет пытаться выполнить такой файл, если он окажется единственным в $PATH.

  54. Режим редактирования vi будет вызывать редактор vi напрямую по команде v вместо проверки переменных $VISUAL и $EDITOR.

  55. При включенной опции xpg_echo оболочка Bash не будет пытаться интерпретировать какие-либо аргументы для эхо-вывода как опции. Каждый аргумент отображается после преобразования символов экранирования.

  56. Внутренняя команда ulimit использует размер блока 512 байтов для опций -c и -f.

  57. Получение сигнала SIGCHLD при установленной для него ловушке не прерывает внутреннюю команду и не ведет к немедленному возврату. Команда trap запускается однократно для каждого завершения работы потомка.

  58. Внутренняя команда read может быть прервана сигналом, для которого установлена ловушка. Если Bash получает захваченный сигнал при выполнении команды read, выполняется обработчик прерывания и read возвращает статус выхода больше 128.

  59. Bash удаляет статус завершенного фонового процесса из списка таких состояний после использования внутренней функции wait для получения статуса.

Имеется ряд аспектов поведения POSIX, которые Bash не реализует по умолчанию даже в режиме POSIX.

  1. Внутренняя команда fc проверяет $EDITOR как программу для редактирования записей истории, если не установлена переменная FCEDIT, вместо использования напрямую редактора ed. fc применяет ed, если переменная EDITOR не задана.

  2. Как отмечено выше, Bash требует включения опции xpg_echo для полного соответствия стандарту внутренней команды echo.

Bash можно настроить на соответствие стандарту POSIX по умолчанию путем указания —enable-strict-POSIX-default при сборке (10.8. Дополнительные возможности).

7. Управление заданиями

В этой главе описано управление заданиями в Bash и способы доступа к такому управлению.

7.1. Основы управления заданиями

Управление заданиями позволяет селективно останавливать (приостанавливать) выполнение процесса, а затем продолжать (восстанавливать) процесс. Пользователь обычно применяет эти средства через интерактивный интерфейс, предоставляемый вместе с драйвером терминала в ядре и Bash.

Оболочка связывает задание с каждый конвейером и хранит таблицу выполняемых в данный момент заданий, которую можно просматривать по команде jobs. При асинхронном запуске задания Bash выводит строку вида

[1] 25647

показывающую, что задание имеет номер 1, а идентификатор последнего процесса в конвейере, связанном с этим заданием, имеет значение 25647. Все процессы конвейера относятся к одному заданию. Bash использует абстракцию задания в качестве базы для управления заданиями.

Для упрощения реализации пользовательского интерфейса управления заданиями операционная система поддерживает понятие текущего идентификатора группы терминальных процессов. Члены этой группы (процессы, у который идентификатор группы совпадает с идентификатором группы терминальных процессов) получают генерируемые клавиатурой сигналы, такие как SIGINT. Эти процессы называют приоритетными (foreground). Фоновыми (background) процессами называют процессы, у которых идентификатор группы отличается о идентификатора текущей группы терминальных процессов. Такие процессы не подвержены воздействию клавиатурных сигналов. Только приоритетным процессам разрешено чтение с терминала (и запись при установке пользователем stty tostop). Фоновые процессы, которые пытаются читать с терминала (или писать при включенном stty tostop) передают сигнал SIGTTIN (SIGTTOU) через драйвер терминала в ядре, который приостанавливает процесс, если не будет перехвачен.

Если операционная система, где работает Bash, поддерживает управление заданиями, Bash позволяет упростить это. Ввод символов приостановки (обычно ^Z, Control-Z) при работе процесса, останавливает процесс и возвращает управление Bash. Ввод символов отложенной приостановки (обычно ^Y, Control-Y) останавливает процесс после попытки чтения с терминала и управление возвращается в Bash. Пользователь может менять состояние заданий, используя команду bg для продолжения задания в фоновом режиме, fg для продолжения в приоритетном режиме или kill для полного прекращения . Клавиши ^Z действуют сразу, но вызывают побочный эффект в форме отбрасывания ожидающих выходных данных и автозаполнения (typeahead).

Существует много способов ссылки на задания в оболочке. Символ % указывает спецификацию задания (jobspec). Задание с номером n можно указать как %n. Символы %% и %+ обозначают оболочку текущего задания, которое является последним, остановленным в приоритетном режиме или запущенным в фоновом. Отдельный символ % без указания номера задания также обозначает текущее задание. Предыдущее задания можно указать символами %-. Если имеется лишь одно задание, его можно указать как %+, так и %-. В относящемся к заданиям выводе (например, в выводе команд задания) текущее задание всегда помечается +, а предыдущее — ‘-’.

Задание можно указать с помощью префикса имени, использованного при запуске, или подстроки команды. Например, %ce указывает остановленное задание ce, а %?ce — задание, содержащее строку ce в команде. Если префикс или подстрока соответствуют нескольким заданиям, Bash сообщает об ошибке.

Задание можно сделать приоритетным (foreground) простым указанием его имени. Например %1 является синонимом fg %1 и переводит фоновое задание 1 в приоритетное. Аналогично, %1 & переводит задание 1 в фоновый режим как команда bg %1

Оболочка сразу узнает о смене состояния заданий. Обычно Bash ждет вывода приглашения перед выводом данных о смене состояния заданий, чтобы не прерывать другой вывод. Если включена опция -b внутренней команды set, Bash сообщает об изменения незамедлительно (4.3.1. Внутренняя команда set). Любая ловушка SIGCHLD выполняется для каждого завершаемого дочернего процесса.

При попытке завершения Bash с остановленным заданием (или работающим при включенной опции checkjobs — 4.3.2. Внутренняя команда shopt) выводится предупреждение, а при включенной опции checkjobs — список заданий с их статусом. После этого можно использовать команду для проверки статуса заданий. При повторной попытке выхода без промежуточных команд Bash не выдает предупреждений и просто прерывает остановленные задания.

Когда оболочка ждет выполнения задания или процесса по внутренней команде wait и управление заданиями включено, wait будет возвращать смену статуса задания. Опция -f будет заставлять wait ожидать завершения процесс или задания перед возвратом управления.

7.2. Внутренние средства управления заданиями

bg

bg [jobspec ...]

Возобновляет каждое остановленное задание jobspec в фоновом режиме как при запуске с оператором &. Если аргумент jobspec не задан, используется текущее задание. Статус возврата будет 0, если команда не была введена при отключенном управлении заданиями, указанное аргументом jobspec задание не было найдено или указанное задание было запущено без управления.

fg

fg [jobspec]

Возобновляет приоритетное (foreground) задание jobspec и делает его текущим. Если аргумент jobspec не задан, используется текущее задание. Статусом возврата будет статус команды, помещенной в режим foreground, или отличное от 0 значение, если управление заданиями отключено, при включенном управлении jobspec не указывает пригодного задания или указывает задание, запущенное без управления.

jobs

jobs [-lnprs] [jobspec]
jobs -x command [arguments]

Первая форма выводит список активных заданий. Опции приведены в таблице.

-l

Добавляет список идентификаторов процессов.

-n

Вывод информации лишь о заданиях, статус которых изменился с последнего уведомления пользователя.

-p

Вывод только идентификатора процесса лидера группы процессов.

-r

Вывод только работающих заданий.

-s

Вывод только остановленных заданий.

При указании jobspec вывод ограничивается информацией об указанном задании, иначе выводятся все.

При наличии опции -x команда jobs заменяет все jobspec в команде или аргументах идентификаторами групп процессов и выполняет команду command, передавая ей arguments и возвращая статус выхода.

kill

kill [-s sigspec] [-n signum] [-sigspec] jobspec или pid
kill -l|-L [exit_status]

Передает сигнал, указанный в sigspec или signum, процессу, заданному jobspec или pid. Аргумент sigspec указывает имя сигнала без учета регистра символов (префикс SIG не обязателен) или его номер. При отсутствии sigspec и signum используется SIGTERM. Имена сигналов выводит опция -l или -L. Если с этой опцией указаны аргументы, выводятся соответствующие им имена сигналов и возвращается статус 0. Статусом выхода служит номер сигнала или статус прерванного сигналом процесса. Статус возврата равен -, если успешно передан хотя бы один сигнал, и отличен от 0 при возникновении ошибки или наличии непригодной опции.

wait

wait [-fn] [jobspec или pid ...]

Задает ожидание завершения каждого процесса, указанного pid или jobspec, и возвращает статус последней выполненной команды. При указании jobspec ожидается выполнение всех процессов задания. Если задание не указано, ожидание применяется ко всем заданиям. Если аргументы не заданы, ожидание применяется ко всем активным в данный момент дочерним процессам и в итоге возвращается статус 0. При наличии опции -n команда wait ждет завершения любого из заданий и возвращает статус его выхода. При наличии опции -f и включенном управлении заданиями wait заставляет завершиться каждый процесс pid или задание jobspec перед возвратом его статуса вместо возврата управления при смене статуса. Если jobspec и pid не указывают активных дочерних процессов оболочки, возвращается статус 127.

disown

disown [-ar] [-h] [jobspec ... | pid ... ]

Без опций удаляет каждое задания jobspec из таблицы активных заданий. При наличии опции -h задания не удаляются из таблицы, а помечаются так, что сигнал SIGHUP не передается заданию при получении SIGHUP оболочкой. Если jobspec отсутствует и нет опции -a или -r, используется текущее задание. Без jobspec опция -a задает удаление или маркировку всех заданий, а -r без jobspec ограничивает операцию работающими заданиями.

suspend

suspend [-f]

Приостанавливает выполнение данной оболочки до получения сигнала SIGCONT. Оболочку входа (login) обычно приостановить нельзя, но опция -f позволяет форсировать приостановку.

При отключенном управлении заданиями внутренние команды kill и wait не принимают jobspec и нужно указывать pid.

7.3. Переменные управления заданиями

auto_resume

Эта переменная определяет взаимодействие оболочки с пользователем и управлением заданиями. При наличии переменной простые команды из одного слова считаются кандидатами на возобновление имеющегося задания. Двусмысленность не допускается и при наличии нескольких заданий, начинающихся с набранной строки, будет выбрано то, к которому наименее давно был доступ. Именем остановленного задания в этом контексте является командная строка, использованная для запуска задания. Если переменная имеет значение exact, строка должна в точности совпадать с именем остановленного задания, а при значении substring достаточно совпадения введенной строки с частью имени остановленного задания. Значение substring обеспечивает функциональность, аналогичную идентификатору задания %? (7.1. Основы управления заданиями). При установке в переменной любого другого значения введенная строка должна быть префиксом имени остановленного задания, аналогично идентификатору задания %.

8. Редактирование командной строки

В этой главе описаны базовые возможности командного интерфейса gnu для редактирования строк. Редактирование выполняется с помощью библиотеки Readline, используемой разными программами, включая Bash. Редактирование командной строки включено по умолчанию для интерактивной оболочки, если при вызове не была задана опция —noediting. Редактирование строк применяется также с опцией -e для внутренней команды read (4.2. Внутренние команды bash). По умолчанию команды редактирования строк похожи на команды Emacs, но доступен также интерфейс со стилем редактора vi. Редактирование строк можно включить в любой момент опцией -o emacs или -o vi внутренней команды set (4.3.1. Внутренняя команда set) или отключить опцией +o emacs или +o vi команды set.

8.1. Введение в редактирование строк

В приведенных ниже описаниях C-k означает Control-K, т. е. нажатие клавиши k при удерживаемой клавише Control. M-k указывает Meta-K, т. е. нажатие клавиши k при удерживаемой клавише Meta (если она имеется). Клавиша Meta на клавиатуре часто обозначена ALT. На клавиатурах с двумя клавишами ALT (обычно слева и справа от клавиши пробела) левая клавиша ALT обычно служит в качестве клавиши Meta. Правую клавишу ALT также можно настроить в качестве Meta или иного модификатора (например, Compose для ввода символов со знаком ударения).

Если нет клавиш Meta, ALT или иной клавиши, работающей как Meta, идентичные последовательности можно создавать, нажимая клавишу ESC, а затем k.

M-C-k означает Meta-Control-k, т. е. нажатие клавиши k при удерживаемых клавишах Meta и Control.

Для некоторых клавиш применяются специальные имена. В частности, клавиши DEL, ESC, LFD, SPC, RET, TAB обозначаются по именам в тексте документа и файле инициализации (8.3. Файл инициализации Readline). Если на клавиатуре нет клавиши LFD, ее заменит нажатие C-j. Клавиша RET может называться Return или Enter.

8.2. Взаимодействие с Readline

Зачастую при работе в интерактивной сессии можно заметить ошибку в начале набранной строки, уже введя достаточно много символов. Библиотека Readline обеспечивает множество команд для манипуляций с набранным текстом, позволяя исправлять ошибки, добавлять или удалять текст. Для использования команд редактирования нужно переместить курсор в нужное место строки и удалить ненужные символы, внести изменения или добавить пропущенные символы. Добившись нужного результата, просто нажмите клавишу RET. Перемещать курсор в конец строки перед нажатием RET не требуется.

8.2.1. Основы Readline

Для ввода символов в строку нужно просто набрать их и символ появится в позиции указанной курсором, а курсор будет перемещен вправо. При ошибочном ввода можно использовать символ стирания для возврата и удалить ошибочный символ. Иногда ошибка может остаться незамеченной сразу и в таких случаях можно использовать клавиши C-b для перемещения курсора влево и исправления ошибки. После этого курсор можно переместить вправо клавишами C-f.

При добавлении символов в середину строки символы справа от добавляемых смещаются вправо, освобождая место для новых. При удалении текста символы справа от удаляемых смещаются влево, занимая освободившееся место. Ниже приведены наиболее важные команды редактирования строк.

C-b

Сдвиг курсора на одну позицию назад (влево).

C-f

Сдвиг курсора на одну позицию вперед (вправо).

DEL или Backspace

Удаление символа слева от курсора.

C-d

Удаление символа в позиции курсора2.

Символьные клавиши

Вставка символа в позицию курсора.

C-_ или C-x C-u

Отмена последней команды редактирования. Можно отметить все, вплоть до пустой строки.

8.2.2. Команды перемещения в Readline

В дополнение к описанным выше командам имеются комбинации клавиш быстрого перемещения.

C-a

Перенос курсора в начало строки.

C-e

Перенос курсора в конец строки.

M-f

Перенос курсора на одно слово вперед (вправо). Словом считается последовательность букв и цифр.

M-b

Перенос курсора на одно слово назад (влево).

C-l

Очистка экрана с выводом текущей строки в верхней позиции.

Отметим, что C-f перемещает курсов на один символ, а M-f — на одно слово. Это свободное соглашение, связывающее клавишу Control с символами, а Meta — со словами.

8.2.3. Команды уничтожения в Readline

Уничтожение текста означает его удаление из строки с сохранением для последующего применения (обычно путем восстановления — yanking). В современной терминологии используются cut и paste вместо kill и yank. Если описание команды говорит, что она «убивает» текст, можно быть уверенным в возможности вернуть его в то же или иное место.

При использовании команды kill текст сохраняется в буфере kill-ring. Произвольное число уничтожений текста сохраняется вместе и текст можно восстановить. Буфер не связан с конкретными строками и уничтоженный текст можно потом поместить в ту же или другую строку. Команды уничтожения текста приведены ниже.

C-k

Уничтожает текст от курсора до конца строки.

M-d

Уничтожает текст от курсора до конца текущего слова или до конца следующего слова, если курсор находится между словами. Границы слов совпадают с используемыми M-f.

M-DEL

Уничтожает текст от курсора до начала текущего слова или до начала предыдущего слова, если курсор находится между словами. Границы слов совпадают с используемыми M-b.

C-w

Уничтожает текст от курсора до предыдущего пробела. Это отличается от M-DEL различием в границах слов.

Ниже приведены команды восстановления текста (yank), когда в строку копируется уничтоженный последним текст.

C-y

Поместить уничтоженный последним текст, начиная с позиции курсора.

M-y

«Провернуть» kill-ring и восстановить новый «верхний» текст. Команда работает только после C-y или M-y.

8.2.4. Аргументы Readline

Можно передать команде Readline числовые аргументы, которые могут служить счетчиками повторов, а иногда содержат знак, который меняет действие команды. При передаче отрицательного аргумента команде, которая обычно действует в прямом направлении, эта команда будет применена в обратном направлении. Например, для уничтожения текста до начала строки можно использовать M— C-k.

Общим способом передачи числовых аргументов является нажатие клавиши Meta с цифровой клавишей перед командой. Если вместо первой цифры будет нажата клавиша -, аргумент получит отрицательное значение. После нажатия Meta-цифра можно нажать остальные цифры, а затем ввести команду. Например, для передачи команде C-d аргумента 10 можно нажать клавиши M-1 0 C-d, что приведет к удалению следующих после курсора 10 символов.

8.2.5. Поиск команд в истории

Readline поддерживает команды для поиска в истории команд (9.1. Средства Bash History)строк, содержащих указанную подстроку. Поддерживается два режима поиска — инкрементный и неинкрементный.

Инкрементный поиск начинается до завершения пользователем ввода искомой строки. По мере ввода символов Readline отображает следующую запись истории, соответствующую набранному. Для поиска в прямом направлении по списку истории служит команда C-s, в обратном — C-r. Для завершения инкрементного поиска служат символы из переменной isearch-terminators. Если значение переменной не задано, поиск можно завершить клавишами ESC и C-J, а C-g будет прерывать инкрементный поиск и восстанавливать исходную строку. По завершении поиска запись истории, содержащая введенные символы, становится текущей строкой.

Для перехода к другим записям истории, соответствующим набранному, служат команды C-r и C-s. Любая другая комбинация клавиш, с которой связана команда Readline, будет завершать поиск и выполнять команду. Например, клавиша RET ведет к завершению поиска и восприятию команды с ее выполнением. Команды перемещения будут прерывать поиск и переводить в режим редактирования найденной строки. Readline запоминает последнюю строку инкрементного поиска и при нажатии C-r подряд без промежуточных символов, определяющих поиск, используется такая строка.

При неинкрементном поиске искомая строка считывается полностью до начала поиска в истории. Строка поиска может быть введена пользователем или быть частью содержимого текущей строки.

8.3. Файл инициализации Readline

Хотя библиотека Readline распространяется с набором привязок клавиш в стиле Emacs, можно использовать другой набор привязок. Любой пользователь может настроить программы, использующие Readline, помещая команды в файл inputrc (обычно в домашнем каталоге). Имя этого файла берется из значения переменной окружения INPUTRC, если переменная не задана, используется ~/.inputrc. Если указанный файл отсутствует или недоступен для чтения, используется файл /etc/inputrc.

При запуске программы, использующей библиотеку Readline, считывается файл инициализации и задаются привязки клавиш. Кроме того, команда C-x C-r перечитывает файл инициализации, активизируя все внесенные в него изменения.

8.3.1. Синтаксис файла инициализации

Имеется небольшое число базовых конструкций, разрешенных в файле инициализации Readline. Пустые строки в файле игнорируются, строки, начинающиеся с символа #, являются комментариями. Строки, начинающиеся с символа $, задают условные конструкции (8.3.2. Условные конструкции в файле инициализации). Остальные строки задают переменные и привязки клавиш.

Установка переменных

Можно изменить поведение Readline, меняя значения переменных в файле инициализации командой set.

set variable value

Например, для смены стиля команд Emacs на стиль vi можно указать

set editing-mode vi

Имена и значения переменных, когда это возможно, не учитывают регистр символов. Нераспознанные переменные игнорируются. Логические переменные (те, что могут иметь значения on или off) устанавливаются в on, если имеют значение null (пусто), on (без учета регистра) или 1. Все прочие значения ведут к установке off.

Команда bind -V выводит имена и значения текущих переменных Readline (4.2. Внутренние команды bash). Поведение библиотеки при работе определяется прежде всего перечисленными ниже переменными.

bell-style

Управляет поведением Readline при «звонках» в терминал (bell). При значении none звонок не используется, visible задает использование видимого звонка, если он доступен. Принятое по умолчанию значение audible задает использование звукового сигнала.

bind-tty-special-chars

Принятое по умолчанию значение on ведет к попытке Readline привязать управляющие символы с особой обработкой драйвером терминала в ядре к их эквивалентам в Readline.

blink-matching-paren

При значении on Readline пытается кратковременно переместить курсов к открывающей скобке при вводе закрывающей (по умолчанию off).

colored-completion-prefix

Если установлено значение on, Readline при перечислении дополнений указывает общий префикс набора возможных дополнений другим цветом в соответствии с переменной среды LS_COLORS (по умолчанию off).

colored-stats

Если установлено значение on, Readline выводит возможные дополнения с выделением типов цветом в соответствии с переменной среды LS_COLORS (по умолчанию off).

comment-begin

Текст для вставки в начало строки по команде insert-comment (по умолчанию #).

completion-display-width

Число символов в строке экрана, используемых для вывода возможных совпадений при дополнении. Отрицательные и превышающие ширину экрана значения игнорируются. Значение 0 задает вывод совпадений по одному в строке. По умолчанию -1.

completion-ignore-case

Если установлено значение on, Readline учитывает регистр символов при сопоставлении имен файлов и дополнении (по умолчанию off).

Completion-map-case

Если установлено значение on и включено completion-ignore-case, Readline считает символы дефиса (-) и подчеркивания (_) эквивалентными при сопоставлении имен файлов и дополнении без учета регистра (по умолчанию off).

completion-prefix-display-length

Число символов общего префикса списка возможных дополнений, которые выводятся без изменения. При положительном значении более длинные общие префиксы заменяются многоточием.

completion-query-items

Число возможных дополнений, при котором у пользователя спрашивают о выводе списка, если набор дополнений больше. При меньшем числе список выводится без вопроса. Значение должно быть неотрицательным целым числом, при отрицательных значениях Readline не будет задавать вопрос (по умолчанию 100).

convert-meta

При значении on Readline будет преобразовывать символы с установленным старшим (8) битом в последовательность ASCII без старшего бита с ESC-префиксом, а затем — в последовательность с префиксом meta. По умолчанию установлено значение on, но оно будет заменено на off, если установленный язык включает 8-битовые символы.

disable-completion

При значении on Readline будет запрещать дополнение слов. Символы дополнения будут помещаться в строку как при самовставке (по умолчанию off).

echo-control-characters

При заданном по умолчанию значении on и поддержке операционной системой Readline будет выводить эхо-символы по сигналам клавиатуры.

editing-mode

Управляет используемыми привязками клавиш и может принимать значение emacs или vi. По умолчанию Readline использует режим Emacs.

emacs-mode-string

При включенном режиме show-mode-in-prompt эта строка (по умолчанию @) выводится непосредственно перед последней строкой основного приглашения в режиме emacs. Значение преобразуется подобно привязкам клавиш и доступны стандартные префиксы Meta- и Control, а также экранирование \. Комбинации \1 и \2 указывают начало и конец последовательности непечатаемых символов, которую можно включить в последовательность управления терминалом в строке режима.

enable-bracketed-paste

Если установлено значение on, Readline будет настраивать терминал на размещение каждой вставки в буфере редактирования как отдельной строки символов вместо того, что считать каждый символ вводом с клавиатуры. Это предотвращает трактовку введенных символов как команд редактирования (по умолчанию off).

enable-keypad

Если установлено значение on, Readline пытается включить клавиатуру приложения при ее вызове. Некоторым системам это нужно для включения клавиш со стрелками. По умолчанию off.

enable-meta-key

Если установлено значение on, Readline пытается включить любую клавишу модификатора Meta, поддержку которой заявляет терминал. На многих терминалах клавиша Meta служит для ввода 8-битовых символов. По умолчанию on.

expand-tilde

Значение on задает преобразование тильды при попытке Readline дополнять слова (по умолчанию off).

history-preserve-point

При значении on код истории пытается установить курсор в одну позицию для каждой строки истории,извлекаемой командами previous-history и next-history (по умолчанию off).

history-size

Максимальное число записей в списке истории. При значении 0 имеющиеся записи удаляются, при отрицательных значениях размер списка не ограничивается (принято по умолчанию). При задании в переменной нечислового значения устанавливается предел 500 записей.

horizontal-scroll-mode

Значение on задает горизонтальную прокрутку текста при размере строки, превышающем размер экрана, вместо перехода на новую строку (по умолчанию off).

input-meta

Если установлено значение on, Readline включает 8-битовый ввод (не сбрасывает старший бит), независимо от заявленной терминалом его поддержки. По умолчанию установлено off, но Readline будет устанавливать on, если выбранный язык использует 8-битовые символы. Переменную называют также meta-flag.

isearch-terminators

Строка символов прерывания инкрементного поиска без последующего выполнения команды из дальнейших символов (8.2.5. Поиск команд в истории). Если переменная не задана, используется ESC или C-J.

keymap

Задает представление Readline о текущей раскладке клавиатуры для привязки клавиш. Встроенные таблицы называются emacs, emacs-standard, emacs-meta, emacs-ctlx, vi, vi-move, vi-command, vi-insert. Раскладки vi и vi-command (vi-move является синонимом), а также emacs и emacs-standard эквивалентны. Приложения могут добавлять свои имена. По умолчанию применяется emacs. Переменная editing-mode также влияет на принятую по умолчанию раскладку.

keyseq-timeout

Время ожидания ввода (мсек, по умолчанию 500) символа при считывании неоднозначной последовательности нажатий клавиш (непонятно, завершен ли ввод последовательности). По истечении времени Readline считает последовательность завершенной. Readline использует значение для определения доступности ввода из текущего источника (по умолчанию rl_instream). Если переменная не содержит положительное число, Readline будет ждать нажатия другой клавиши для принятия решения.

mark-directories

При значении on (принято по умолчанию) имена каталогов завершаются символом \.

mark-modified-lines

Значение on заставляет Readline выводить символ * в начале строк истории, которые были изменены (по умолчанию off).

mark-symlinked-directories

При значении on к полным именам, которые являются символьными ссылками на каталог, добавляется \ в зависимости от mark-directories (по умолчанию off).

match-hidden-files

Значение on (принято по умолчанию) заставляет Readline сопоставлять имена файлов, начинающиеся с точки (скрытые) при дополнении имен файлов. При значении off пользователь должен сам указать точку в начале.

menu-complete-display-prefix

Если установлено значение on, при дополнении меню выводится общий префикс списка возможных дополнений (может быть пустым) перед прокручиванием списка (по умолчанию off).

output-meta

Если установлено значение on, Readline будет выводить символы с восьмым битом напрямую, без Meta-префиксов. По умолчанию установлено значение off, но Readline устанавливает on для языков с 8-битовыми символами.

page-completions

Если установлено значение on (принято по умолчанию), Readline использует внутреннее разбиение на страницы в стиле more при отображении многостраничных списков возможных дополнений.

print-completions-horizontally

При значении on Readline выводит дополнения по горизонтали, сортируя в алфавитном порядке, вместо построчного вывода (по умолчанию off).

revert-all-at-newline

Если установлено значение on, Readline отменяет все изменения в строках истории перед возвратом при выполнении accept-line. По умолчанию строки могут быть изменены и сохраняют отдельные списки отмены изменений между вызовами readline.

show-all-if-ambiguous

При установке on для слов с несколькими вариантами дополнения совпадения выводятся сразу вместо подачи звукового сигнала (по умолчанию off).

show-all-if-unmodified

При установке on для слов с несколькими вариантами дополнения без возможности частичного завершения (варианты не имеют общего префикса) совпадения выводятся сразу вместо подачи звукового сигнала (по умолчанию off).

show-mode-in-prompt

Установка значения on добавляет в начало приглашения строку, указывающую режим редактирования (emacs, vi command, vi insertion), которую пользователь может изменить (например, emacs-mode-string). По умолчанию off.

skip-completed-text

Установка значения on меняет принятое по умолчанию поведение при вставке в строку одного совпадения в середине слова. При включенном режиме readline не вставляет символы из завершения, соответствующие символам после указателя в дополняемом слове, поэтому части слов после курсора не дублируются. Например, попытка дополнить после символа e слово Makefile даст в результате Makefile, а не Makefilefile, при наличии одного завершения (по умолчанию off).

vi-cmd-mode-string

Если переменная show-mode-in-prompt включена, эта строка (по умолчанию (cmd)) выводится непосредственно перед последней строкой основного приглашения в командном режиме vi. Значение преобразуется подобно привязке клавиш, поэтому доступен стандартный набор префиксов Meta и Control, а также \-экранирование. Комбинации \1 и \2 указывают начало и конец последовательности непечатаемых символов, которую можно включить в последовательность управления терминалом в строке режима.

vi-ins-mode-string

Если переменная show-mode-in-prompt включена, эта строка (по умолчанию (ins)) выводится непосредственно перед последней строкой основного приглашения в режиме вставки vi. Значение преобразуется подобно привязке клавиш, поэтому доступен стандартный набор префиксов Meta и Control, а также \-экранирование. Комбинации \1 и \2 указывают начало и конец последовательности непечатаемых символов, которую можно включить в последовательность управления терминалом в строке режима The default is ‘(ins)’.

visible-stats

При установке значения on символ, указывающий тип файла, добавляется к имени файла при выводе возможных дополнений (по умолчанию off).

Привязка клавиш

Синтаксис привязки клавиш управления в файле инициализации достаточно прост. Ниже приведены таблицы имен команд, принятые по умолчанию привязки клавиш и краткие описания действия команд.

Когда имя команды понятно, нужно просто найти строку в файле инициализации или добавить ее и указать комбинацию клавиш для привязки, отделив ее двоеточием от имени команды. Пробел между именем и двоеточием будет считаться частью имени. Клавиши можно указывать разными способами. Кроме команд readline позволяет связать комбинацию клавиш со строкой, которая будет вставляться при нажатии клавиш (макрос).

Команда bind -p выводит имена функций Readline с их привязками в формате, который подходит для файла инициализации (4.2. Внутренние команды bash).

keyname: function-name или macro

Поле keyname задает имя клавиши на английском языке, например,

Control-u: universal-argument
Meta-Rubout: backward-kill-word
Control-o: "> output"

В этом примере C-u привязывается к функции universal-argument, M-DEL — к функции backward-kill-word, а C-o — к макросу, указанному справа (вставка ‘> output’ в строку).

В привязках распознаются символьные имена клавиш DEL, ESC, ESCAPE, LFD, NEWLINE, RET, RETURN, RUBOUT, SPACE, SPC, TAB.

«keyseq»: function-name or macro

Поле keyseq отличается от keyname тем, что позволяет указывать всю последовательность клавиш в двойных кавычках. Это позволяет использовать некоторые комбинации в стиле Emacs, но имена специальных символов не распознаются.

"\C-u": universal-argument
"\C-x\C-r": re-read-init-file
"\e[11~": "Function Key 1"

В примере комбинация C-u снова привязана к функции universal-argument, C-x C-r — к функции re-read-init-file, а ESC [ 1 1 ~ служит для вставки текста Function Key 1.

При указании комбинаций доступны приведенные ниже escape-последовательности в стиле Emacs.

\C-

Префикс Control

\M-

Префикс Meta

\e

Символ экранирования (escape)

\\

Обратная дробная черта

Символ двойной кавычки

\’

Символ одинарной кавычки или апостроф

В дополнение к последовательностям в стиле Emacs поддерживается \-экранирование, приведенное ниже.

\a

Звонок (bell)

\b

Забой (backspace)

\d

Удаление (delete)

\f

Перевод страницы (form feed)

\n

Перевод строки (newline)

\r

Возврат каретки (carriage return)

\t

Горизонтальная табуляция

\v

Вертикальная табуляция

\nnn

8-битовый символ с восьмеричным кодом nnn (1 — 3 цифры)

\xHH

8-битовый символ с шестнадцатеричным кодом HH (1 или 2 цифры)

При вводе текста в определении макроса должны применяться одинарные или двойные кавычки. Текст без кавычек считается именем функции. В теле макроса описанное выше \-экранирование преобразуется. Символ \ экранирует в определении макроса любые символы, включая одинарные и двойные кавычки. Например, для привязки C-x \ к вставке в строку одного символа \ служит «\C-x\\»: «\\».

8.3.2. Условные конструкции в файле инициализации

Readline реализует функции, похожие на условную компиляцию в препроцессорах C, которые позволяют задавать переменные и привязки клавиш с учетом проверки условий. Анализатор понимает 4 директивы, описанные ниже.

$if

Конструкция $if позволяет создавать привязки на основе режима редактирования, применяемого терминала или приложения, использующего Readline. Проверяемый текст после оператора сравнения продолжается до конца строки, если явно не указано иное. Для выделения текста не требуется специальных символов.

mode

Форма mode= директивы $if служит для проверки работы Readline в режиме emacs или vi и может применяться с командой set keymap, например, для привязки раскладок emacs-standard и emacs-ctlx только при работе Readline в режиме emacs.

term

Форма term= может служить для включения раскладок под определенные терминалы, возможно с учетом функциональных клавиш терминала. Слово справа от знака = сравнивается с полным именем терминала и частью имени до первого символа -. Это позволяет, например, указать sun для соответствия терминалам sun и sun-cmd.

version

Проверка version может служить для работы с учетом версии Readline. Поле version преобразуется в текущую версию Readline. Набор операторов сравнения включает = (и ==), !=, <=, >=, <, >. Номер версии, указываемый справа от оператора, состоит из старшей части, необязательной точки и необязательной младшей части (например, 7.1). Если младшая часть не указана, предполагается 0. Оператор может отделяться пробелами от строки version и от номера версии. Приведенный ниже пример устанавливает переменную для Readline версии 7.0 и выше.

$if version >= 7.0
set show-mode-in-prompt on
$endif

application

Конструкция application служит для задания установок в зависимости от приложения. Каждая программа, использующая библиотеку Readline, задает свое имя, что позволяет выполнить сравнение. Например, приведенная ниже команда добавляет комбинацию, заключающую текущее и предыдущее слово в кавычки при использовании Bash.

$if Bash
"\C-xq": "\eb\"\ef\""
$endif

variable

Конструкция variable обеспечивает простую проверку равенства для переменных Readline, поддерживая операторы =, == и !=. Имя переменной должно, а значение может отделяться от оператора пробелом. Проверки возможны для строковых и логических (on или off) переменных. Ниже приведен пример проверки mode=emacs.

$if editing-mode == emacs
set show-mode-in-prompt on
$endif

$endif

Эта директива завершает конструкцию $if.

$else

Команды этой ветви конструкции $if выполняются при отрицательном результате проверки.

$include

Эта директива принимает аргументом имя файла и читает из него команды и привязки. Например,

	$include /etc/inputrc

8.3.3. Пример файла инициализации

# This file controls the behaviour of line input editing for
# programs that use the GNU Readline library. Existing
# programs include FTP, Bash, and GDB.
#
# You can re-read the inputrc file with C-x C-r.
# Lines beginning with ’#’ are comments.
#
# First, include any system-wide bindings and variable
# assignments from /etc/Inputrc
$include /etc/Inputrc
#
# Set various bindings for emacs mode.
set editing-mode emacs
$if mode=emacs
Meta-Control-h: 	backward-kill-word Text after the function name is ignored
#
# Arrow keys in keypad mode
#
#"\M-OD":	backward-char
#"\M-OC":	forward-char
#"\M-OA":	previous-history
#"\M-OB":	next-history
#
# Arrow keys in ANSI mode
"\M-[D":	backward-char
"\M-[C":	forward-char
"\M-[A":	previous-history
"\M-[B":	next-history
#
# Arrow keys in 8 bit keypad mode
#
#"\M-\C-OD":	backward-char
#"\M-\C-OC":	forward-char
#"\M-\C-OA":	previous-history
#"\M-\C-OB":	next-history
#
# Arrow keys	in 8 bit ANSI mode
#
#"\M-\C-[D":	backward-char
#"\M-\C-[C":	forward-char
#"\M-\C-[A":	previous-history
#"\M-\C-[B":	next-history
C-q: quoted-insert

$endif
# An old-style binding. This happens to be the default.
TAB: complete
# Macros that are convenient for shell interaction
$if Bash
# edit the path
"\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
# prepare to type a quoted word --
# insert open and close double quotes
# and move to just after the open quote
"\C-x\"": "\"\"\C-b"
# insert a backslash (testing backslash escapes
# in sequences and macros)
"\C-x\\": "\\"
# Quote the current or previous word
"\C-xq": "\eb\"\ef\""
# Add a binding to refresh the line, which is unbound
"\C-xr": redraw-current-line
# Edit variable on current line.
"\M-\C-v": "\C-a\C-k$\C-y\M-\C-e\C-a\C-y="
$endif
# use a visible bell if one is available
set bell-style visible
# don’t strip characters to 7 bits when reading
set input-meta on
# allow iso-latin1 characters to be inserted rather
# than converted to prefix-meta sequences
set convert-meta off
# display characters with the eighth bit set directly
# rather than as meta-prefixed characters
set output-meta on
# if there are more than 150 possible completions for
# a word, ask the user if he wants to see all of them
set completion-query-items 150
# For FTP
$if Ftp
"\C-xg": "get \M-?"
"\C-xt": "put \M-?"
"\M-.": yank-last-arg
$endif

8.4. Клавиатурные команды Readline

В этом разделе описаны команды Readline, которые могут быть связаны с комбинациями клавиш. Можно посмотреть список привязок с помощью команды bind -P или bind -p (в более сжатом формате, пригодном для файла inputrc (4.2. Внутренние команды bash). Имена команд без комбинации клавиш по умолчанию не привязаны. В последующих описаниях точка указывает текущую позицию курсора, а метка (mark) — позицию курсора, сохраненную командой set-mark. Текст между точкой и меткой называют также областью (region).

8.4.1. Команды перемещения

beginning-of-line (C-a)

Перемещение в начало текущей строки.

end-of-line (C-e)

Перемещение в конец строки.

forward-char (C-f)

Перемещение на 1 символ вперед.

backward-char (C-b)

Перемещение на 1 символ назад.

forward-word (M-f)

Перемещение в конец следующего слова (последовательность букв и цифр).

backward-word (M-b)

Перемещение в начало текущего или предыдущего слова (последовательность букв и цифр).

shell-forward-word ()

Перемещение в конец следующего слова (слова ограничиваются метасимволами без кавычек).

shell-backward-word ()

Перемещение в начало текущего или предыдущего слова (слова ограничиваются метасимволами без кавычек).

previous-screen-line ()

Пытается поместить указатель в ту же позицию предыдущей экранной строки. Это не будет работать, если текущая строка Readline не занимает нескольких экранных строк или позиция указателя не превышает сумму размера приглашения и ширины экрана.

next-screen-line ()

Пытается поместить указатель в ту же позицию следующей экранной строки. Это не будет работать, если текущая строка Readline не занимает нескольких экранных строк или позиция указателя не превышает сумму размера приглашения и ширины экрана.

clear-screen (C-l)

Очищает экран и заново выводит текущую строку наверху экрана.

redraw-current-line ()

Обновляет текущую строку. По умолчанию не имеет привязки.

8.4.2. Команды работы с историей

accept-line (Newline или Return)

Принимает строку независимо от позиции курсора. Непустая строка добавляется в историю в соответствии с переменными HISTCONTROL и HISTIGNORE. Измененная строка истории восстанавливается.

previous-history (C-p)

Возврат в списке истории с выборкой предыдущей команды.

next-history (C-n)

Перемещение вперед по списку истории с выборкой следующей команды.

beginning-of-history (M-<)

Перемещение к первой строке истории.

end-of-history (M->)

Перемещение в конец истории ввода (т. е. к вводимой в данный момент строке).

reverse-search-history (C-r)

Инкрементный поиск по списку истории от текущей строки к началу (вверх).

forward-search-history (C-s)

Инкрементный поиск по списку истории от текущей строки к концу (вниз).

non-incremental-reverse-search-history (M-p)

Неинкрементный поиск заданной пользователем строки по списку истории от текущей строки к началу (вверх).

non-incremental-forward-search-history (M-n)

Неинкрементный поиск заданной пользователем строки по списку истории от текущей строки к концу (вниз).

history-search-forward ()

Неинкрементный поиск вперед по истории строки символов от начала текущей строки до курсора. Искомая строка должна быть началом строки истории. По умолчанию команда не привязана.

history-search-backward ()

Неинкрементный поиск назад по истории строки символов от начала текущей строки до курсора. Искомая строка должна быть началом строки истории. По умолчанию команда не привязана.

history-substring-search-forward ()

Неинкрементный поиск вперед по истории строки символов от начала текущей строки до курсора. Искомая строка может находиться в любом месте строки истории. По умолчанию команда не привязана.

history-substring-search-backward ()

Неинкрементный поиск назад по истории строки символов от начала текущей строки до курсора. Искомая строка может находиться в любом месте строки истории. По умолчанию команда не привязана.

yank-nth-arg (M-C-y)

Вставка первого аргумента в предыдущую команду (обычно второе слово предыдущей строки) в позиции курсора. При наличии аргумента n вставляется n-е слово из предыдущей команды (отсчет с 0), при отрицательном значении вставляется n-е слово от конца предыдущей команды. После вычисления n аргумент извлекается как при преобразовании истории !n.

yank-last-arg (M-. или M-_)

Вставка последнего аргумента в предыдущую команду (последнее слово предыдущей записи истории). С числовым аргументом похожа на yank-nth-arg. Последовательные вызовы yank-last-arg перемещают назад по списку истории, вставляя последнее (или заданное аргументом первого вызова) слово в каждую строку по очереди. Числовой аргумент этих последовательных вызовов определяет направление в списке истории. Используются средства преобразования истории для извлечения последнего аргумента как при задании !$.

8.4.3. Команды изменения текста

end-of-file (обычно C-d)

Символ, указывающий конец файла, как установлено, например, stty. Если символ прочитан при отсутствии других символов в строке и курсор находится в начале строки, Readline считает это завершением ввода и возвращает eof.

delete-char (C-d)

Удаляет символ в позиции курсора. Если функция привязана к той же комбинации, как символ tty eof (обычно C-d), действие идентично предыдущей команде.

backward-delete-char (Rubout3)

Удаляет символ перед курсором (слева). Числовой аргумент задает уничтожение (kill) символов вместо удаления.

forward-backward-delete-char ()

Удаляет символ в позиции курсора, если это не конец строки, когда удаляется символ перед курсором (слева). По умолчанию команда не привязана.

quoted-insert (C-q или C-v)

Добавляет следующий введенный символ в строку дословно, например, как комбинация вставки символов C-q.

self-insert (a, b, A, 1, !, …)

Вставляет введенный символ (самое себя).

bracketed-paste-begin ()

Эта функция предназначена для привязки к последовательности «вставка в скобках» (bracketed paste), передаваемой некоторыми терминалами, и такая привязка задана по умолчанию. Это позволяет Readline вставлять текст одним блоком без трактовки каждого символа как ввода с клавиатуры. Символы вставляются как с привязкой self-insert вместо выполнения команд редактирования.

transpose-chars (C-t)

Меняет местами символы перед курсором (слева) и в позиции курсора, а затем перемещает курсор на одну позицию вперед (вправо). Если курсор находится в конце строки, просто меняются местами 2 последних символа. Отрицательные аргументы не дают эффекта.

transpose-words (M-t)

Меняет местами слово в позиции курсора и предшествующее ему слово, устанавливая курсор в конец второго (правого) слова. Если курсор находится в конце строки, просто меняются местами 2 последних слова строки.

upcase-word (M-u)

Переводит в верхний регистр текущее или следующее слово. С отрицательным аргументом переводит в верхний регистр предыдущее слово без перемещения курсора.

downcase-word (M-l)

Переводит в нижний регистр текущее или следующее слово. С отрицательным аргументом переводит в верхний регистр предыдущее слово без перемещения курсора.

capitalize-word (M-c)

Меняет на заглавную первую букву текущего или следующего слова. С отрицательным аргументом переводит в верхний регистр первую букву предыдущего слова без перемещения курсора.

overwrite-mode ()

Переключает режим вставки-замены. С явным положительным числовым аргументом переходит в режим замены, с явным неположительным — в режим вставки. Команда работает только в режиме emacs, а в режиме vi переключение происходит иначе. Каждый вызов readline() начинается в режиме вставки. В режиме замены введенный символ помещается в текущую позицию вместо имеющегося. Символы, привязанные к backward-delete-char заменяют символ перед курсором (слава) пробелом. По умолчанию команда не привязана.

8.4.4. Уничтожение и восстановление

kill-line (C-k)

Уничтожает текст от курсора до конца строки.

backward-kill-line (C-x Rubout)

Уничтожает текст от курсора до начала текущей строки.

unix-line-discard (C-u)

Уничтожает текст от курсора до начала текущей строки.

kill-whole-line ()

Уничтожает все символы текущей строки независимо от позиции курсора. По умолчанию не привязана.

kill-word (M-d)

Уничтожает текст от курсора до конда текущего или следующего (если курсор находится между словами) слова. Границы слов такие же как для forward-word.

backward-kill-word (M-DEL)

Уничтожает слово перед курсором. Границы слов такие же как для forward-word.

shell-kill-word ()

Уничтожает текст от курсора до конда текущего или следующего (если курсор находится между словами) слова. Границы слов такие же как для shell-forward-word.

shell-backward-kill-word ()

Уничтожает слово перед курсором. Границы слов такие же как для shell-backward-word.

unix-word-rubout (C-w)

Уничтожает слово перед курсором, используя пробел в качестве границы. Текст сохраняется в kill-ring.

unix-filename-rubout ()

Уничтожает слово перед курсором, используя пробел и / в качестве границы. Текст сохраняется в kill-ring.

delete-horizontal-space ()

Удаляет пробелы и символы табуляции по обе стороны курсора. По умолчанию не привязана.

kill-region ()

Уничтожает текст в текущей области (region). По умолчанию не привязана.

copy-region-as-kill ()

Копирует текст области в kill-буфер с возможностью вставить его позже. По умолчанию не привязана.

copy-backward-word ()

Копирует слово перед курсором в kill-буфер. Границы слов как для backward-word. По умолчанию не привязана.

copy-forward-word ()

Копирует слово после курсора в kill-буфер. Границы слов как для forward-word. По умолчанию не привязана.

yank (C-y)

Помещает верхнюю запись kill-ring в позицию курсора.

yank-pop (M-y)

Прокручивает kill-ring и извлекает новую верхнюю запись. Может использоваться лишь вслед за yank или yank-pop.

8.4.5. Задание числовых аргументов

digit-argument (M-0, M-1, … M—)

Добавляет введенную цифру к имеющемуся аргументу или создает новый аргумент. M— создает отрицательный аргумент.

universal-argument ()

Обеспечивает другой способ задания аргумента. Если за этой командой следует одна или несколько цифр (возможно со знаком — в начале), эти цифры определяют аргумент. Если за командой следуют цифры, повторное выполнение universal-argument завершает числовой аргумент (в остальных случаях игнорируется). Особым случаем является ввод после команды символа, не являющегося — или цифрой, — число аргументов команды умножается на 4. Изначально имеется один аргумент, поэтому первое выполнение команды увеличивает число аргументов до 4, второе — до 16 и т. д. По умолчанию команда не привязана.

8.4.6. Завершение строк из Readline

complete (TAB)

Пытается завершить текст до точки. Реальное дополнение зависит от приложения. Bash пытается завершить текст как переменную (если он начинается с $), имя пользователя (начинается с ~), имя хоста (начинается с @) или команду (включая псевдонимы и функции). Если ни один из вариантов не обеспечивает соответствия, выполняется завершение имени файла.

possible-completions (M-?)

Список возможных завершений текста до точки. При выводе завершений Readline устанавливает число отображаемых символов в соответствии с completion-display-width, значением переменной COLUMNS или шириной экрана в указанном порядке.

insert-completions (M-*)

Вставляет все завершения текста перед точкой, которые были бы сгенерированы possible-completions.

menu-complete ()

Похожа на complete, но заменяет дополняемое слово одним совпадением из списка возможных дополнений. Повтор дополнения меню из списка возможных дополнений вставляет каждое совпадение по очереди. В конце списка подается звуковой сигнал (в зависимости от настройки) и восстанавливается исходный текст. Аргумент n задает шаг перемещения вперед по списку совпадений, при отрицательном значении перемещение происходит назад. Команда предназначена для привязки к клавише TAB, но по умолчанию не привязана.

menu-complete-backward ()

Идентична menu-complete, но с обратным перемещением как при отрицательном аргументе menu-complete.

delete-char-or-list ()

Удаляет символ в позиции курсора, если это не начало и не конец строки (как delete-char). В конце строки идентична possible-completions. Команда по умолчанию не привязана.

complete-filename (M-/)

Пытается завершить текст перед курсором как полное имя файла.

possible-filename-completions (C-x /)

Выводит возможные завершения текста до курсора, считая его именем файла.

complete-username (M-~)

Пытается завершить текст перед курсором как имя пользователя.

possible-username-completions (C-x ~)

Выводит возможные завершения текста до курсора, считая его именем пользователя.

complete-variable (M-$)

Пытается завершить текст перед курсором как имя переменной среды.

possible-variable-completions (C-x $)

Выводит возможные завершения текста до курсора, считая его именем переменной среды.

complete-hostname (M-@)

Пытается завершить текст перед курсором как имя хоста.

possible-hostname-completions (C-x @)

Выводит возможные завершения текста до курсора, считая его именем хоста.

complete-command (M-!)

Пытается завершить текст перед курсором как имя команды, сопоставляя текст с псевдонимами, зарезервированными словами, функциями и внутренними командами оболочки, а также именами исполняемых файлов в указанном порядке.

possible-command-completions (C-x !)

Выводит возможные завершения текста до курсора, считая его именем команды.

dynamic-complete-history (M-TAB)

Пытается завершить текст перед курсором, сравнивая его со строками из списка истории для дополнения.

dabbrev-expand ()

Пытается завершить меню по тексту до курсора, сравнивая его со строками из списка истории для дополнения.

complete-into-braces (M-{)

Дополняет имя файла и вставляет список возможных дополнений в фигурных скобках, чтобы он был доступен для оболочки (3.5.1. Раскрытие скобок).

8.4.7. Клавиатурные макросы

start-kbd-macro (C-x ()

Начинает сохранение введенных символов в текущем клавиатурном макросе.

end-kbd-macro (C-x ))

Останавливает сохранение введенных символов в текущем клавиатурном макросе и сохраняет макрос.

call-last-kbd-macro (C-x e)

Заново выполняет определенный последним клавиатурный макрос, как будто символы вводятся с клавиатуры.

print-last-kbd-macro ()

Выводит определенный последним клавиатурный макрос в форме, пригодной для файла inputrc.

8.4.8. Прочие команды

re-read-init-file (C-x C-r)

Читает файл inputrc и включает найденные привязки и назначения переменных.

abort (C-g)

Прерывает текущую команду редактирования с подачей звукового сигнала (в зависимости от bell-style).

do-lowercase-version (M-A, M-B, M-x, …)

Если символ x имеет верхний регистр, запускается команда, привязанная к соответствующему символу в нижнем регистре. При x в нижнем регистре поведение становится неопределенным.

prefix-meta (ESC)

Добавляет префикс Meta к следующему введенному символу. Это рассчитано на клавиатуры без клавиши Meta. Нажатие ESC f эквивалентно M-f.

undo (C-_ или C-x C-u)

Инкрементный откат, раздельно запоминаемый для каждой строки.

revert-line (M-r)

Отменяет все изменения данной строки, как многократное выполнение команды undo для возврата к началу.

tilde-expand (M-&)

Выполняет преобразование тильды для текущего слова.

set-mark (C-@)

Устанавливает маркер в позицию курсора. При наличии числового аргумента маркер устанавливается в заданную им позицию.

exchange-point-and-mark (C-x C-x)

Меняет местами позицию курсора и маркер. Курсор помещается в сохраненную позицию, а прежняя позиция сохраняется как маркер.

character-search (C-])

Символ считывается и курсор перемещается к следующему вхождению этого символа. Отрицательное значение задает поиск предыдущего вхождения.

character-search-backward (M-C-])

Символ считывается и курсор перемещается к предыдущему вхождению этого символа. Отрицательное значение задает поиск следующего вхождения.

skip-csi-sequence ()

Считывается достаточное число символов для потребления многосимвольной последовательности, такой как для клавиш Home и End. Последовательности этого типа начинаются с индикатора управляющей последовательности (CSI4), которым обычно служит ESC-[. Если последовательность привязана к \e[, создающие ее символы не будут давать эффекта, если они явно не связаны с командой readline вместо вставки в буфер редактирования. Команда по умолчанию не привязана, но обычно ее связывают с клавишами ESC-[.

insert-comment (M-#)

Без числового аргумента вставляется значение переменной comment-begin в начало текущей строки. При наличии числового аргумента команда действует как переключатель — если символы в начале строки не совпадают с comment-begin, вставляется значение этой переменной, в противном случае значение comment-begin удаляется из начала строки. В любом случае строка воспринимается как при вводе символа новой строки. Принятое по умолчанию значение comment-begin заставляет делать текущую строку комментарием для оболочки. Если числовой аргумент ведет к удалению комментария, строка будет выполнена оболочкой как команда.

dump-functions ()

Выводит все функции и их привязки в выходной поток Readline. При наличии числового аргумента вывод форматируется так, что его можно включить в файл inputrc. По умолчанию команда не привязана.

dump-variables ()

Выводит все устанавливаемые переменные и их значения в выходной поток Readline. При наличии числового аргумента вывод форматируется так, что его можно включить в файл inputrc. По умолчанию команда не привязана.

dump-macros ()

Выводит все комбинации клавиш Readline, привязанные к макросам, и создаваемые ими строки. При наличии числового аргумента вывод форматируется для включения в файл inputrc. По умолчанию команда не привязана.

glob-complete-word (M-g)

Слово перед курсором трактуется как шаблон преобразования пути с неявным добавлением *. Этот шаблон служит для создания списка совпадающих имен файлов для возможного дополнения.

glob-expand-word (C-x *)

Слово перед курсором считается шаблоном преобразования пути и вместо него вставляется список совпадающих имен файлов. При наличии числового аргумента перед преобразованием имен в конец добавляется *.

glob-list-expansions (C-x g)

Выводится список преобразования, которые будут созданы glob-expand-word и строка печатается заново. При наличии числового аргумента перед преобразованием имен в конец добавляется *.

display-shell-version (C-x C-v)

Выводится информация о версии текущего экземпляра Bash.

shell-expand-line (M-C-e)

Строка преобразуется, как это делает оболочка. Преобразуются псевдонимы и история, а также выполняется преобразование слов оболочкой (3.5. Преобразования).

history-expand-line (M-^)

Выполняет преобразование истории для текущей строки.

magic-space ()

Выполняет преобразование истории для текущей строки и вставляет пробел (9.3. Преобразование истории).

alias-expand-line ()

Выполняет преобразование псевдонимов для текущей строки (6.6. Псевдонимы).

history-and-alias-expand-line ()

Выполняет преобразование истории и псевдонимов для текущей строки.

insert-last-argument (M-. or M-_)

Синоним yank-last-arg.

operate-and-get-next (C-o)

Принимает текущую строку для выполнения и извлекает следующую строку истории, помещая ее в текущую строку для редактирования. При наличии числового аргумента он задает строку истории, которую следует использовать взамен текущей.

edit-and-execute-command (C-x C-e)

Вызывает редактор текущей строки команды и выполняет результат как команды оболочки. Bash пытается вызывать в качестве редактора $VISUAL, $EDITOR, emacs в указанном порядке.

8.5. Readline в режиме vi

Хотя библиотека Readline не включает полного набора функций редактирования vi, она поддерживает простые операции редактирования строк. Readline в режиме vi ведет себя в соответствии со стандартом POSIX.

Для интерактивного переключения между режимами редактирования emacs и vi служат команды set -o emacs и set -o vi (4.3.1. Внутренняя команда set). Readline по умолчанию работает в режиме emacs.

При вводе строки в режиме vi используется режим вставки, как при нажатии клавиши i. Клавиша ESC переключает в режим команд, где можно редактировать текст строки с использованием стандартных команд перемещения vi, переходить к предыдущей (k) или следующей (j) строке истории и т. п.

8.6. Программируемое дополнение

При попытке завершения слова в аргументе команды, для которой определена спецификация дополнения (compspec) с использованием внутренней команды complete (8.7. Внутренние функции программируемого дополнения), вызываются функции программируемого дополнения.

Сначала идентифицируется имя команды. Если для команды была определена спецификация compspec, она служит для создания списка возможных дополнений слова. Если слово команды является пустой строкой (попытка дополнения в начале строки), применяется любая спецификация compspec, определенная с опцией -E. Если слово команды является полным путем, сначала отыскивается compspec для полного пути, а при отсутствии предпринимается попытка найти compspec для части, следующей за последним символом /. Если этот поиск не дает compspec, по умолчанию используется любая спецификация compspec, определенная с опцией -D. Если заданной по умолчанию спецификации compspec нет, Bash пытается преобразовать псевдоним для слова команды, а затем найти compspec для преобразованного слова.

После нахождения спецификации compspec она применяется для создания списка соответствующих слов. Если compspec найти не удалось, выполняется принятое по умолчанию дополнение Bash (8.4.6. Завершение строк из Readline). Сначала применяются действия, заданные compspec, при этом возвращаются только совпадения, которые начинаются с дополняемого слова. При использовании опции -f или -d для дополнения имени файла или каталога, применяется переменная оболочки FIGNORE для фильтрации совпадений (5.2. Переменные Bash).

Затем генерируются совпадения, заданные шаблоном преобразования имен файлов для опции -G. Слова, создаваемые шаблоном не обязаны совпадать с дополняемым словом, переменная оболочки GLOBIGNORE не используется для фильтрации совпадений, но переменная FIGNORE применяется.

Далее рассматривается строка, заданная аргументом опции -W. Сначала строка расщепляется ч использованием в качестве ограничителей символов из переменной IFS. Кавычки в строке принимаются во внимание для обеспечения механизма преобразования слов с метасимволами оболочки или символами из IFS. Затем каждое слово преобразуется с учетом преобразований скобок, тильды параметров и переменных, как описано в параграфе 3.5. Преобразования. Результат расщепляется по правилам параграфа 3.5.7. Расщепление слов.

Результатом преобразования является совпадение начала с дополняемым словом и совпадающие слова становятся возможными дополнениями.

После генерации совпадений вызывается функция или команда оболочки, заданная опциями -F и -C при вызове, при этом переменным COMP_LINE, COMP_POINT, COMP_KEY и COMP_TYPE присваиваются значения, как описано в параграфе 5.2. Переменные Bash. При вызове функции оболочки устанавливаются также переменные COMP_WORDS и COMP_CWORD. При вызове команды или функции первым аргументом ($1) является имя команды, чьи аргументы дополняются, вторым ($2) — дополняемое слово, а третьим ($3) слово, предшествующее дополняемому в строке текущей команды. Дополнения не фильтруются, функция или команда имеют полную свободу генерации совпадений.

Функция, заданная с -F, вызывается первой и может использовать для генерации совпадений любые средства оболочки, включая встроенные функции compgen и compopt, описанные в параграфе 8.7. Внутренние функции программируемого дополнения. Она должна поместить возможные дополнения в переменную (массив) COMPREPLY по одному дополнению в элемент. Затем вызывается команда указанная с -C, в среде эквивалентной подстановке команд. Ей следует вывести список дополнений (по 1 в строке) на стандартный вывод. Для экранирования перевода строки (newline) можно использовать \.

После создания списка всех возможных дополнений к нему применяются фильтры, заданные опцией -X. Фильтр является шаблоном, какие применяются для преобразования имен файлов — символ & в шаблоне заменяется текстом дополняемого слова. Сам символ & может экранироваться символом \, который удаляется до попытки сопоставления. Любое дополнение, соответствующее шаблону, удаляется из списка. Символ ! перед шаблоном инвертирует его и удаляются дополнения, не соответствующие шаблону. Если включена опция nocasematch (4.3.2. Внутренняя команда shopt), регистр символов при сопоставлении не учитывается. В заключение к каждому элементу списка дополнений добавляются префикс и суффикс, заданные опциями -P и -S, и результат возвращается коду завершения Readline как список возможных дополнений.

Если описанные выше действия не привели к созданию списка совпадений и была задана опция -o dirnames для дополнения при заданной спецификации compspec, выполняется попытка дополнить имена каталогов.

Если была указано опция -o plusdirs для дополнения при заданной спецификации compspec, выполняется попытка дополнить имена каталогов и совпадения добавляются к результатам предшествующих действий.

По умолчанию, если найдена спецификация compspec, все созданное этой спецификацией возвращается коду дополнения как полный набор возможных вариантов. Принятые по умолчанию дополнения Bash не применяются и принятое по умолчанию дополнение имен файлов Readline отключено. Если была указана опция -o bashdefault для дополнения с compspec и эта спецификация не дала совпадений, предпринимается попытка принятого по умолчанию дополнения Bash. Если была задана опция -o default для дополнения с compspec и эта спецификация, а также дополнение Bash не дали совпадений, применяется заданное по умолчанию дополнение Readline.

Когда compspec указывает желательность дополнения имен каталогов, программируемые функции дополнения заставляют Readline добавлять символ / к дополненным именам, которые являются символьными ссылками на каталоги, в соответствии со значением переменной mark-directories в Readline, независимо от установки переменной mark-symlinked-directories в Readline.

Имеется некоторая поддержка динамически меняющихся дополнений, которая может быть полезна в сочетании с принятым по умолчанию дополнением, заданным с опцией -D. Для функций оболочки, выполняемых как обработчики дополнений, можно указать потребность в повторе дополнения путем возврата статуса 124. Если функция оболочки возвращает 124 и меняет спецификацию compspec, связанную с командой, для которой выполняется дополнение (первый аргумент при выполнении функции), программируемое дополнение запускается сначала в попытке найти новую спецификацию compspec для этой команды. Это позволяет создавать динамический набор дополнений вместо загрузки всех спецификаций сразу.

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

_completion_loader()
{
	. "/etc/bash_completion.d/$1.sh" >/dev/null 2>&1 && return 124
}
complete -D -F _completion_loader -o bashdefault -o default

8.7. Внутренние функции программируемого дополнения

Для работы с программируемыми функциями дополнения имеется 3 команды, одна из которых задает способ дополнения аргументов конкретной команды, а две другие позволяют менять режим дополнения.

compgen

compgen [option] [word]

Генерирует список возможных дополнений для слова в соответствии с опциями (любые опции внутренней команды complete, кроме -p и -r) и выдает совпадения на стандартный вывод. При указании опции -F или -C переменные оболочки, задаваемые различными средствами программируемого дополнения, будут доступны, но бесполезны.

Совпадения будут генерироваться так же, как это делает программируемый код дополнения по спецификации с такими же флагами. Если задан параметр word, будут выводиться лишь соответствующие ему дополнения.

Функция возвращает значение true, если нет непригодных опций и найдены совпадения.

complete

complete [-abcdefgjksuv] [-o comp-option] [-DEI] [-A action] [-G globpat]
[-W wordlist] [-F function] [-C command] [-X filterpat]
[-P prefix] [-S suffix] name [name ...]
complete -pr [-DEI] [name ...]

Задает способ дополнения аргументов для каждого параметра name. При наличии опции -p или полном отсутствии опций выводится имеющаяся спецификация дополнения в форме пригодной для ввода. Опция -r удаляет спецификацию дополнения для каждого значения name или все спецификации, если параметр name не задан. Опция -D указывает, что следует применять другие заданные опции и действия к «принятому по умолчанию» дополнению command, т. е. выполняется дополнение команды, которое ранее не было определено. Опция -E указывает, что следует применять другие заданные опции и действия к дополнению «пустой» команды, т. е. пустой строки command. Опция -I указывает, что следует применять другие заданные опции и действия к дополнению изначально не заданного слова в строке или после разделителя (такого как ; или |), который обычно является завершение имени команды. При наличии множества опций -D имеет приоритет над -E и обе эти опции более приоритетны чем -I. Если задана любая из опций -D, -E, -I, все остальные аргументы name игнорируются и дополнения относятся лишь к заданному опцией случаю.

Процесс применения этих спецификаций дополнения описан в параграфе 8.6. Программируемое дополнение.

Назначение остальных опций описано ниже. Аргументы опций -G, -W и -X (при необходимости и опций -P и -S) следует заключать в кавычки, чтобы предотвратить их преобразование до вызова внутренней команды complete.

-o comp-option

Опция comp-option управляет несколькими аспектами поведения compspec сверх простой генерации дополнений и может принимать одно из приведенных ниже значений.

bashdefault

Выполнять принятые по умолчанию дополнения Bash, если compspec не дает совпадений.

default

Выполнять принятое по умолчанию дополнение имен файлов Readline, если compspec не дает совпадений.

dirnames

Выполнять дополнение имен каталогов, если compspec не дает совпадений.

filenames

Говорит Readline, что генерирует имена файлов, поэтому можно выполнять соответствующую обработку (например, добавление / к именам каталогов, экранирование специальных символов, исключение пробелов в конце). Опция предназначена для использования с функциями оболочки, заданными -F.

noquote

Говорит Readline, что не нужно применять экранирование дополненных имен файлов (принято по умолчанию).

nosort

Говорит Readline, что не нужно сортировать список дополнений по алфавиту.

nospace

Говорит Readline, что не нужно добавлять пробел к слову, дополненному в конце строки (принято по умолчанию).

plusdirs

После создания всех дополнений, заданных compspec, выполняется дополнение имен каталогов и совпадения добавляются к результатам других действий.

-A action

Параметр action может принимать одно из перечисленных ниже значений при создании списка дополнений.

alias

Имена псевдонимов. Может также применяться сокращение -a.

arrayvar

Имена переменных массивов.

binding

Имена привязок клавиш Readline (8.4. Клавиатурные команды Readline).

builtin

Имена внутренних команд оболочки. Может также применяться сокращение -b.

command

Имена команд. Может также применяться сокращение -c.

directory

Имена каталогов. Может также применяться сокращение -d.

disabled

Имена отключенных внутренних функций оболочки.

enabled

Имена включенных внутренних функций оболочки.

export

Имена экспортируемых переменных оболочки. Может также применяться сокращение -e.

file

Имена файлов. Может также применяться сокращение -f.

function

Имена функций оболочки.

group

Имена групп. Может также применяться сокращение -g.

helptopic

Темы справки, принимаемые внутренней командой help (4.2. Внутренние команды bash).

hostname

Имена хостов из файла, заданного переменной оболочки HOSTFILE (5.2. Переменные Bash).

job

Имена заданий, если активно управление заданиями. Может также применяться сокращение -j.

keyword

Зарезервированные слова оболочки. Может также применяться сокращение -k.

running

Имена работающих заданий, если активно управление заданиями.

service

Имена служб. Может также применяться сокращение -s.

setopt

Действительные аргументы опции -o внутренней команды set (4.3.1. Внутренняя команда set).

shopt

Имена опций оболочки, воспринимаемые функцией shopt (4.2. Внутренние команды bash).

signal

Имена сигналов.

stopped

Имена остановленных заданий, если активно управление заданиями.

user

Имена пользователей. Может также применяться сокращение -u.

variable

Имена всех переменных оболочки. Может также применяться сокращение -v.

-C command

Команда command выполняется в среде субоболочки и вывод используется как возможные дополнения.

-F function

Функция оболочки, выполняемая в среде текущей оболочки. При выполнении $1 указывает имя команды, аргументы которой дополняются, $2 — дополняемое слово, $3 — слово, предшествующее дополняемому, как описано в параграфе 8.6. Программируемое дополнение. По завершении список возможных дополнений извлекается как переменная массива COMPREPLY.

-G globpat

Шаблон преобразования имен файлов globpat преобразуется для генерации возможных дополнений.

-P prefix

Префикс prefix добавляется в начале каждого возможного дополнения после применения всех других опций.

-S suffix

Суффикс suffix добавляется в конце каждого возможного дополнения после применения всех других опций.

-W wordlist

Список wordlist расщепляется с использованием символов специальной переменной IFS в качестве разделителей и каждое полученное слово преобразуется. Возможными дополнениями являются элементы списка, соответствующие дополняемому слову.

-X filterpat

Шаблон filterpat служит для преобразования имен файлов и применяется к списку возможных дополнений, созданному предшествующими опциями и аргументами, с удалением всех элементов, соответствующих filterpat. Символ ! А начале filterpat инвертирует операцию и удаляются несоответствующие элементы.

Возвращается значение true, если нет непригодных опций, не представлены без аргументов опции, отличные от -p и -r, не было попыток удалить отсутствующую спецификацию дополнения для имени и не было ошибок при добавлении спецификации дополнения.

compopt

compopt [-o option] [-DEI] [+o option] [name]

Меняет опции дополнения в соответствии с option для каждого параметра name или для текущего дополнения при отсутствии name. При отсутствии опций выводятся имеющиеся опции для каждого name или текущего дополнения. Возможными значениями параметра option являются пригодные для внутренней функции complete, как описано выше. Опция -D указывает, что следует применять другие заданные опции к «принятому по умолчанию дополнению команды, т. е. предпринимается попытка дополнения команды, которе не было задано раньше. Опция -E указывает, что следует применять другие заданные опции и действия к дополнению «пустой» команды, т. е. пустой строки command. Опция -I указывает, что следует применять другие заданные опции и действия к дополнению изначально не заданного слова в строке или после разделителя (такого как ; или |), который обычно является завершение имени команды. При наличии множества опций -D имеет приоритет над -E и обе эти опции более приоритетны чем -I.

Возвращается значение true, если нет непригодных опций, не было попыток изменить опции для name без спецификации дополнения и не возникло ошибок.

8.8. Пример программируемого дополнения

Наиболее распространенным способом расширения функциональности дополнения за пределы операций complete и compgen является использование функций оболочки с их привязкой к коркретной команде с помощью complete -F.

Приведенная ниже функция обеспечивает дополнения для внутренней команды cd. Это достаточно хороший пример использования shell-функции для дополнения. Функция использует слово, переданное как аргумент $2, для определения имени дополняемого каталога. Можно применять переменную массива COMP_WORDS для индексирования текущего слова.

Функция использует внутренние команды complete и compgen для основной работы, добавляя от внутренней команды Bash cd преобразование тильды (3.5.2. Преобразование тильды), поиск каталогов в $CDPATH (4.1. Внутренние элементы Bourne Shell) и базовую поддержку опции оболочки cdable_vars (4.3.2. Внутренняя команда shopt). Функция _comp_cd меняет значение IFS, чтобы оно включало лишь символ newline для имен файлов с пробелами и символами табуляции, compgen выводит возможные дополнения по одному в строке.

Возможные дополнения помещаются в переменную массива COMPREPLY (по одному в элемент). Система программируемого дополнения отыскивает дополнения в возвращенном результате.

# Функция дополнения для внутренней команды cd на основе функции
# дополнения cd из пакета bash_completion
_comp_cd()
{
	local IFS=$’ \t\n’	# нормализация IFS
	local cur _skipdot _cdpath
	local i j k
	# Преобразование тильды в полный путь
	case "$2" in
	\~*)	eval cur="$2" ;;
	*)	cur=$2 ;;
	esac
	# Нет cdpath или абсолютного пути, прямое дополнение каталога
	if [[ -z "${CDPATH:-}" ]] || [[ "$cur" == @(./*|../*|/*) ]]; then
		# compgen выводит пути по одному в строке и может применять цикл while
		IFS=$’\n’
		COMPREPLY=( $(compgen -d -- "$cur") )
		IFS=$’ \t\n’
	# CDPATH + каталоги в текущем каталоге, если их нет в CDPATH
	else
		IFS=$’\n’
		_skipdot=false
		# Обработка CDPATH для преобразования пустых имен каталогов в .
		_cdpath=${CDPATH/#:/.:}
		_cdpath=${_cdpath//::/:.:}
		_cdpath=${_cdpath/%:/:.}
		for i in ${_cdpath//:/$’\n’}; do
			if [[ $i -ef . ]]; then _skipdot=true; fi
			k="${#COMPREPLY[@]}"
			for j in $( compgen -d -- "$i/$cur" ); do
				COMPREPLY[k++]=${j#$i/}	# Вырезание каталога
			done
		done
		$_skipdot || COMPREPLY+=( $(compgen -d -- "$cur") )
		IFS=$’ \t\n’
	fi
	# Имена переменных, если задана подходящая опция и нет дополнений
	if shopt -q cdable_vars && [[ ${#COMPREPLY[@]} -eq 0 ]]; then
		COMPREPLY=( $(compgen -v -- "$cur") )
	fi
	return 0
}

Функция дополнения устанавливается с помощью опции -F команды complete

# Указывает readline экранировать нужное, добавлять \ к каталогам и
# использовать принятое по умолчанию дополнение bash для других аргументов
complete -o filenames -o nospace -o bashdefault -F _comp_cd cd

Чтобы Bash и Readline принимали во внимание другие детали, для этого используются опции Bash и Readline. Опция -o filenames говорит Readline что возможные дополнения следует считать именами файлов и применять экранирование. Эта опция также ведет к добавлению символа / в имена, которые Readline считает каталогами (поэтому можно расширить _comp_cd для добавления / при использовании каталогов, найденных через CDPATH — Readline не может считать эти дополнения каталогами). Опция -o указывает Readline не добавлять пробел к имени каталога. Опция -o bashdefault включает остальные «принятые по умолчанию» дополнения Bash к набору «принятых по умолчанию» в Readline. Это включает дополнение имен команд, дополнение переменных для слов, начинающихся с {, дополнения с шаблонами преобразования путей (3.5.8. Преобразование имен файлов) и т. д.

После установки в команде complete функция _comp_cd будет вызываться при попытке дополнения слов для cd.

В проекте дополнения bash имеется еще много примеров для команд GNU, Unix и Linux, которые по умолчанию устанавливаются во многих дистрибутивах GNU/Linux. Созданный Ian Macdonald проект сейчас размещен на сайте http://bash-completion.alioth.debian.org/. Имеются варианты для таких систем как Solaris и Mac OS X. Старые версии пакета дополнения bash распространяются с bash в каталоге examples/complete.

9. Интерактивное использование истории

В этой главе описана работа с библиотекой gnu History в интерактивном режиме.

9.1. Средства Bash History

При включенной опции -o history внутренней команды set (4.3.1. Внутренняя команда set) оболочка предоставляет доступ к истории команд, т. е. списку ранее введенных команд. Значение переменной оболочки HISTSIZE задает число записей, хранящихся в списке истории )по умолчанию 500). Оболочка сохраняет команды в списке до преобразования параметров и переменных с учетом значений HISTIGNORE и HISTCONTROL.

При запуске оболочки история инициализируется из файла, указанного в переменной HISTFILE (по умолчанию ~/.bash_history). При необходимости заданный в HISTFILE файл усекается, чтобы число строк в нем не превышало значение переменной HISTFILESIZE. При завершении оболочки со включенной историей последние $HISTSIZE строк копируются из списка истории в файл, заданный в $HISTFILE. Если установлена опция оболочки histappend (4.2. Внутренние команды bash), строки добавляются в конец файла истории, а при выключенной опции файл перезаписывается. После сохранения истории файл усекается до числа строк, не превышающего значение $HISTFILESIZE. Если переменная HISTFILESIZE не установлена, пуста или содержит нечисловое значение или число меньше 0, файл истории не усекается.

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

Можно применять внутреннюю команду fc для просмотра, редактирования или повторного выполнения части списка истории. Внутренняя команда history позволяет просматривать и редактировать список, а также манипулировать файлом истории. При редактировании командной строки доступны команды поиска в каждом режиме редактирования, обеспечивающем доступ к списку истории (8.4.2. Команды работы с историей).

Оболочка позволяет управлять сохранением команд в истории с помощью переменных HISTCONTROL и HISTIGNORE. Включение опции оболочки cmdhist ведет к попытке сохранения всех строк многострочной команды в одной записи истории с добавлением символов ; для обеспечения синтаксической корректности. Опция lithist заставляет оболочку сохранять команды с символами новой строки вместо ;. Для установки этих опций служит внутренняя команда shopt (4.3.2. Внутренняя команда shopt).

9.2. Внутренние команды истории Bash

Bash поддерживает две внутренних команды для манипулирования списком и файлом истории.

fc

fc [-e ename] [-lnr] [first] [last]
fc -s [pat=rep] [command]

Первая форма выбирает из списка истории команды от first до last и выводит или редактирует и заново выполняет их все. Оба параметра first и last могут быть заданы строками (выбирается наиболее свежая команда, начинающаяся с заданной строки) или номером (индекс списка истории, где отрицательные значения задают смещение от номера текущей команды). Если параметр last не задан, он принимает значение first. Если не задан параметр first, устанавливается предыдущая команда при редактировании и -16 для списка. Флаг -l задает печать списка на стандартном устройстве вывода, флаг -n отключает вывод номеров команд в списке, а -r обращает порядок списка. В остальных случаях вызывается редактор, заданные параметром ename, а при отсутствии параметра — редактор, заданный преобразованием переменной ${FCEDIT:-${EDITOR:-vi}}. Это выражение задает использования значения переменной FCEDIT (при наличии) или EDITOR (при наличии), а при отсутствии обеих вызывается редактор vi. По завершении редактирования исправленная команда выводится и выполняется.

Во втором варианте команда command выполняется заново после замены каждого pat в выбранной команде на rep. Параметр command интерпретируется так же, как описанный выше параметр first.

Полезным псевдонимом для работы с командой fc является r=’fc -s’, ввод команды r cc запустит последнюю команду, начинающуюся с cc, а r повторит выполнение последней команды (6.6. Псевдонимы).

history

history [n]
history -c
history -d offset
history -d start-end
history [-anrw] [filename]
history -ps arg

При запуске без опций выводит список записей истории с номерами строк, указывая префиксом * измененные строки. Аргумент n ограничивает вывод последними n строками. Если переменная оболочки HISTTIMEFORMAT задана и не пуста, она служит строкой формата для strftime при выводе временных меток записей истории. Метки не отделяются пробелом от строк истории.

Опции команды описаны ниже.

-c

Очищает список истории и может сочетаться с другими опциями для полной замены списка.

-d offset

Удаляет запись, указанную смещением offset. Положительные значения считаются номерами в списке, отрицательные отсчитываются от последней записи + 1, т. е. команда history -d -1 удалит последнюю команду.

-d start-end

Удаляет записи истории между позициями start и end, включительно. Положительные и отрицательные значения трактуются как для offset.

-a

Добавляет новые записи в файл истории. Это будут строки, введенные с начала текущей сессии Bash, но еще не добавленные в файл.

-n

Добавляет строки, еще не прочитанные из файла истории в текущий список. Это будут строки, добавленные в конец файла истории с начала текущей сессии Bash.

-r

Читает файл истории и добавляет его содержимое в конец списка.

-w

Записывает текущий список в файл истории.

-p

Выполняет подстановку в истории по arg и печатает результат на стандартном устройстве вывода без сохранения в списке.

-s

Параметр arg добавляется в конец списка как одна запись.

Если задано имя файла при наличии любой из опций -w, -r, -a, -n, оно считается именем файла истории. В остальных случаях используется значение переменной HISTFILE.

9.3. Преобразование истории

Библиотека History обеспечивает функции преобразования истории, похожие на функции оболочки csh. В этом разделе описан синтаксис для работы с данными истории.

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

Преобразование состоит из двух частей. Сначала определяется строка из списка истории, которую следует использовать в процессе подстановки. Затем выбирается часть этой строки для включения в текущую строку. Выбор строки из истории называют событием, а используемые части этой строки — словами. Для манипуляция с выбранными словами можно применять различные модификаторы. Строка разбивается на слова обычными методами Bash и несколько слов в кавычках рассматриваются как одно слово. Преобразование истории инициируется специальным символом (по умолчанию !).

При преобразовании используются похожие на применяемые в оболочке соглашения о кавычках. Для отмены специальной трактовки символов перед ним может помещаться символ \, последовательность символов в одинарных кавычках трактуется дословно. Для символов внутри двойных кавычек может применяться преобразование истории, поскольку символу преобразования может предшествовать \, но не символ одинарных кавычек, который не имеет специального значения внутри двойных кавычек. При использовании оболочки лишь символы \ и ’ могут служить для экранирования символа преобразования истории, но этот символ считается заключенным в кавычки также в том случае, когда он непосредственно предшествует закрывающей кавычке в строк с двойными кавычками.

Несколько опций, устанавливаемых внутренней командой shopt (4.3.2. Внутренняя команда shopt), могут применяться для настройки преобразования истории. Если включена опция histverify и применяется Readline, подстановки в истории не передаются сразу же анализатору оболочки и преобразованная строка заново загружается в буфер редактирования Readline для дополнительного изменения. При использовании Readline со включенной опцией histreedit неудачное преобразование истории будет заново загружаться в буфер Readline для исправления. Можно использовать опцию -p внутренней команды history для просмотра преобразования истории перед его использованием. Опция -s команды history позволяет добавлять команды в конец списка истории без их реального выполнения, чтобы они были доступны для последующих вызовов. Это наиболее полезно в сочетании с Readline.

Оболочка позволяет управлять символами, используемыми в механизмах преобразования истории, с помощью переменной histchars (5.2. Переменные Bash). Оболочка использует символ комментария в истории для включения в файл истории временных меток.

9.3.1. Обозначения событий

Указатель события — это ссылка на запись команды в списке истории. Если ссылка не является абсолютной, событие относится к текущей позиции в списке истории.

!

Начало подстановки истории за исключением тех случаев, когда за восклицательным знаком следует пробел, символ табуляции, завершение строки = или ( (если включена опция extglob с помощью внутренней команды shopt).

!n

Указывает строку команды n.

!-n

Указывает команду n назад.

!!

Указывает предыдущую команду (синоним !-1).

!string

Указывает последнюю команду, предшествующую текущей позиции в списке истории и начинающуюся со string.

!?string[?]

Указывает последнюю комагду, предшествующую текущей позиции в списке истории и содержащую string. Символ ? в конце можно опустить, если непосредственно за ним следует newline.

^string1^string2^

Быстрая подстановка. Повторяется последняя команда с заменой string1 на string2 (эквивалент !!:s/string1/string2/).

!#

Набрана все команда.

9.3.2. Обозначения слов

Указатель слов применяется для выбора нужных слов из события. Указатель слова отделяется от спецификации события двоеточием, которое можно опустить, если указатель слова начинается с ^, $, *, — или %. Слова нумеруются от начала строки, начиная с 0 для первого слова. Слова вставляются в текущую строку через пробел. Например,

!!

указывает предшествующую команду.

!!:$

указывает последний аргумент предшествующей команды и может сокращаться до !$.

!fi:2

указывает второй аргумент последней команды, начинающейся с fi.

Указатель слов приведены ниже.

0

Нулевое слово, которое для многих приложений является словом команды.

N

N-е слово.

^

Первый аргумент (слово 1).

$

Последний аргумент.

%

Слово, соответствующее последнему поиску ‘?string?’.

x-y

Диапазон слов (-y является сокращение 0-y).

*

Все слова кроме нулевого (сокращение 1-$). Использование * не является ошибкой при наличии в событии единственного слова, просто будет возвращена пустая строка.

x*

Сокращение для x-$

x-

Сокращение для x-$, похожее на x*, но без возврата последнего слова.

Если указатель слова приведен без спецификации события, в качестве события служит предыдущая команда.

9.3.3. Модификаторы

После необязательного указателя слова можно добавить один или несколько приведенных ниже модификаторов, помещая перед каждым двоеточие (:).

h

Удаляет конечную часть пути, оставляя только «голову».

t

Удаляет начальные компоненты пути, оставляя только «хвост».

r

Удаляет суффикс .suffix (расширение), оставляя лишь базовое имя.

e

Удаляет все, кроме расширения (суффикса).

p

Выводит новую команду без ее выполнения.

q

Помещает подставленные слова в кавычки, экранируя дальнейшую подстановку.

x

Помещает подставленные слова в кавычки (как q), но разбивает их по символам пробела, табуляции и новой строки.

s/old/new/

Подставляет new вместо первого вхождения old в строке события. Вместо / можно использовать любые ограничители. В old и new ограничитель можно экранировать символом \. При наличии символа & в new, он заменяется old. Одиночный символ / экранирует &. Конечный ограничитель не обязателен, если это последний символ в строке ввода.

&

Повторяет предыдущую подстановку.

g

Применяет изменения ко всей строке события и используется вместе с s как в gs/old/new/ или с &.

G

Применяет следующий модификатор s один раз к каждому слову в событии.

10. Установка Bash

В этой главе приведены базовые инструкции по установке Bash на разных поддерживаемых платформах. Оболочка поддерживает операционные системы gnu, практически все версии Unix, а также ряд других систем, таких как BeOS и Interix. Имеются также варианты для ms-dos, os/2 и Windows.

10.1. Базовая установка

Ниже описан простейший вариант установки Bash с компиляцией исходных кодов.

  1. Из каталога с исходным кодом оболочки следует ввести команду ./configure для настройки Bash под конкретную систему. При работе с csh или старыми версиями System V может потребоваться команда sh ./configure, чтобы интерпретатор csh не пытался настраивать себя.

    Работа сценария настройки займет некоторое время и на консоль будут выводиться сообщения о проверки разных возможностей и функций.

  2. Команда make запускает компиляцию Bash и сборку сценария bashbug для сообщений об ошибках.

  3. Для запуска набора тестов Bash можно ввести команду make tests.

  4. Команда make install служит для установки bash и bashbug, а также страниц man и файла Info.

Сценарий configure пытается предсказать корректные значения зависимых от системы переменных в процессе настройки и использует эти значения для создания файлов Makefile в каждом каталоге пакета (основной каталог, builtins, doc и support, каждый каталог в lib и некоторые другие). Создается также файл config.h с зависимыми от системы определениями. В заключение создается сценарий оболочки config.status, который можно потом использовать для восстановления текущей конфигурации, файл config.cache с результатами проверок для ускорения последующей настройки и config.log с комментированным выводом процесса настройки (полезен в основном для отладки configure). Если config.cache содержит неприемлемые для вас результаты, файл можно удалить или отредактировать.

Для просмотра опций и аргументов настройки служит вводимая из каталога исходного кода Bash команда

bash-4.2$ ./configure --help

Если нужно собрать Bash в отдельном каталоге за пределами дерева кодов (например при сборке для нескольких вариантов архитектуры) можно указать полный путь к сценарию configure. В приведенном ниже примере bash будет собираться в каталоге /usr/local/build/bash-4.4 с использованием исходного кода из /usr/local/src/bash-4.4.

mkdir /usr/local/build/bash-4.4
cd /usr/local/build/bash-4.4
bash /usr/local/src/bash-4.4/configure
make

Сборка в отдельном каталоге более подробно описана в параграфе 10.3. Компиляция для разной архитектуры.

Если нужны какие-то особые настройки при компиляции Bash, следует описать свои потребности и отправить по адресу bash-maintainers@gnu.org, чтобы их можно было рассмотреть в следующем выпуске.

Файл configure.ac служит для создания сценария configure программой autoconf. Этот файл потребуется лишь для изменения или повторного создания сценария с использованием новой версии autoconf (не ниже 2.50).

Результаты сборки можно удалить из каталога исходных кодов командой make clean. Для удаления также файлов, созданных сценарием configure (например, перед сборкой Bash для другой системы) служит команда make distclean.

10.2. Компиляторы и опции

В некоторых системах нужны необычные опции компиляции или компоновки, о которых сценарий configure не знает. Можно задать для configure начальные значения переменных путем их установки в среде. Например в оболочках, совместимых с Bourne, можно использовать команды вида

CC=c89 CFLAGS=-O2 LIBS=-lPOSIX ./configure

В системах с программой env можно воспользоваться командами вида

env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure

Процесс настройки использует компилятор GCC для сборки Bash, если этот компилятор доступен.

10.3. Компиляция для разной архитектуры

Можно собрать Bash сразу для нескольких типов компьютеров, помещая объектные файлы для каждой архитектуры в свой каталог. Для этого нужна версия make, поддерживающая переменную VPATH, например. GNU make. Для настройки нужно перейти в каталог, куда следует помещать объектные и исполняемые файлы, и выполнить сценарий configure из каталога с исходным кодом (10.1. Базовая установка). Можно использовать аргумент —srcdir=PATH, который скажет сценарию configure, где расположен исходный код. Сценарий автоматически проверить код в каталоге, находится он сам и в каталоге ‘..’.

При использовании make без поддержки переменной VPATH, можно собрать Bash для одной архитектуры в каталоге с исходным кодом. После установки Bash для одной архитектуры следует использовать команду make distclean перед сборкой для другой архитектуры.

Если система поддерживает символьные ссылки, можно использовать сценарий support/mkclone для создания дерева сборки с символьными ссылками на каждый файл в каталоге исходных кодов. Ниже приведен пример создания каталога сборки в текущем каталоге из каталога исходных кодов /usr/gnu/src/bash-2.0

bash /usr/gnu/src/bash-2.0/support/mkclone -s /usr/gnu/src/bash-2.0 .

Для сценария mkclone требуется оболочка Bash, поэтому перед его использованием нужно собрать Bash хотя бы для одной архитектуры перед созданием каталогов сборки для других вариантов архитектуры.

10.4. Каталог для установки

По умолчанию команда make install устанавливает файлы оболочки в каталоги /usr/local/bin, /usr/local/man и т. п. Можно задать другой префикс установки с помощью опции configure —prefix=PATH или задания значения переменной DESTDIR для make при вызове ’ make install.

Можно указать отдельные префиксы установки для зависимых и независимых от архитектуры файлов. Если использовать опцию configure —exec-prefix=PATH, команда make install будет использовать значение PATH в качестве префикса для установки программ и библиотек, а документация и другие файлы данных будут размещены с использованием обычного префикса.

10.5. Указание типа системы

Некоторые параметры configure могут не настраиваться автоматически, но в любом случае нужно определить тип хоста, на котором будет работать Bash. Обычно configure может определить тип хоста автоматически, но если выводится сообщение о невозможности определения, следует использовать опцию —host=TYPE. Параметр TYPE может быть коротким именем системы (например, sun4) или каноническим именем с тремя полями CPU-COMPANY-SYSTEM (например, i386-unknown-freebsd4.2). Возможные значения полей указаны в файле support/config.sub.

10.6. Общее использование принятых по умолчанию значений

При желании можно сделать параметры сценария configure общими, создав сценарий config.site с принятыми по умолчанию значениями таких переменных как CC, cache_file, prefix. Сценарий configure ищет такой файл сначала в каталоге PREFIX/share/config.site, затем в PREFIX/etc/config.site. Можно также задать переменную среды CONFIG_SITE, указывающую этот файл. Следует отметить, что сценарий Bash configure ищет этот файл, но это делают не все сценарии configure.

10.7. Управление настройкой конфигурации

Сценария configure распознает перечисленные ниже опции управления его работой.

—cache-file=file

Использовать и сохранить результаты тестов в файле file вместо ./config.cache. Указание в качестве файла /dev/null отключает кэширование для отладки configure.

—help

Выводит краткую информацию о параметрах configure и завершает работу.

—quiet
—silent
-q

Отключает вывод сообщений о выполняемых проверках.

—srcdir=dir

Указывает размещение исходного кода Bash в каталоге dir. Обычно configure может определить каталог автоматически.

—version

Выводит информацию о версии Autoconf, использованной для создания сценария configure и завершает работу.

Другие опции configure можно увидеть по команде configure —help.

10.8. Дополнительные возможности

Сценарий Bash configure имеет множество опций вида —enable-feature для включения необязательных возможностей Bash. Имеется также несколько опций вида —with-package, где package указывает тот или иной пакет, например, bash-malloc или purify. Для отключения принятого по умолчанию пакета служит опция —without-package, для отключения той или иной включенной по умолчанию функции Bash — —disable-feature.

Ниже приведен полный список опций —enable- и —with-, поддерживаемых сценарием Bash configure.

—with-afs

Определяет использование файловой системы AFS5 для Transarc.

—with-bash-malloc

Задает использование Bash-версии malloc из каталога lib/malloc. Это отличается от malloc из gnu libc, но старая версия основана на 4.2 bsd malloc. Используемая версия malloc работает очень быстро, но требует большого пространства для каждого размещения. Опция включена по умолчанию. В файле NOTES приведен список систем, для которых опцию следует отключить и configure автоматически отключает опцию для многих систем.

—with-curses

Задает использование библиотеки curses вместо termcap. Это следует включать для систем, которые не имеют адекватной и полной базы termcap.

—with-gnu-malloc

Синоним для —with-bash-malloc.

—with-installed-readline[=PREFIX]

Связывает Bash с локально установленной версией Readline вместо версии из lib/readline и работает только для Readline версии 5.0 и выше. Если PREFIX имеет значение yes или отсутствует, configure использует значения переменных make includedir и libdir, которые по умолчанию являются подкаталогами prefix, для поиска установленной версии Readline, если ее нет в стандартных каталогах include и library. Если для PREFIX задано значение no, Bash привязывается к версии из lib/readline. Если PREFIX имеет любое другое значение, считает его именем каталога и ищет установленную версию Readline в его подкаталогах (включаемые файлы в PREFIX/include и библиотеки в PREFIX/lib).

—with-purify

Задает использование блока проверки выделения памяти Purify от Rational Software.

—enable-minimal-config

Задает сборку оболочки с минимальным набором возможностей, похожей на классическую оболочку Bourne. Имеется несколько опций —enable-, меняющих сборку и компоновку Bash, а не работу оболочки.

—enable-largefile

Включает поддержку больших файлов, если операционная система требует специальных опций компилятора для сборки программ, способных работать с большими файлами. Опция включена по умолчанию, если операционная система поддерживает большие файлы.

—enable-profiling

Задает сборку двоичного файла Bash, создающего данные профилировки для обработки gprof при каждом запуске.

—enable-static-link

Задает статическую компоновку Bash, если применяется gcc. Опцию можно использовать для сборки root-оболочки.

Опция minimal-config может служить для отключения всех перечисленных ниже опций, но она обрабатывается раньше, поэтому некоторые опции можно включить далее в команде с помощью —enable-feature. Все указанные ниже опции, за исключением —disabled-builtins, —direxpand-default и —xpg-echo-default, по умолчанию включены, если операционная система обеспечивает их поддержку.

—enable-alias

Разрешает преобразование псевдонимов и включает внутренние команды alias и unalias (6.6. Псевдонимы).

—enable-arith-for-command

Включает поддержку дополнительной формы оператора for, аналогичную оператору for в языке C (3.2.4.1. Конструкции с циклами).

—enable-array-variables

Включает поддержку переменных одномерных массивов (6.7. Массивы).

—enable-bang-history

Включает поддержку подстановки истории в стиле csh (9.3. Преобразование истории).

—enable-brace-expansion

Включает преобразование скобок в стиле csh ( b{a,b}c → bac bbc ). 3.5.1. Раскрытие скобок

—enable-casemod-attributes

Включает поддержку атрибутов, изменяющих регистр внутренней команды declare и операторов присваивания. Например, при назначении переменных символы верхнего регистра могут переводиться в нижний регистр.

—enable-casemod-expansion

Включает поддержку преобразования слов с изменением регистра.

—enable-command-timing

Включает поддержку зарезервированного слова time и отображение временной статистики для конвейеров (3.2.2. Конвейеры). Это позволяет контролировать время для конвейеров, а также внутренних команд и функций.

—enable-cond-command

Включает поддержку условной команды [[. (3.2.4.2. Конструкции с условием).

—enable-cond-regexp

Включает поддержку сопоставлений с регулярными выражениями POSIX, использующих бинарный оператор =~ в условной конструкции [[. (3.2.4.2. Конструкции с условием).

—enable-coprocesses

Включает поддержку копроцессов и зарезервированного слова coproc (3.2.2. Конвейеры).

—enable-debugger

Включает поддержку отладчика bash (распространяется отдельно).

—enable-dev-fd-stat-broken

Включает обход ситуаций, когда вызов stat для /dev/fd/N возвращает результат, отличный от вызова fstat для дескриптора N. Это имеет значение для условных конструкций, проверяющих атрибуты.

—enable-direxpand-default

Включает опцию оболочки direxpand (4.3.2. Внутренняя команда shopt) по умолчанию при запуске оболочки (обычно по умолчанию отключена).

—enable-directory-stack

Включает поддержку стека каталогов в стиле csh и внутренних команд pushd, popd и dirs (6.8. Стек каталогов).

—enable-disabled-builtins

Позволяет вызывать внутренние команды с помощью builtin xxx даже при отключении xxx командой enable -n xxx (см. описание команд builtin и enable в параграфе 4.2. Внутренние команды bash).

—enable-dparen-arithmetic

Включает поддержку команд ((…)) (3.2.4.2. Конструкции с условием).

—enable-extended-glob

Включает поддержку расширенного сопоставления с шаблонами, описанного в параграфе 3.5.8.1. Сопоставление с шаблоном.

—enable-extended-glob-default

Включает по умолчанию опцию оболочки extglob, описанную в параграфе 4.3.2. Внутренняя команда shopt.

—enable-function-import

Включает поддержку импорта определений функций, экспортируемых другим экземпляром оболочки из среды. Опция включена по умолчанию.

—enable-glob-asciirange-default

Включает по умолчанию опцию оболочки globasciiranges, описанную в параграфе 4.3.2. Внутренняя команда shopt. Это управляет поведением диапазонов символов при сравнении с шаблонами при использовании выражений в скобках.

—enable-help-builtin

Включает внутреннюю команду help которая выводит справку о внутренних функциях и переменных оболочки (4.2. Внутренние команды bash).

—enable-history

Включает историю команд, а также внутренние команды fc и history (9.1. Средства Bash History).

—enable-job-control

Включает средства управления заданиями (7. Управление заданиями), если операционная система поддерживает их.

—enable-multibyte

Включает поддержку многобайтовых символов, если операционная система поддерживает их.

—enable-net-redirections

Включает особую обработку имен файлов вида /dev/tcp/host/port и /dev/udp/host/port в перенаправлении (3.6. Перенаправление).

—enable-process-substitution

Включает подстановку процессов (3.5.6. Подстановка процессов), если операционная система поддерживает ее.

—enable-progcomp

Включает средства программируемого дополнения (8.6. Программируемое дополнение). Опция работает лишь при включенной поддержке Readline.

—enable-prompt-string-decoding

Включает интерпретацию ряда символов с \-экранированием в строках приглашений $PS0, $PS1, $PS2 и $PS4 (6.9. Управление формой приглашения).

—enable-readline

Включает поддержку редактирования и истории команд с версией Bash библиотеки Readline (8. Редактирование командной строки).

—enable-restricted

Включает поддержку ограниченной оболочки, когда Bash при вызове по команде rbash переходит в ограниченный режим (6.10. Ограниченная оболочка).

—enable-select

Включает составную команду select, позволяющую создавать простые меню (3.2.4.2. Конструкции с условием).

—enable-separate-helpfiles

Задает использование внешних файлов документации внутренней командой help вместо встраивания текста справки в программу.

—enable-single-help-strings

Задает сохранение каждого раздела справочной системы, выводимой внутренней командой help, в форме отдельной строки. Это может помочь при переводе текста. Однако опцию придется выключить, если компьютер не может корректно выводить длинные строки.

—enable-strict-POSIX-default

Включает совместимость Bash с POSIX по умолчанию (6.11. Режим POSIX).

—enable-usg-echo-default

Синоним для —enable-xpg-echo-default.

—enable-xpg-echo-default

Заставляет встроенную команду echo преобразовывать по умолчанию символы с \-экранированием без опции -e. Это устанавливает для переменной оболочки xpg_echo значение on по умолчанию, что делает команду Bash echo более похожей на версию, заданную спецификацией Single Unix Specification версии 3 (4.2. Внутренние команды bash).

Файл config-top.h содержит операторы препроцессора C #define для опций, которые не устанавливаются из configure. Некоторые из этих опций не предназначены для изменения. При редактировании файла следует внимательно читать комментарии к каждому определению.

Приложение A. Уведомление об ошибках

При обнаружении ошибок в Bash о них следует сообщать. Но сначала нужно убедиться в том, что это действительно ошибка и она присутствует в последней версии Bash, доступной на ftp://ftp.gnu.org/pub/gnu/bash/. Когда ясно, что ошибка действительно имеется, следует воспользоваться командой bashbug для представления сведений. Если ошибку удалось исправить самостоятельно, следует включить исправления в отчет. Предложения и «философские» сообщения об ошибках следует направлять по адресу bug-bash@gnu.org или в конференцию Usenet gnu.bash.bug.

В отчет об ошибке следует включать:

  • номер версии Bash;

  • указание оборудования и операционной системы;

  • компилятор, использованный для сборки Bash;

  • описание ошибочного поведения;

  • краткий сценарий или «задание» для воспроизведения ошибки.

Программа bashbug три первых элемента определяет автоматически по шаблону сообщения. Информацию следует направлять по адресу bug-bash@gnu.org.

Приложение B. Основные отличия от Bourne Shell

Bash использует в точности такую же грамматику, преобразование слов и переменных, перенаправление и экранирование как Bourne Shell. Bash использует стандарт POSIX в качестве спецификации для реализации этих свойств. Имеются некоторые различия между традиционной оболочкой Bourne и Bash, которые кратко перечислены ниже. Многие из этих различий подробно рассмотрены в предыдущих главах. Для сравнения использована версия sh, включенная в SVR4.2 (последняя версия Bourne).

  • Bash следует стандарту POSIX, даже при отличии POSIX от традиционного поведения sh (6.11. Режим POSIX).

  • Bash поддерживает многосимвольные опции вызова (6.1. Вызов Bash).

  • Bash включает редактирование команд (8. Редактирование командной строки) и внутреннюю команду bind.

  • Bash обеспечивает механизм программируемого дополнения слов (8.6. Программируемое дополнение) и внутренние команды complete, compgen, compopt для управления им.

  • Bash поддерживает историю команд (9.1. Средства Bash History) и внутренние команды history и fc для работы с ней. Список истории Bash поддерживает временные метки и использует переменную HISTTIMEFORMAT для их вывода.

  • Bash реализует преобразование истории в стиле csh (9.3. Преобразование истории).

  • Bash поддерживает переменные одномерных массивов (6.7. Массивы), а также соответствующие преобразования назначение переменных для них. Некоторые внутренние команды Bash принимают опции для работы с массивами. Bash имеет множество внутренних переменных-массивов.

  • Поддерживается синтаксис $’…’, расширяющий \-экранирование ANSI-C внутри одинарных кавычек (3.1.2.4. Кавычки ANSI-C).

  • Bash Поддерживает синтаксис $»…» для зависимых от языка трансляций символов в двойных кавычках. Опции вызова -D, —dump-strings и —dump-po-strings выводят транслируемые строки, найденные в сценарии (3.1.2.5. Зависимая от языка трансляция).

  • Bash поддерживает ключевое слово ! Для инвертирования значений, возвращаемых конвейерами (3.2.2. Конвейеры). Это очень полезно, когда оператор if должен действовать лишь при отрицательном результате проверки. Опция Bash -o pipefail ведет к возврату конвейером отказа при отказе любой из его команд.

  • Bash поддерживает зарезервированное слово time и синхронизацию команд (3.2.2. Конвейеры). Выводом статистики синхронизации можно управлять с помощью переменной TIMEFORMAT.

  • Bash реализует конструкцию for (( expr1 ; expr2 ; expr3 )) для команд подобно языку C (3.2.4.1. Конструкции с циклами).

  • Bash включает составную команду select для создания простых меню (3.2.4.2. Конструкции с условием).

  • Bash включает составную команду [[, которая делает проверку условия частью грамматики (3.2.4.2. Конструкции с условием), включая необязательное сопоставление с регулярным выражением.

  • Bash поддерживает необязательное сопоставление без учета регистра символов в конструкциях case и [[.

  • Bash включает преобразование скобок (3.5.1. Раскрытие скобок) и тильды (3.5.2. Преобразование тильды).

  • Bash реализует псевдонимы команд и внутренние команды alias и unalias (6.6. Псевдонимы).

  • Bash поддерживает арифметику оболочки, составную команду (( (3.2.4.2. Конструкции с условием) и арифметические преобразования (6.5. Арифметика командного процессора).

  • Переменные из начального окружения оболочки автоматически экспортируются в дочерние процессы. Оболочка Bourne обычно не делает этого без явной маркировки переменных для экспорта.

  • Bash поддерживает оператор присваивания += который добавляет значение в конец переменной, указанной слева от оператора.

  • Bash включает шаблоны POSIX %, #, %% и ## для удаления подстрок в начале или в конце значений переменных (3.5.3. Преобразование параметров оболочки).

  • Поддерживается преобразование ${#xx}, возвращающее размер ${xx} (3.5.3. Преобразование параметров оболочки).

  • Имеется расширение ${var:offset[:length]}, которое преобразует подстроку значения var размером length, начиная со смещения offset (3.5.3. Преобразование параметров оболочки).

  • Доступно преобразование ${var/[/]pattern[/replacement]}, которое сопоставляет с шаблоном pattern и выполняет замену на replacement в значении переменной var (3.5.3. Преобразование параметров оболочки).

  • Доступно преобразование ${!prefix*}, которое извлекает имена всех переменных оболочки, начинающиеся с prefix (3.5.3. Преобразование параметров оболочки).

  • Bash поддерживает непрямое преобразование переменных ${!word} (3.5.3. Преобразование параметров оболочки).

  • Bash может извлекать позиционные параметры сверх $9, используя ${num}.

  • Реализована форма подстановки команд POSIX $() (3.5.4. Подстановка команд), которая предпочтительней формы Bourne ‘‘ (поддерживается для совместимости).

  • Bash включает подстановку процессов (3.5.6. Подстановка процессов).

  • Bash автоматически назначает переменные, предоставляющие информацию о текущем пользователе (UID, EUID, GROUPS), хосте (HOSTTYPE, OSTYPE, MACHTYPE, HOSTNAME) и работающем экземпляре Bash (BASH, BASH_VERSION, BASH_VERSINFO), как описано в разделе 5.2. Переменные Bash.

  • Используется переменная IFS для расщепления лишь результатов преобразования, а не всех слов (3.5.7. Расщепление слов). Это закрывает давно известный дефект защиты.

  • Код преобразования имен файлов в скобках использует символы ! и ^ для инвертирования набора символов внутри скобок. Оболочка Bourne использует лишь !.

  • Bash реализует полный набор операторов преобразования имен файлов POSIX, включая классы символов, классы эквивалентности и сортировку символов (3.5.8. Преобразование имен файлов).

  • Bash реализует расширенное сопоставление с шаблонами при включенной опции оболочки extglob (3.5.8.1. Сопоставление с шаблоном).

  • Могут существовать одноименные переменная и функция. Оболочка sh не разделяет эти пространства имен.

  • Функции Bash могут использовать локальные переменные с помощью внутренней команды local, что позволяет создавать рекурсивные функции (4.2. Внутренние команды bash).

  • Назначение переменных перед командой влияет лишь на эту команду, внутренние команды и функции (3.7.4. Окружение). В sh все назначения переменных перед командами являются глобальными, если команда не выполняется из файловой системы.

  • Bash выполняет преобразование для имен файлов, заданных как операнды для операторов перенаправления ввода и вывода (3.6. Перенаправление).

  • Bash включает оператор перенаправления <>, позволяющий открыть файл для чтения и записи, а также оператор &> для перенаправления стандартного вывода и вывод ошибок в один файл (3.6. Перенаправление).

  • Bash включает оператор перенаправления <<<, позволяющий использовать строку в качестве стандартного ввода для команды.

  • Bash включает операторы перенаправления [n]<&word и [n]>&word, переносящие один дескриптор файла в другой.

  • Bash использует особую трактовку некоторых имен файлов в операторах перенаправления (3.6. Перенаправление).

  • Bash позволяет создавать сетевые соединения с любыми машинами и службами в операторах перенаправления (3.6. Перенаправление).

  • Поддерживается опция noclobber, позволяющая переписывать существующие файлы при перенаправлении вывода (4.3.1. Внутренняя команда set). Оператор >| позволяет переопределить опцию noclobber.

  • Внутренние команды Bash cd и pwd (4.1. Внутренние элементы Bourne Shell) принимают опции -L и -P для переключения между физическим и логическим режимом.

  • Bash позволяет функциям переопределять одноименные внутренние команды и обеспечивает доступ к функциональности этих внутренних команд с помощью внутренних команд builtin и command (4.2. Внутренние команды bash).

  • Внутренняя команда command позволяет селективно отключать функции при поиске команд (4.2. Внутренние команды bash).

  • Внутренние команды можно селективно включать и отключать внутренней командой enable (4.2. Внутренние команды bash).

  • Внутренняя команда Bash exec принимает опции, позволяющие пользователям управлять содержимым окружения, передаваемого выполняемой команде, а также передаваемым команде нулевым аргументом (4.1. Внутренние элементы Bourne Shell).

  • Функции оболочки могут экспортироваться в дочерние процессы через окружение с помощью export -f (3.3. Функции оболочки).

  • Внутренние функции Bash export, readonly и declare могут принимать опцию -f для воздействия на функции оболочки, опцию -p для вывода переменных с различными атрибутами в формате, пригодном для ввода, опцию -n для удаления атрибутов переменных и аргументы name=value для задания одновременно переменных и значений.

  • Внутренняя команда Bash hash позволяет связать имя с произвольным именем файла, даже если файл нельзя найти по переменной $PATH, с помощью hash -p (4.1. Внутренние элементы Bourne Shell).

  • Bash включает внутреннюю команду help для получения справок о возможностях оболочки (4.2. Внутренние команды bash).

  • Внутренняя команда printf обеспечивает форматированный вывод (4.2. Внутренние команды bash).

  • Внутренняя команда Bash read (4.2. Внутренние команды bash) будет читать строки, завершающиеся символом \, с опцией -r и использовать переменную REPLY по умолчанию, если нет аргументов, не являющихся опциями. Эта команда также принимает строку приглашения с опцией -p и будет использовать Readline для получения строк, если задана опция -e. Команда read также поддерживает опции управления вводом — -s выключает эхо вводимых символов при их чтении, -t позволяет задать тайм-аут для ввода, -n позволяет считывать лишь заданное число символов, а -d будет читать до ввода определенного символа, а не новой строки.

  • Внутренняя команда return может служить для прерывания работы сценариев, вызванных по внутренней команде . или source (4.1. Внутренние элементы Bourne Shell).

  • Bash включает внутреннюю функцию shopt для тонкой настройки дополнительных возможностей (4.3.2. Внутренняя команда shopt) и позволяет устанавливать и сбрасывать опции при вызове оболочки (6.1. Вызов Bash).

  • Bash обеспечивает множество опций контроля поведения с помощью внутренней команды set (4.3.1. Внутренняя команда set).

  • Опция -x (xtrace) выводит команды, отличающиеся от простых, при трассировке выполнения (4.3.1. Внутренняя команда set).

  • Внутренняя команда test (4.1. Внутренние элементы Bourne Shell) несколько отличается, поскольку она реализует алгоритм POSIX, определяющий поведение на основе множества аргументов.

  • Bash включает внутреннюю команду caller, выводящую контекст любого активного вызова подпрограммы (shell-функции или сценария, выполняемого по команде . или source). Это позволяет отлаживать bash.

  • Внутренняя команда trap (4.1. Внутренние элементы Bourne Shell) позволяет задать псевдосигнал DEBUG, похожий на EXIT. Команды с ловушкой DEBUG выполняются перед каждой простой командой, командами for, case и select, каждой арифметической командой и первой командой, выполняемой в shell-функции. Ловушка DEBUG не наследуется функциями оболочки, если им не назначен атрибут trace или не включена опция functrace с помощью внутренней команды shopt. Опция оболочки extdebug оказывает дополнительное влияние на DEBUG.

    Внутренняя функция trap (4.1. Внутренние элементы Bourne Shell) позволяет задать псевдосигнал ERR, похожий на EXIT и DEBUG. Команды, заданные с ловушкой ERR, выполняются после отказов простых команд с некоторыми исключениями. Ловушка ERR не наследуется функциями оболочки, если не включена опция -o внутренней функцией set.

    Внутренняя команда trap (4.1. Внутренние элементы Bourne Shell) позволяет задать псевдосигнал RETURN, похожий на EXIT и DEBUG. Команды, заданные с ловушкой RETURN, выполняются перед возобновлением исполнения после возврата из shell-функции или сценария, запущенного командой . или source. Ловушка RETURN не наследуется функциями оболочки, если им не назначен атрибут trace или не включена опция functrace с помощью внутренней команды shopt.

  • Внутренняя команда Bash type расширена и дает больше информации о найденных именах (4.2. Внутренние команды bash).

  • Внутренняя команда Bash umask поддерживает опцию -p для вывода в формате пригодном для ввода (4.1. Внутренние элементы Bourne Shell).

  • Bash реализует стек каталогов в стиле csh и внутренние команды pushd, popd, dirs для работы с ним (6.8. Стек каталогов). Bash также позволяет просматривать стек каталогов как значение переменной оболочки DIRSTACK.

  • Bash интерпретирует специальные символы с \-экранированием в строке приглашения при интерактивном режиме (6.9. Управление формой приглашения).

  • Ограниченный режим в Bash (6.10. Ограниченная оболочка) более полезен, нежели в SVR4.2.

  • Внутренняя команда disown может удалять задания из внутренней таблицы оболочки (7.1. Основы управления заданиями) или предотвращать отправку заданиям сигналов SIGHUP при завершении оболочки по сигналу SIGHUP.

  • Bash включает множество возможностей для отладки сценариев оболочки.

  • Оболочка SVR4.2 имеет две связанных с привилегиями внутренних команды (mldmode и priv), отсутствующих в Bash.

  • Bash не имеет внутренних команд stop и newgrp.

  • Bash не использует переменную SHACCT и не выполняет учета.

  • SVR4.2 sh использует переменную TIMEOUT, в Bash — TMOUT.

Уникальные для Bash возможности описаны в главе 6. Свойства Bash.

B.1 Отличия от оболочки SVR4.2

Поскольку Bash является совершенно новой реализацией, здесь нет многих ограничений, присущих оболочке SVR4.2.

  • Bash не создает субоболочку при переходе в структуру управления (или из нее), такую как оператор if или while.

  • Bash не разрешает несбалансированные кавычки. Оболочка SVR4.2 в некоторых случаях просто вставляет недостающие кавычки перед EOF, что может приводить к трудно обнаруживаемым ошибкам.

  • Оболочка SVR4.2 использует схему управления памятью в стиле «барокко» (baroque) на основе ловушек SIGSEGV. Если оболочка запускается из процесса с блокировкой SIGSEGV (например, путем вызова функции system() из библиотеки C), она ведет себя некорректно.

  • В сомнительной попытке обеспечения безопасности оболочка SVR4.2 при вызове без опции -p меняет действительные и эффективные значения uid и gid, если они меньше некого порогового значения (обычно 100). Это может приводить к непредсказуемым результатам.

  • Оболочка SVR4.2 не разрешает пользователям ловушки SIGSEGV, SIGALRM, SIGCHLD.

  • Оболочка SVR4.2 не разрешает пользователям отменять переменные IFS, MAILCHECK, PATH, PS1, PS2.

  • Оболочка SVR4.2 трактует ^ как недокументированный эквивалент |.

  • Bash допускает использование при вызове нескольких аргументов (-x -v), а SVR4.2 — только один (-xv). Фактически некоторые версии оболочки завершают работу аварийно (dump core), если второй аргумент начинается с -.

  • Оболочка SVR4.2 выходит из сценария при отказе встроенной команды, а Bash — только при отказе некоторых особых внутренних команд POSIX и лишь при определенных обстоятельствах, указанных в стандарте POSIX.

  • Оболочка SVR4.2 иначе ведет себя при вызове как jsh (включает управление заданиями).

Приложение C. GNU Free Documentation License

Version 1.3, 3 November 2008

Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.

http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain ascii without markup, Texinfo input format, LaTEX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

The “publisher” means any person or entity that distributes copies of the Document to the public.

A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.

  15. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.

11. RELICENSING

“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.

“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.

“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.

An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (C) year your name.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ‘‘GNU Free Documentation License’’.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with. . . Texts.” line with this:

with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Portable object — переносимый объект.

2В зависимости от настройки Backspace может удалять символ слева от курсора, а DEL — в позиции курсора как C-d.

3Клавиша удаления последнего введенного символа, например, Backspace.

4Control Sequence Indicator.

5Andrew File System — распределенная файловая система на основе защищенных серверов.

Рубрика: Linux | Комментарии к записи Справочник по командному процессору Bash отключены

Руководство по разработке проектов в Yocto Project (часть 2)

Часть 1

3.13. Использование x32 psABI

Двоичный интерфейс приложений x32 ABI (x32 psABI) является естественным ABI для архитектуры Intel® 64 (x86-64) и определяет соглашения о вызовах функций в среде обработки, задавая используемые регистры и размеры различных типов данных C.

Некоторые среды обработки предпочитают использовать 32-битовые приложения даже на 64-разрядных платформах Intel. Рассмотрим i386 psABI, который является самым старым из 32-битовых ABI для платформ Intel 64. i386 psABI не обеспечивает эффективного использования и доступа ко всем ресурсам 64-битовых процессоров Intel 64, оставляя процессоры недогруженными. По сравнению с этим интерфейс x86_64 psABI более новый и использует 64 бита для размеров данных и указателей. Дополнительные биты увеличивают размер программ и библиотек, а также потребности в памяти и дисковом пространстве. Работа в среде x32 psABI позволяет позволяет программам более эффективно использовать ресурсы CPU и системы, а также снижать размер приложений. Дополнительные биты используются для регистров, но не для адресации.

YP поддерживает финальную спецификацию x32 psABI, как показано ниже.

  • Создание пакетов и образов в формате x32 psABI для целевых платформ x86_64.
  • Возможность собирать задания, с использованием инструментария x32.
  • Возможность создавать и загружать образы core-image-minimal и core-image-sato images.
  • Поддержка менеджером RPM имеющихся двоичных файлов x32.
  • Поддержка больших образов.

Для использования x32 psABI нужно включить в файл conf/local.conf приведенные ниже строки.

     MACHINE = "qemux86-64"
     DEFAULTTUNE = "x86-64-x32"
     baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE') \
        or 'INVALID')) or 'lib'}"

После этого можно применять BitBake для сборки образов с поддержкой x32 psABI, например. bitbake core-image-sato.

3.14. Включение поддержки GObject Introspection

GObject introspection является стандартным механизмом доступа к программам на основе Gobject из рабочей среды. GObject является свойством библиотеки Glib, которое предоставляет объектную среду на GNOME и связанных с этой средой программ. GObject Introspection добавляет в GObject информацию, которая позволяет представлять созданные механизмом объекты в разных языках программирования. Если нужно создать конвейеры GStreamer с помощью Python или управлять инфраструктурой UPnP с использованием Javascript и GUPnP, GObject introspection обеспечивает единственный способ сделать это.

В этом разделе описаны средства YP для генерации и упаковки данных GObject introspection, которые представляют собой описание API, обеспечиваемого библиотеками, собранными на основе инфраструктуры GLib, в частности, механизм GObject. Файлы репозитория GObject Introspection (GIR) помещаются в пакеты -dev, файлы typelibв основные пакеты, поскольку они упаковываются вместе с библиотеками, которые подвергаются самоанализу.

Данные создаются при сборке библиотеки путем компоновки библиотеки с небольшим исполняемым модулем, запрашивающим у библиотеки ее описание, а затем выполняющим обработку этого описания. Генерация таких данных в среде кросс-компиляции осложняется тем, что библиотека предназначена для целевой архитектуры, а код должен выполняться на хосте сборки. Эта проблема решается в системе сборки OE запуском кода в QEMU. К сожалению, QEMU не всегда работает хорошо.

3.14.1. Генерация данных самоанализа

Процесс включения генерации данных самоанализа (файлы GIR) для пакета библиотеки включает несколько шагов.

  1. Наследование класса gobject-introspection.
  2. Проверка отсутствия блокировки самоанализа в задании и включаемых файлах. Следует проверить также отсутствие gobject-introspection-data в переменной DISTRO_FEATURES_BACKFILL_CONSIDERED и qemu-usermode в переменной MACHINE_FEATURES_BACKFILL_CONSIDERED, отключающих самоанализ.
  3. Сборка образа. При возникновении ошибок, похожих на невозможность найти библиотеки .so следует найти эти библиотеки в дереве кода и добавить в задание строку вида GIR_EXTRA_LIBS_PATH = «${B}/something/.libs». Примеры использования переменной можно найти в репозитории oe-core.
  4. Другие ошибки могут быть связаны с не совсем стандартной поддержкой самоанализа в пакете, приводящим к проблемам кросс-компиляции. Такие вопросы часто обсуждаются в почтовых конференциях YP.

3.14.2. Запрет генерации данных самоанализа

Если не нужно создавать данные самоанализа (например, QEMU не работает для комбинации сборочного хоста и целевой архитектуры), можно отключить создание файлов GIR любым из приведенных ниже способов.

  • Добавить в конфигурацию дистрибутива строку DISTRO_FEATURES_BACKFILL_CONSIDERED = «gobject-introspection-data», которая отключит генерацию данных самоанализа с помощью QEMU, но сохранит сборку инструментов и библиотек для самоанализа (для этого не требуется QEMU).
  • Добавить в конфигурацию машины строку MACHINE_FEATURES_BACKFILL_CONSIDERED = «qemu-usermode», которая отключит использование QEMU при сборке пакетов для машины. В настоящее время этот вариант применяется только заданиями с самоанализом и дает такой же эффект, как предыдущий вариант. В будущих выпусках YP этот вариант может влиять и на другие свойства.

При отключении генерации данных самоанализа их можно получить иными способами, например, копированием из подходящего каталога sysroot или созданием на целевой платформе. Система сборки OE в настоящее время не включает поддержки таких методов.

3.14.3. Тестирование данных самоанализа для образа

Ниже описана процедура, позволяющая проверить работоспособность данных самоанализа в образе.

  1. Проверка отсутствия gobject-introspection-data в переменной DISTRO_FEATURES_BACKFILL_CONSIDERED и qemu-usermode в переменной MACHINE_FEATURES_BACKFILL_CONSIDERED.
  2. Сборка образа core-image-sato.
  3. Запуск терминальной сессии и Python в этой сессии.
  4. Ввод на терминале команд
         >>> from gi.repository import GLib
         >>> GLib.get_host_name()
  5. Более полное описание доступно по ссылке http://python-gtk-3-tutorial.readthedocs.org/en/latest/introduction.html.

3.14.4. Известные проблемы

С поддержкой GObject Introspection связан ряд проблем, указанных ниже.

  • «Падение» qemu-ppc64, не позволяющее собрать данные самоанализа для архитектуры.
  • Отсутствие поддержки x32 в QEMU и связанное с этим отключение данных самоанализа.
  • «Падение» временных библиотек GLib в musl и связанное с этим отключение данных самоанализа.
  • Отключение данных самоанализа для некоторых пакетов в результате неспособности QEMU корректно выполнять некоторые двоичные файлы для определенной архитектуры (например, gcr, libsecret, webkit).
  • Некорректная работа QEMU в пользовательском режиме при запуске 64-битовых программ на 32-битовом хосте сборки. В частности, qemumips64 не работает с i686.

3.15. Использование внешних инструментов

Для использования в процесс разработки внешних инструментов следует выполнить ряд действий.

  • Разобраться с местоположением инструментов. Для их сборки потребуются дополнительные действия.
  • Добавить уровень с инструментами в файл bblayers.conf через переменную BBLAYERS.
  • Указать в переменной EXTERNAL_TOOLCHAIN файла local.conf местоположение инструментов.

Хорошим примером использования внешних инструментов в YP является Mentor Graphics® Sourcery G++. Информация об использовании инструментов приведена в файле README на странице http://github.com/MentorEmbedded/meta-sourcery/. Дополнительная информация приведена также в описании переменной TCMODE [3].

3.16. Создание образов с дисковыми разделами с помощью Wic

Создание образа для определенной аппаратной платформы с использованием системы сборки не обязательно ведет к возможности загрузки этого образа на устройстве. Физические устройства принимают и загружают образы разными способами с учетом своих возможностей. Обычно информация об устройстве может подсказать нужный формат. Если для устройства нужны несколько разделов на SD-карте, флэш-диске или HDD, можно использовать OE Image Creator (Wic) для создания образа с разделами.

Команда wic создает образы с разделами из результатов сборки OE. Генерация образа управляется командами разбиения из файла OE kickstart (.wks), заданного в команде напрямую или выбранного из стандартных файлов, которые можно увидеть по команде wic list images (3.16.5. Использование имеющихся файлов Kickstart). Использование команды для имеющихся результатов сборки приводит к созданию одного или нескольких образов, которые можно записать на носитель и поместить в устройство. Описание файлов kickstart приведено в разделе OpenEmbedded Kickstart (.wks) Reference [3].

Команда wic и инфраструктура, на которой она основана, по определению неполны. Задача команды — разрешить создание настраиваемых образов, поэтому команда проектировалась для расширения через интерфейс подключаемых модулей, описанных в параграфе 3.16.6. Использование интерфейса подключаемых модулей Wic.

3.16.1. Основы

Здесь приведены некоторые сведения об утилите Wic, которые могут быть интересны, хотя и не требуются для работы.

  • Имя Wic образовано от oeic1, где дифтонг oe произносится как w, поскольку oeic сложней запомнить и сказать.
  • Wic базируется на платформе Meego Image Creator (mic), но реализация Wic существенно переработана для прямого использования результатов сборки OE вместо установки и настройки пакетов, которые уже включены в результаты OE.
  • Wic является независимой автономной утилитой, которая является более простой и гибкой в сравнении с классом OE-Core image-live. Функциональность Wic реализована базовым языком разбиения, основанным на синтаксисе Redhat kickstart.

3.16.2. Требования

Для использования Wic в системе сборки OE нужно выполнить приведенные ниже требования.

  • Дистрибутив Linux на хосте сборки должен поддерживать YP (см. раздел Supported Linux Distributions [3]).
  • На хосте сборки должны быть установлены стандартные системные утилиты, такие как cp.
  • Следует выполнить сценарий инициализации среды (oe-init-build-env) из каталога сборки.
  • Результаты сборки должны быть доступны, что обычно означате наличие собранного с помощью OE образа (например, core-image-minimal). Создание образа для генерации образа с помощью Wic модет показаться избыточным, но для текущей версии Wic нужны результаты работы системы сборки OE.
  • Нужно собрать несколько естественных инструментов для работы на хосте сборки с помощью команды bitbake parted-native dosfstools-native mtools-native.
  • Нужно включить wic в переменную IMAGE_FSTYPES.
  • Нужно включить имя файла kickstart в переменную WKS_FILE.

3.16.3. Доступ к справочной информации

Можно получить справку о работе с командой с помощью команды wic с опцией wic -h, wic —help или wic help. В настоящее время Wic поддерживает 7 команд — cp, create, help, list, ls, rm, write. Для получения справки по работе с ними служат команды вида wic help command. Например, команда wic help write выведет справку о работе с командой write. Wic поддерживает 3 темы справок — overview, plugins и kickstart. Можно получить справку по любой из тем командой вида wic help topic. Например, для получения обзорной справки служит команды wic help overview.

Имеется дополнительный вид справок для Wic, показывающий список доступных образов Wic.

     $ wic list images
       mpc8315e-rdb     	Create SD card image for MPC8315E-RDB
       genericx86       	Create an EFI disk image for genericx86*
       beaglebone-yocto 	Create SD card image for Beaglebone
       edgerouter       	Create SD card image for Edgerouter
       qemux86-directdisk	Create a qemu machine 'pcbios' direct disk image
       directdisk-gpt   	Create a 'pcbios' direct disk image
       mkefidisk        	Create an EFI disk image
       directdisk       	Create a 'pcbios' direct disk image
       systemd-bootdisk 	Create an EFI disk image with systemd-boot
       mkhybridiso      	Create a hybrid ISO image
       sdimage-bootpart 	Create SD card image with a boot partition
       directdisk-multi-rootfs	Create multi rootfs image using rootfs plugin
       directdisk-bootloader-config	Create a 'pcbios' direct disk image with custom bootloader config

Зная список образов, можно получить справку по конкретному образу с помощью команды вида

     $ wic list beaglebone-yocto help
     Creates a partitioned SD card image for Beaglebone.
     Boot files are located in the first vfat partition.

3.16.4. Режимы работы

В зависимости от уровня управления результатами вывода системы сборки OE доступны 2 режима — Raw и Cooked:

  • режим Raw позволяет явно указать результаты сборки параметрами команды Wic;
  • режим Cooked использует текущую установку MACHINE и имя образа для автоматического выбора результатов сборки, включаемых в образ; нужно лишь указать файл kickstart и имя образа для включения результатов сборки.

В любом случае результаты сборки должны быть доступны в момент ввода команды.

3.16.4.1. Режим Raw

Запуск Wic в режиме raw позволяет указать все разделы в строке команды. Основным применением этого режима является создание образов при сборке ядра за пределами дерева YP. Иными словами, можно указать произвольное ядро, размещение корневой файловой системы и т. п. В режиме cooked просматривается лишь каталог сборки (например, tmp/deploy/images/machine). Команда wic имеет вид wic create wks_file options

wks_file

Файл OpenEmbedded kickstart. Можно использовать свой файл или один из имеющихся в системе сборки.

Дополнительные аргументы рассмотрены ниже.

-h, —helpshow

выводит справочную информацию и завершает работу.

-o OUTDIR, —outdir OUTDIR

каталог для создания образа.

-e IMAGE_NAME, —image-name IMAGE_NAME

имя образа для использования результатов сборки (например, core-image-sato).

-r ROOTFS_DIR, —rootfs-dir ROOTFS_DIR

путь к каталогу /rootfs для использования в качестве источника .wks rootfs.

-b BOOTIMG_DIR, —bootimg-dir BOOTIMG_DIR

путь к каталогу с элементами загрузки (например, /EFI или /syslinux) для использования в .wks bootimg.

-k KERNEL_DIR, —kernel-dir KERNEL_DIR

путь к каталогу с ядром для использования в .wks bootimg

-n NATIVE_SYSROOT, —native-sysroot NATIVE_SYSROOT

путь к native sysroot с инструментами, использованными при сборке образа.

-s, —skip-build-check

задает пропуск проверки сборки.

-f, —build-rootfs

rootfs для сборки.

-c {gzip,bzip2,xz}, —compress-with {gzip,bzip2,xz}

задает алгоритм сжатия образа.

-m, —bmapgenerate

.bmap

—no-fstab-update

отключает изменения файла fstab.

-v VARS_DIR, —vars VARS_DIR

каталог с файлами <image>.env. Содержащими переменные bitbake.

-D, —debug

задает вывод отладочной информации.

Для запуска Wic не нужны полномочия root и даже не следует использовать утилиту от имени root.

3.16.4.2. Режим Cooked

Wic в режиме cooked использует элементы из каталога сборки. Иными словами, не нужно указывать размещение ядра и корневой файловой системы, достаточно указать файл kickstart и образ из которого берутся результаты сборки, с помощью опции -e. Wic в режиме Cooked запускается командой вида wic create wks_file -e IMAGE_NAME.

wks_file

Имя файла OE kickstart. Можно использовать свой файл или один из файлов в составе выпуска YP.

Обязательный аргумент

-e IMAGE_NAME, —image-name IMAGE_NAME — имя образа для использования результатов сборки (например, core-image-sato)

3.16.5. Использование имеющихся файлов Kickstart

Можно не создавать свой файл kickstart, воспользовавшись готовыми из состава Wic. Эти файлы можно найти в репозитории YP (каталог poky/meta-yocto-bsp/wic или poky/scripts/lib/wic/canned-wks). Для просмотра доступных файлов можно использовать команду wic list images.

     $ wic list images
       mpc8315e-rdb     	Create SD card image for MPC8315E-RDB
       genericx86       	Create an EFI disk image for genericx86*
       beaglebone-yocto 	Create SD card image for Beaglebone
       edgerouter       	Create SD card image for Edgerouter
       qemux86-directdisk	Create a qemu machine 'pcbios' direct disk image
       directdisk-gpt   	Create a 'pcbios' direct disk image
       mkefidisk        	Create an EFI disk image
       directdisk       	Create a 'pcbios' direct disk image
       systemd-bootdisk 	Create an EFI disk image with systemd-boot
       mkhybridiso      	Create a hybrid ISO image
       sdimage-bootpart 	Create SD card image with a boot partition
       directdisk-multi-rootfs	Create multi rootfs image using rootfs plugin
       directdisk-bootloader-config	Create a 'pcbios' direct disk image with custom bootloader config

При использовании имеющегося файла не нужно указывать расширение .wks. Ниже приведен пример использования файла directdisk в режиме Raw.

$ wic create directdisk -r rootfs_dir -b bootimg_dir -k kernel_dir -n native_sysroot

Фактические команды языка разбиения, используемые в файле genericx86.wks для создания образа, показаны ниже.

# short-description: Create an EFI disk image for genericx86*
# long-description: Creates a partitioned EFI disk image for genericx86* machines
part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --active --align 1024
part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 --use-uuid
part swap --ondisk sda --size 44 --label swap1 --fstype=swap

bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"

3.16.6. Использование интерфейса подключаемых модулей Wic

Можно расширить и настроить Wic с помощью подключаемых модулей (plug-in). Плагины Wic состоят из двух частей — source и imager (не рассматриваются здесь). Модули source обеспечивают механизм настройки содержимого разделов в процессе генерации образа. Можно использовать модули source для отображения значений, указываемых командами —source в файлах *.wks на реализацию модуля, применяемого для заполнения раздела.

При использовании модулей, связанных зависимостями (например, от инструментов native, загрузчиков и т. п.) во время построения образа Wic, нужно указать эти зависимости в переменной WKS_FILE_DEPENDS. Модули source являются субклассом, определяемым в файлах plug-in. Некоторые из таких файлов входят в состав YP. Каждый файл содержит плагины source, предназначенные для заполнения разделов в образах Wic. Класс SourcePlugin, к которому относятся модули source, определен в файле poky/scripts/lib/wic/pluginbase.py.

Можно реализовать модули source на уровне, лежащем вне репозитория исходных кодов (внешний уровень). При этом они должны находиться в каталоге scripts/lib/wic/plugins/source/ внутри этого уровня, чтобы быть доступными для Wic.

Когда реализации Wic нужно вызвать зависящую от раздела реализацию, просматриваются плагины с именем, указанным параметром —source в файле kickstart для этого раздела. Например, при установке раздела с помощью команды part /boot —source bootimg-pcbios —ondisk sda —label boot —active —align 1024 используются методы, определенные как члены класса соответствующего подключаемого модуля source (bootimg-pcbios) в файле bootimg-pcbios.py.

Ниже приведено соответствующее определение плагина из the bootimg-pcbios.py для предыдущей команды вместе с примером метода, вызываемого реализацией Wic для подготовки раздела с зависимой от реализации функцией.

      ...
     class BootimgPcbiosPlugin(SourcePlugin):
         """
         Create MBR boot partition and install syslinux on it.
         """

         name = 'bootimg-pcbios'
      ...
         @classmethod
         def do_prepare_partition(cls, part, source_params, creator, cr_workdir,
          oe_builddir, bootimg_dir, kernel_dir,
          rootfs_dir, native_sysroot):
 """
 Called to do the actual content population for a partition i.e. it
 'prepares' the partition to be incorporated into the image.
 In this case, prepare content for legacy bios boot partition.
 """
      ...

Если субкласс (plug-in) сам не реализует определенную функцию, Wic находит и использует принятую по умолчанию версию надкласса (superclass). По этой причине все модули source выводятся из класса SourcePlugin. Этот класс, определенный в pluginbase.py, включает набор методов, которые модули source plug-ins могут использовать или переопределять. Все плагины (субкласс SourcePlugin), не реализующие тот или иной метод, наследуют его реализацию от класса SourcePlugin. Описание SourcePlugin можно найти в файле pluginbase.py, а ниже приведен список реализованных в этом классе методов.

  • do_prepare_partition() вызывается для заполнения раздела содержимым. Иными словами, метод готовит окончательный образ раздела для встраивания в образ диска.
  • do_configure_partition() вызывается перед do_prepare_partition() для создания конфигурационных файлов раздела (например, для syslinux или grub).
  • do_install_disk() вызывается после того, как все разделы подготовлены и собраны в образ диска. Этот метод обеспечивает завершение записи образа диска (например, запись MBR).
  • do_stage_partition()специальный метод подготовки содержимого перед вызовом do_prepare_partition(). Обычно этот метод пуст. Раздел, как правило, просто использует переданные параметры (например, неизменное значение bootimg_dir), однако в некоторых случаях может потребоваться особый подход. Например, могут потребоваться некоторые файлы из bootimg_dir + /boot. Этот метод позволяет размещать такие файлы индивидуально. Метод get_bitbake_var() обеспечивает доступ к нестандартным переменным, которые могут применяться в таких случаях.

Механизм модулей source можно расширить путем добавления «ловушек», создания дополнительных методов в SourcePlugin и соответствующих производных субклассов. Код, вызывающий методы, использует функцию plugin.get_source_plugin_methods() для поиска требуемых методов. Поиск реализуется с помощью ключей, содержащих имена методов.

3.16.7. Примеры

В этом разделе приведено несколько примеров использования утилиты Wic. Предполагается, что выполнены все требования раздела 3.16.2. Требования и применяется заранее созданный образ core-image-minimal.

3.16.7.1. Создание образа с имеющимся файлом Kickstart

Здесь используется режим Cooked с kickstart-файлом mkefidisk.

$ wic create mkefidisk -e core-image-minimal
INFO: Building wic-tools...
   .
   .
   .
INFO: The new image(s) can be found here:
  ./mkefidisk-201804191017-sda.direct

The following build artifacts were used to create the image(s):
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native

INFO: The image(s) were created using OE kickstart file:
       /home/stephano/build/master/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks

Это простейший способ создать образ в режиме cooked с указанием kickstart-файла и опции -e для задания имеющихся результатов сборки. В файле local.conf переменная MACHINE должна указывать используемую машину (qemux86).

Когда образ собран, выходные данные указывают местоположение образа, использованные результаты и информацию файла kickstart. Следует внимательно проверить эту информацию, чтобы убедиться в корректности собранного образа.

Полученный образ можно записать из каталога сборки на USB-носитель или иную среду и загрузить систему с нее. Для записи можно использовать команду bmaptool или dd, как показано ниже.

$ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX

или

$ sudo dd if=mkefidisk-201804191017-sda.direct of=/dev/sdX

Информация об использовании bmaptool приведена в разделе 3.17. Запись образов с помощью bmaptool.

3.16.7.2. Использование измененного файла Kickstart

Поскольку созданием образа с разделами управляет файл kickstart, изменение параметров файле позволяет влиять на получаемый образ. Ниже приведен пример этого с использованием файла directdisk-gpt.

Как было отмечено, команда wic list images выводит список имеющихся kickstart-файлов. Файл directdisk-gpt.wks размещается в каталоге scripts/lib/image/canned-wks/ внутри дерева исходных кодов (например, poky). В этом каталоге размещаются другие файлы и можно создать свой kickstart-файл. Имеющийся файл directdisk-gpt содержит почти все, что нужно для примера. Однако для загрузки образа в примере будет применяться устройство sdb вместо sda, указанного в файле directdisk-gpt.

В примере сначала создается копия файла directdisk-gpt.wks с другим именем в каталоге scripts/lib/image/canned-wks.

     $ cp /home/stephano/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
          /home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks

Затем ф копии directdisksdb-gpt.wks строка «—ondisk sda» заменяется на «—ondisk sdb«, как показано ниже.

part /boot --source bootimg-pcbios --ondisk sdb --label boot --active --align 1024
part / --source rootfs --ondisk sdb --fstype=ext4 --label platform --align 1024 --use-uuid

Этот файл будет создавать образ directdisksdb-gpt с результатами сборки core-image-minimal для машины Next Unit of Computing (nuc), указанной переменной MACHINE в файле local.conf.

$ wic create directdisksdb-gpt -e core-image-minimal
INFO: Building wic-tools...
...
Initialising tasks: 100% |#######################################| Time: 0:00:01
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1161 tasks of which 1157 didn't need to be rerun and all succeeded.
INFO: Creating image(s)...

INFO: The new image(s) can be found here:
       ./directdisksdb-gpt-201710090938-sdb.direct

The following build artifacts were used to create the image(s):
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR:       /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT:   /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native

INFO: The image(s) were created using OE kickstart file:
  /home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks

В продолжение примера образ записывается с помощью команды dd на накопитель USB или иную среду для загрузки.

     $ sudo dd if=directdisksdb-gpt-201710090938-sdb.direct of=/dev/sdb
     140966+0 records in
     140966+0 records out
     72174592 bytes (72 MB, 69 MiB) copied, 78.0282 s, 925 kB/s
     $ sudo eject /dev/sdb
3.16.7.3. Использование измененного файла Kickstart и работа в режиме Raw

В следующем примере вручную задаются все включаемые в образ результаты сборки (режим Raw) и используется измененный файл kickstart. Применяется также опция -o, заставляющая Wic создавать в отличном от принятого по умолчанию каталоге.

$ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \
--rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
--bootimg-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \
--kernel-dir /home/stephano/build/master/build/tmp/deploy/images/qemux86 \
--native-sysroot /home/stephano/build/master/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native

INFO: Creating image(s)...

INFO: The new image(s) can be found here:
  /home/stephano/testwic/test-201710091445-sdb.direct

The following build artifacts were used to create the image(s):
ROOTFS_DIR:       /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR:      /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR:       /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT:   /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native

INFO: The image(s) were created using OE kickstart file:
  /home/stephano/my_yocto/test.wks

В этом примере переменная MACHINE не задана в файле local.conf, поэтому результаты сборки указываются вручную.

3.16.7.4. Использование Wic для манипуляций с образом

Возможности Wic позволяют сократить время разработки образа. Например, можно использовать Wic для удаления раздела ядра из образа, а затем поместить туда новый образ ядра. Это позволит не собирать образ полностью, ограничившись сборкой образа ядра.

В рассматриваемом ниже примере предполагается наличие на хосте разработки установленного пакета mtools. В примере из образа Wic удаляется удаляется ядро, затем в образ помещается новое ядро.

  1. Просмотр списка разделов с помощью команды wic ls.
         $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
         Num     Start        End          Size      Fstype
          1       1048576     25041919     23993344  fat16
          2      25165824     72157183     46991360  ext4    

    Вывод показывает два раздела в образе core-image-minimal-qemux86.wic.

  2. Проверка отдельного раздела с помощью команды wic ls.
         $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1
         Volume in drive : is boot
          Volume Serial Number is E894-1809
         Directory for ::/
    
         libcom32 c32    186500 2017-10-09  16:06
         libutil  c32     24148 2017-10-09  16:06
         syslinux cfg       220 2017-10-09  16:06
         vesamenu c32     27104 2017-10-09  16:06
         vmlinuz        6904608 2017-10-09  16:06
     5 files           7 142 580 bytes
          16 582 656 bytes free    

    Вывод команды показывает 5 файлов и файл vmlinuz содержит ядро. Если при работе команды возникает показанная ниже ошибка, следует обновить файл ~/.mtoolsrc, убедившись в наличии там строки “mtools_skip_check=1“, и повторить команду Wic.

    ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0
    output: Total number of sectors (47824) not a multiple of sectors per track (32)!
    Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
  3. Удаление имеющегося ядра (vmlinuz) с помощью команды wic rm.
         $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
  4. Добавление нового ядра с помощью команды wic cp. Местоположение нового ядра зависит от способа его сборки. При использовании devtool и SDK ядро записывается в каталог tmp/work directory расширяемого SDK, а при использовании команды makeв каталог workspace/sources. В примере предполагается, что ядро собрано с помощью devtool.
    wic cp ~/poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+git999/arch/x86/boot/bzImage \
    ~/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz 

    После возврата файла ядра в образ можно использовать команду dd или bmaptool для записи образа на карту SD или носитель USB. Отметим, что bmaptool работает в 10 — 20 быстрее, нежели dd.

3.17. Запись образов с помощью bmaptool

Быстрый и простой способ записи образа на загрузочное устройство обеспечивает программа Bmaptool из состава системы сборки OE. Bmaptool является инструментом общего назначения, создающим отображение блоков (bmap) и применяющим его для копирования файла. По сравнению с традиционными средствами, такими как dd и cp, Bmaptool может копировать (записывать) большие файлы существенно быстрее.

При работе с Ubuntu или Debian можно установить пакет bmap-tools и после этого использовать инструмент без указания PATH даже от имени root. Если установить bmap-tools невозможно, потребуется собрать Bmaptool с помощью команды bitbake bmap-tools-native.

Ниже приведен пример записи образа Wic с использованием Bmaptool.

  1. Обновление файла local.conf путем включения строки IMAGE_FSTYPES += «wic wic.bmap».
  2. Подготовка образа. Если образе не был собран заранее с использованием указанной выше переменной IMAGE_FSTYPES, его нужно собрать с помощью команды bitbake image.
  3. Запись образа на устройство с использованием Bmaptool зависит от конкретных настроек. Здесь предполагается, что образ хранится в каталоге deploy/images/ внутри каталога сборки.
    • При наличии прав записи в среду используется команда вида (devX нужно заменить реальным именем).
      $ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX
    • Если прав записи в среду нет, нужно сначала предоставить их с помощью команды sudo chmod 666 /dev/sdX, а затем ввести приведенную выше команду записи.

Для получения справки о работе с bmaptool служит команда bmaptool —help.

3.18. Повышение защищенности образов

Безопасность важна для встраиваемых систем. Ниже приведен ряд ссылок по этим вопросам.

Для защиты образа имеются действия, инструменты и переменные, которые помогут обеспечить безопасность целевого устройства. В этом разделе приведены рекомендации, учет которых позволит сделать образ защищенным. Поскольку требования безопасности и риски отличаются для разных устройств, здесь не представлено полной информации по защите ОС. Настоятельно рекомендуется обратиться к другим источникам информации по защите встраиваемых систем на базе Linux и вопросам безопасности.

3.18.1. Общие вопросы

Ниже перечислены некоторые предложения общего плана, учет которых позволит защитить устройство.

  • Проверка кода, добавляемого в систему (например, приложений), с помощью инструментов статического анализа позволит обнаружить переполнение буферов и другие возможные уязвимости.
  • Особое внимание к защите административных web-интерфейсов, которые зачастую работают с повышенными привилегиями. Это ведет к росту рисков в результате нарушения защиты таких интерфейсов. Следует обратить внимание на основные уязвимости web-систем, такие как кросс-сайтовые сценарии (XSS), непроверяемый ввод и т. п. Как и для системных паролей учетные данные для доступа к web-интерфейсу не должны быть одинаковыми на всех системах. Это особенно важно в тех случаях, когда интерфейс включен по умолчанию, поскольку не все пользователи поменяют сразу учетные записи.
  • Возможность обновления программ на устройстве для устранения обнаруженных уязвимостей, что особо важно для устройств с доступом в сеть.
  • Удаление или запрет функций отладки в окончательном образ, как описано в параграфе 3.18.3. Вопросы, связанные с системой сборки OE.
  • Отключение или удаление ненужных сетевых служб.
  • Удаление из образа ненужных программ.
  • Включение аппаратной поддержки защищенной загрузки, если устройство имеет ее.

3.18.2. Флаги защиты

YP поддерживает флаги защиты, которые позволяют повысить уровень безопасности образов. Флаги защиты определены в файле meta/conf/distro/include/security_flags.inc дерева источников (например, poky). В зависимости от заданий некоторые флаги могут быть установлены или сброшены по умолчанию. Для использования флагов защиты следует включить в файл local.conf или конфигурацию дистрибутива строку require conf/distro/include/security_flags.inc.

3.18.3. Вопросы, связанные с системой сборки OE

Ниже перечислены некоторые действия по повышению уровня защиты образов, связанные с системой сборки OE.

  • Следует исключить debug-tweaks из выбранных в IMAGE_FEATURES свойств. При создании нового проекта в local.conf по умолчанию включается строка EXTRA_IMAGE_FEATURES = «debug-tweaks», для отключения которой достаточно поместить в начало строки символ комментария или исключить из строки debug-tweaks. Эта установка делает пустым пароль root, что может быть полезно при отладке в процессе разработки.
  • Можно установить пароль root для образа, а также пароли иных пользователей (например, администраторов). При установке не следует задавать один пароль для разных образов или пользователей. Предпочтительным методом установки паролей является наследование класса extrausers (см. раздел extrausers.bbclass [3]).
  • Следует рассмотреть вопрос включения инфраструктуры обязательного контроля доступа (MAC), такой как SMACK или SELinux и ее соответствующей настройки на устройстве (см. уровень meta-selinux).

3.18.4. Средства усиления защиты образа

YP включает средства защиты создаваемых образов, которые можно найти на уровне meta-security в Yocto Project Source Repositories.

3.19. Создание своего дистрибутива

При сборке образа с помощью YP без изменения метаданных дистрибутива будет создан дистрибутив Poky. Для более эффективного управления выбором приложений, опциями компиляции и настройками на нижних уровнях можно создать свой дистрибутив. Процесс включает создание уровня дистрибутива, конфигурационного файла, а также добавления нужного кода и уровня метаданных, как описано ниже.

  • Создание уровня для нового дистрибутива, позволяющего хранить метаданные и код. Использование отдельного уровня упрощает воспроизведение конфигурации сборки для разных машин. Создание уровней общего назначения описано в параграфе 3.1.8. Создание базового уровня с помощью сценария bitbake-layers.
  • Создание файла конфигурации дистрибутива в каталоге conf/distro на уровне дистрибутива. Файл следует назвать в соответствии с именем дистрибутива (например, mydistro.conf). Имя дистрибутива указывается в переменной DISTRO файла local.conf. Можно выделить часть конфигурации во включаемые файлы и затем «требовать» (require) их в файле конфигурации дистрибутива. Включаемые файлы следует размещать в каталоге conf/distro/include. Типичным примером использования включаемых файлов является разделения заданий по номеру версии и выпуску. В файле конфигурации должны быть заданы переменные DISTRO_NAME и DISTRO_VERSION. Переменные DISTRO_FEATURES, DISTRO_EXTRA_RDEPENDS, DISTRO_EXTRA_RRECOMMENDS, TCLIBC не обязательны, но обычно включаются в файл конфигурации дистрибутива.Можно создать файл на основе базовой конфигурации из OE-Core (файл conf/distro/defaultsetup.conf) и просто изменить соответствующие переменные. Другим вариантом является создание файла конфигурации с нуля с использованием defaultsetup.conf или файла конфигурации из другого дистрибутива как образца.
  • Включение переменных, которые задают принятые по умолчанию значения или устанавливают значения как часть конфигурации дистрибутива. Можно включать почти все переменные из файла local.conf.
  • Указание файла конфигурации дистрибутива в файле local.conf каталога сборки через переменную DISTRO. Например, если файл конфигурации называется mydistro.conf, указывается строка DISTRO = «mydistro».
  • Добавление других компонент уровня.
    • Добавление заданий для установки специфических для дистрибутива файлов конфигурации, которые не включены в другие задания. Если такие файлы уже имеются в других заданиях, следует создать для них файлы дополнения (.bbappend). Общее описание и рекомендации по добавлению заданий на уровень приведены в параграфах 3.1.1. Создание своего уровня и 3.1.2. Рекомендации по организации уровней.
    • Добавление заданий, относящихся к дистрибутиву.
    • Включение файла дополнения psplash для фирменной заставки, как описано в параграфе 3.1.5. Использование файлов .bbappend на уровне.
    • Включение других файлов дополнения, вносящих изменения в имеющиеся задания.

3.20. Создание шаблона каталога конфигурации

При распространении своей системы сборки другим пользователям может возникнуть желание изменить сообщение, выводимое сценарием установки, а изменить шаблоны файлов конфигурации (local.conf и bblayers.conf) в каталоге сборки.

Система сборки OE использует переменную TEMPLATECONF для указания каталога с данными конфигурации, которые в конечном итоге попадают в каталог conf внутри каталога сборки. По умолчанию задано TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}. Этот каталог используется системой сборки для хранения шаблонов, из которых создаются некоторые файлы конфигурации. В частности, там содержатся файлы bblayers.conf.sample, local.conf.sample и conf-notes.txt, из которых система сборки создает файлы bblayers.conf и local.conf, а также список целей BitBake.

Для переопределения принятых по умолчанию конфигураций в каждом новом каталоге сборки нужно лишь указать каталог в TEMPLATECONF в файле .templateconf на верхнем уровне дерева источников (например, poky).

Практика рекомендует помещать каталог шаблонов конфигурации на уровень дистрибутива. Например, для уровня meta-mylayer в домашнем каталоге можно создать каталог шаблонов конфигурации myconf. Описанное изменение .templateconf заставит систему сборки OE просматривать каталог и создавать файлы конфигурации на основе найденных файлов *.sample. Окончательные файлы конфигурации (local.conf и bblayers.conf) в конечно итоге будут помещены в каталог сборки, но созданы будут на основе файлов *.sample.

     TEMPLATECONF=${TEMPLATECONF:-meta-mylayer/myconf}

Кроме файлов *.sample в принятом по умолчанию каталоге meta-poky/conf хранится также файл conf-notes.txt. Сценарий организации среды сборки (oe-init-build-env) использует этот файл для вывода целей BitBake в процессе выполнения сценария. Редактирование conf-notes.txt обеспечивает возможность указать нужные цели. Ниже показан список целей, выводимых в результате работы сценария.

     You can now run 'bitbake <target>'

     Common targets are:
         core-image-minimal
         core-image-sato
         meta-toolchain
         meta-ide-support

3.21. Экономия дискового пространства при сборке

Для экономии дискового пространства при сборке можно добавить в файл local.conf каталога сборки строку INHERIT += «rm_work» для удаления рабочего каталога задания после сборки этого задания (см. rm_work [3]).

3.22. Работа с пакетами

3.22.1. Исключение пакетов из образа

Иногда возникает потребность исключить некоторые пакеты из образа, для чего имеется несколько переменных, указывающих системе сборки необходимость игнорировать рекомендуемые пакеты или совсем не устанавливать пакет. Каждая из перечисленных ниже переменных работает только с пакетами IPK и RPM, но не работает с Debian. Эти переменные можно указывать в файле local.conf file или привязывать к заданию для конкретного образа путем переопределения имени задания. Более подробная информация о переменных представлена в [3].

  • BAD_RECOMMENDATIONS указывает пакеты, которые не следует устанавливать.
  • NO_RECOMMENDATIONS отменяет установку всех пакетов recommended-only.
  • PACKAGE_EXCLUDE исключает пакет из образа независимо от установки recommended-only. Следует помнить, что это может приводить к отказу, если пакет требуется для установки другого пакета.

3.22.2. Инкрементирование версии пакета

Здесь рассматривается управление нумерацией версий двоичных пакетов и рассмотрены некоторые переменные и термины. Для понимания нумерации версий пакетов нужно принимать во внимание ряд аспектов, указанных ниже.

  • Двоичный пакет — это то, что в конечном итоге устанавливается в образ.
  • Версия двоичного пакета состоит из двух компонент — версия и выпуск (revision).
  • Эпоха (PE) также рассматривается, но в большинстве случаев PE игнорируется.
  • Версия и выпуск берутся из переменных PV и PR.
  • PV указывает версию задания и представляет версию программы. Не следует путать PV с версией двоичного пакета.
  • PRвыпуск задания.
  • SRCPVстрока, используемая системой сборки OE для помощи в определении значения PV, когда нужно включить выпуск исходного кода.
  • PR Serviceсетевая служба, помогающая автоматизировать запись пакетов в хранилища, совместимые с имеющимися менеджерами пакетов, такими как RPM, APT, OPKG.

При каждом изменении содержимого двоичного пакета номер его версии должен меняться. Это обеспечивается путем изменения (bumping) значений PR и/или PV, которое может выполняться одним из двух способов:

  • автоматически с использованием службы выпусков пакетов (PR Service);
  • вручную путем инкрементирования значений переменных PR и/или PV.

С учетом того, что основной задачей системы сборки и ее пользователей является поддержка хранилища пакетов, совместимого с имеющимися менеджерами пакетов, такими как RPM, APT и OPKG, предпочтительно использование автоматизированной системы управления версиями. В любой системе основным требованием к версиям двоичных пакетов является монотонное возрастание и наличие компонент версии, поддерживающих это. Поддержка монотонного роста версий описана в параграфе 3.22.2.3. Автоматическое инкрементирование номера версии пакета.

3.22.2.1. Работа с сервисом PR

Как уже отмечалось, попытка сохранять номера выпусков в метаданных подвержена ошибкам, неточна и создает проблемы для людей, представляющих задания. Служба PR автоматически создает возрастающие номера, в частности для выпуска. Информация о службе PR доступна на странице PR Service.

В YP для упрощения нумерации версий используются переменные PE, PV и PR для эпохи, версии и выпуска. Значения переменных зависят от правил и процедур дистрибутива и хранилища пакетов.

Поскольку система сборки OE использует подписи, которые уникальны для данной сборки, она знает, когда нужно заново собрать пакет. Весь ввод в данную задачу представляется подписью и ее изменение может служить сигналом для повторной сборки. Таким образом, система сборки не использует переменные PR, PV, PE для запуска повторной сборки, однако для создания значений этих переменных могут применяться подписи.

Служба PR работает с генераторами OEBasic и OEBasicHash. Значение PR увеличивается при изменении контрольной суммы, а эти изменения вызываются механизмами генератора. Система сборки включает значения из службы PR в поле PR как дополнение, используя форму .x, так что r0 становится r0.1, r0.2 и т. д. Эта схема позволяет использовать имеющиеся значения PR в всех случаях, включая увеличение PR вручную, когда это требуется.

По умолчанию служба PR выключена и не запущена. В результате пакеты генерируются как «самосогласованные». Система сборки добавляет и удаляет пакеты и нет никаких гарантий по части обновления, но образы будут соответствовать внесенным изменениям. Простейшей формой службы PR является ее организация на хосте сборки, где создаются пакеты для хранилища. В этом случае локальную службу PR можно включить, указав в файле local.conf внутри каталога сборки значение PRSERV_HOST = «localhost:0». После запуска службы пакеты будут автоматически получать возрастающие значения PR и BitBake будет обеспечивать запуск и остановку службы.

При наличии нескольких хостов разработки, работающих с одним хранилищем пакетов, будет использоваться общая служба PR для всех систем сборки. В этом случае службу PR нужно запускать командой bitbake-prserv —host ip —port port —start. Кроме того, нужно обновить файл local.conf на каждом хосте сборки, как описано выше, указав сервер и порт.

Рекомендуется также применять историю сборки, которая добавляет некоторые проверки корректности версий двоичных пакетов. Для этого на каждом хосте сборки нужно добавить в файл local.conf приведенные ниже строки.

     # It is recommended to activate "buildhistory" for testing the PR service
     INHERIT += "buildhistory"
     BUILDHISTORY_COMMIT = "1"

История сборки описана в разделе 3.28. Поддержка качества вывода сборки.

Система сборки OE не поддерживает данные PR как часть общего состояния (sstate). Если sstate поддерживается, все системы сборки должны использовать общую службу PR или эта служба должна быть отключена на всех хостах сборки. Информация о sstate приведена в разделе Shared State Cache [1].

3.22.2.2. Увеличение PR вручную

Вместо установки службы PR можно вручную увеличивать переменную PR. Если зафиксированные изменения приводят в изменению вывода пакета, значение переменной PR должно быть увеличено при фиксации изменений. Для новых заданий следует устанавливать принятое по умолчанию значение r0. Хотя значение r0 задано по умолчанию, его добавление в новое задание снижает вероятность забыть об увеличении переменной при обновлении задания.

При использовании файла .inc для нескольких заданий можно использовать также переменную INC_PR, чтобы все использующие этот файл задания собирались заново при изменении файла .inc. В этом файле должна устанавливаться переменная INC_PR (исходно r0), а в заданиях нужно установить изначально PR = «${INC_PR}.0», увеличивая последнюю часть при обновлении задания. При обновлении файла .inc увеличивается INC_PR.

При обновлении версии двоичного пакета, предполагающем изменение PV, переменную PR следует сбрасывать в r0 (или ${INC_PR}.0 при использовании INC_PR). Обычно увеличение версии происходит лишь для двоичных пакетов. Однако при изменении PV без увеличения можно увеличить переменную PE (эпоха пакета), для которой по умолчанию установлено значение 0.

Нумерацию версий пакетов рекомендуется вести в соответствии с Debian Version Field Policy Guidelines, где определен механизм сравнения версий и понятие увеличения.

3.22.2.3. Автоматическое инкрементирование номера версии пакета

При выборке из репозитория BitBake использует переменную SRCREV для определения конкретного выпуска кода, который будет служить для сборки. Можно установить SRCREV = «${AUTOREV}», чтобы система сборки OE автоматически применяла последний выпуск программы. Кроме того, нужно указать SRCPV в переменной PV для автоматического обновления версии при изменении выпуска исходного кода, например, PV = «1.0+git${SRCPV}». Система сборки OE будет подставлять вместо SRCPV значение AUTOINC+source_code_revision, заменяя AUTOINC числом в зависимости от состояния службы PR.

  • Если служба PR включена, система сборки инкрементирует номер, подобно поведению PR. Это ведет к монотонному росту номера версии пакета, например,
         hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
         hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk    
  • Если служба PR выключена, система сборки заменяет AUTOINC нулем (0). Это ведет к смене версии пакета, поскольку включается выпуск программы, но изменение номера версии не будет монотонным, например,
         hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
         hello-world-git_0.0+git0+dd2f5c3565-r0.0_armv7a-neon.ipk    

3.22.3. Обработка пакетов с необязательными модулями

Многие программы включают необязательные модули (plug-in), сборка которых зависит от опций конфигурации. Чтобы избежать дублирования логики включения модулей в задание и необходимости указывать модули вручную, система сборки OE поддерживает функции динамической упаковки модулей, для чего нужно:

  • обеспечить действительную сборку модулей;
  • обеспечить выполнение заданием всех зависимостей модулей от других заданий.
3.22.3.1. Обеспечение сборки модулей

Обеспечить реальное создание пакетов с модулями можно с помощью функции do_split_packages внутри функции Python populate_packages в задании. Функция отыскивает шаблоны файлов и каталогов по указанному пути и создает пакет для найденного, добавляя его в переменную PACKAGES и устанавливая нужные значения FILES_packagename, RDEPENDS_packagename, DESCRIPTION_packagename и т. д. Например, для задания lighttpd

     python populate_packages_prepend () {
         lighttpd_libdir = d.expand('${libdir}')
         do_split_packages(d, lighttpd_libdir, '^mod_(.*)\.so$',
  'lighttpd-module-%s', 'Lighttpd module for %s',
   extra_depends='')
     }

В примере заданно множество параметров при вызове do_split_packages:

  • каталог в котором do_install ищет файлы, устанавливаемые заданием;
  • регулярное выражение для сопоставления с файлами модулей в каталоге поиска; в примере следует обратить внимание на () для указания части выражения, из которой выводится имя модуля;
  • шаблон для имен пакетов;
  • описание каждого пакета;
  • пустая строка для extra_depends отключает заданные по умолчанию зависимости основного пакета lighttpd, поэтому при нахождении файла в ${libdir} с именем mod_alias.so создается пакет для него, а в переменной DESCRIPTION устанавливается значение «Lighttpd module for alias».

Для более сложных случаев имеются другие опции do_split_packages. При необходимости можно расширить логику путем задания функции-ловушки, вызываемой для каждого пакета. Можно вызывать do_split_packages несколько раз если для пакета имеется не один набор модулей. Примеры использования do_split_packages приведены в файле connman.inc file каталога meta/recipes-connectivity/connman/ в репозитории poky, а также в meta/classes/kernel.bbclass.

Ниже перечислены обязательные и дополнительные аргументы do_split_packages.

Обязательные аргументы

root

Путь поиска.

file_regex

Регулярное выражения для сопоставления файлов. Скобки () служат для маркировки части выражения, которую следует применять для вывода имени модуля (для подстановки вместо %s в других аргументах).

output_pattern

Шаблон для имен пакетов (должен включать %s).

description

Описание для каждого пакета (должно включать %s).

Дополнительные аргументы

postinst

Сценарий пост-установки для всех пакетов (как строка).

recursive

True для рекурсивного поиска (принято по умолчанию).

hook

Функция ловушка, вызываемая для каждого совпадения с перечисленными ниже аргументами в заданном порядке:

f

полный путь к файлу или каталогу для сопоставления;

pkg

имя пакета;

file_regex

см. выше;

output_pattern

см. выше;

modulename

Имя модуля, полученное с использованием file_regex.

extra_depends

Дополнительные зависимости при работе (RDEPENDS), устанавливаемые для всех пакетов. Принятое по умолчанию значение None задает зависимость от основного пакета (${PN}). Если такая зависимость не нужна, следует указать пустую строку в этом параметре.

aux_files_pattern

Элементы, добавляемые в FILES для каждого пакета (одна строка или список строк для нескольких пакетов с обязательным включением %s).

postrm

Сценарий postrm для использования со всеми пакетами (как строка).

allow_dirs

True для сопоставления с каталогами (по умолчанию False).

prepend

True задает добавление пакетов в начало PACKAGES, False (принято по умолчанию) — в конец.

match_path

Сопоставление file_regex со всем относительным путем к корню, а не только с именем файла.

aux_files_pattern_verbatim

Элементы, добавляемые в FILES для каждого пакета с выведенными именами модулей вместо преобразования в пригодные для имени пакета (строка или список строк для нескольких пакетов с обязательным включением %s).

allow_links

True разрешает сопоставление символьных ссылок (по умолчанию False).

summary

Резюме для каждого пакета (должно включать %s), значения по умолчанию не задано.

3.22.3.2. Выполнение зависимостей

Второй частью обработки пакетов с необязательными модулями является выполнение зависимостей этих модулей от других заданий. Это можно обеспечить с помощью переменной PACKAGES_DYNAMIC. Например, для упомянутого выше задания lighttpd это будет иметь вид PACKAGES_DYNAMIC = «lighttpd-module-.*».

Имя в регулярном выражении может быть любым. В примере задано имя lighttpd-module-, которое будет префиксом во всех RDEPENDS и RRECOMMENDS для пакетов, имена которых начинаются с этого префикса. При использовании do_split_packages в соответствии с предыдущим параграфом значение, помещаемое в PACKAGES_DYNAMIC, должно соответствовать шаблону имени при вызове do_split_packages.

3.22.4. Управление пакетами в процессе работы

При сборке BitBake преобразует задание в один или несколько пакетов. Например, BitBake принимает задание bash и создает пакеты bash, bash-bashbug, bash-completion, bash-completion-dbg, bash-completion-dev, bash-completion-extra, bash-dbg и т. п. В образ включаются не все созданные пакеты.

В некоторых случаях может потребоваться обновление, добавление, удаление или запрос пакета не целевом устройстве при работе (т. е. без создания нового образа). Например,

  • нужно обеспечить обновление развернутых устройств в «полевых» условиях (например, безопасность);
  • нужен быстрый цикл разработки одного или нескольких приложений на целевом устройстве;
  • нужно временно установить отладочные пакеты разных приложений для ускорения отладки;
  • нужно развернуть на устройстве минимальный выбор пакетов с возможностью расширения в «поле».

Все эти случаи похожи на обычные дистрибутивы Linux, где устройства могут получать собранные пакеты с сервера инсталляции или обновления. Возможность установки пакетов в полевых условиях называют управлениям пакетами в процессе работы. Для такого управления потребуется машина, которая будет обеспечивать собранные пакеты и требуемые метаданные, а также инструменты для управления пакетами. В качестве сервера обновления проще всего применять сборочный хост, однако он может не быть сервером пакетов. Хост сборки может передавать результаты на другой сервер (например, доступный через Internet). Это удобно для рабочей среды, поскольку получение пакетов из среды сборки может сталкиваться с проблемой их перезаписи.

Простая сборка для единственного устройства создает не одну базу данных о пакетах, т. е. созданные при сборке пакеты разделяются по нескольким группам на основе таких критериев, как архитектура CPU, целевая плата и применяемая там библиотека C. Например, сборка для устройства qemux86 создает 3 базы данных — noarch, i586, qemux86. Если нужно сообщить устройству qemux86 о всех доступных пакетах, потребуется отдельно указать каждую из этих баз, как это обычно делается в традиционных дистрибутивах Linux.

Управление пакетами при работе не является обязательным и не требуется для сборки и разработки. Однако для использования такого управления потребуется сделать некоторые дополнительные шаги, описанные ниже.

3.22.4.1. Вопросы сборки

При создании пакетов BitBake нужно знать об используемых форматах пакетов, которые указываются в переменной PACKAGE_CLASSES. Для этого в файле local.conf каталога сборки (например, ~/poky/build/conf/local.conf), указывается переменная вида PACKAGE_CLASSES ?= “package_packageformat”, где packageformat может включать значении ipk, rpm, deb и tar в соответствии с поддерживаемыми типами пакетов. Поскольку YP поддерживает четыре формата, в переменной можно указать несколько значений, однако система сборки OE будет применять лишь первый при создании образа или SDK.

Если нужно иметь базовые данные о пакетах в текущей сборке, а также иметь на платформе соответствующий инструмент управления пакетами при работе, можно включить значение package-management в переменную IMAGE_FEATURES. Однако делать это совсем не обязательно и можно создать образ без баз данных и добавить лишь инструменты для управления пакетами при работе. Например, можно включить opkg в переменную IMAGE_INSTALL, если планируется использовать пакеты IPK. Потом можно будет инициализировать базы данных на целевой системе.

Всякий раз, когда при сборке может быть создан новый пакет или изменен существующий, рекомендуется обновить индекс пакетов после сборки с помощью команды bitbake package-index. Можно возникнуть желание обновить индекс пакетов при сборке того или иного пакета с помощью bitbake some-package package-index, но лучше этого не делать, поскольку BitBake не планирует обновление индекса по завершении сборки пакета и не обеспечивается гарантии того, что собранный пакет будет включен в индекс. Лучше обновлять индекс отдельной командой после сборки пакетов.

Можно использовать переменные PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_URIS для настройки в целевом образе работы с хранилищем пакетов. Если этого не сделать, потребуется выполнить инициализацию работы с хранилищем непосредственно на платформе, как описано ниже. Переменные для их корректной работы нужно устанавливать до сборки образа.

По завершении сборки пакеты размещаются в каталоге ${TMPDIR}/deploy/packageformat. Например, при ${TMPDIR} = tmp и выборе формата RPM пакеты RPM будут доступны в каталоге tmp/deploy/rpm.

3.22.4.2. Организация сервера

Обычно для работы с пакетами применяют сервер HTTP, который может работать на основе Apache 2, lighttpd, SimpleHTTPServer и т. п. Для простоты здесь описана организация сервера на основе SimpleHTTPServer, хотя это и не является лучшим решением для производственной среды.

Сервер можно запустить из каталога сборки, где хранятся файлы выбранного варианта пакетов (PACKAGE_CLASSES). Ниже приведен пример с каталогом ~/poky/build/tmp/deploy/rpm, где PACKAGE_CLASSES имеет значение package_rpm.

     $ cd ~/poky/build/tmp/deploy/rpm
     $ python -m SimpleHTTPServer
3.22.4.3. Установка цели

Настройка целевой платформы зависит от выбранного менеджера пакетов. Здесь даны сведения для RPM, IPK и DEB.

3.22.4.3.1. Использование RPM

Пакет Dandified Packaging Tool (DNF) обеспечивает управление пакетами RPM в процессе работы. Для этого требуется выполнить начальную установку, если переменные PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_URIS не были установлены до сборки целевого образа.

На целевой платформе нужно уведомить DNF о доступности баз данных о пакетах путем создания файла /etc/yum.repos.d/oe-packages.repo и указания пакетов. Предположим в качестве примера возможность использования на устройстве пакетов i586 и qemux86 с сервера my.server. Важно, чтобы идентификаторы URI в конфигурации репозиториев на платформе корректно указывали удаленные хранилища. Для разработки можно использовать машину сборки, но в рабочей среде лучше вынести пакеты за пределы области сборки и указать их местоположение. Это предотвратит ситуации переписывания системой сборки пакетов в репозитории.

При указании DNF местоположения баз данных о пакетах нужно отдельно указать место для каждой архитектуры или общее место для всех пакетов. Совмещение приведенных ниже вариантов недопустимо.

  • Создание явного списка архитектур путем определения базовых URL для местоположения пакетов:
    [oe-packages]
    baseurl=http://my.server/rpm/i586 http://my.server/rpm/qemux86 http://my.server/rpm/all

    Это указывает DNF базы данных для пакетов трех вариантов архитектуры.

  • Создание одного (полного) индекса пакетов с одним URL для базы данных обо всех пакетах.
         [oe-packages]
         baseurl=http://my.server/rpm

    Это указывает DNF единую базу данных, содержащую информацию о пакетах для каждой архитектуры.

После указания базы данных можно собрать информацию о пакетах с помощью команды

     # dnf makecache

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

3.22.4.3.2. Использование IPK

Приложение opkg выполняет управление пакетами IPK при работе системы. Для этого требуется выполнить начальную установку, если переменные PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_URIS не были установлены до сборки целевого образа. Программа opkg использует файлы конфигурации для поиска доступных баз данных о пакетах, поэтому нужно создать эти файлы в каталоге /etc/opkg/ для указания репозиториев.

Предположим, например, что обслуживаются пакеты из каталога ipk/, содержащего базы данных для архитектуры i586, all и qemux86, через сервер HTTPmy.server. На целевой платформе файл конфигурации (например, my_repo.conf) в каталоге /etc/opkg/ будет иметь вид

     src/gz all http://my.server/ipk/all
     src/gz i586 http://my.server/ipk/i586
     src/gz qemux86 http://my.server/ipk/qemux86

После этого выполняется команда извлечения данных из репозитория

     # opkg update

Получив информацию, opkg может находить, устанавливать и обновлять пакеты из репозиториев.

3.22.4.3.3. Использование DEB

Приложение apt выполняет управление пакетами DEB при работе системы. Для этого требуется выполнить начальную установку, если переменные PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_URIS не были установлены до сборки целевого образа.

Для информирования apt о репозитории можно создать файл со списком (например, my_repo.list) в каталоге /etc/apt/sources.list.d/. Например, для обслуживания пакетов из каталога deb/ с базами данных для i586, all, qemux86 с помощью сервера HTTP my.server в список следует включить приведенные ниже строки.

     deb http://my.server/deb/all ./
     deb http://my.server/deb/i586 ./
     deb http://my.server/deb/qemux86 ./

После этого выполняется команда извлечения данных из репозитория

     # apt-get update

Получив информацию, apt может находить, устанавливать и обновлять пакеты из репозиториев.

3.22.5. Создание и использование подписанных пакетов

Для улучшения защиты пакетов RPM можно использовать подписи. После проверки подписи система сборки OE может использовать пакет, но если подпись не соответствует, сборка будет прервана.

3.22.5.1. Подписывание пакетов RPM

Для подписывания пакетов RPM нужно добавить в файл local.conf или distro.conf приведенные ниже строки.

# Inherit sign_rpm.bbclass to enable signing functionality
     INHERIT += " sign_rpm"
     # Define the GPG key that will be used for signing.
     RPM_GPG_NAME = "key_name" # Provide passphrase for the key RPM_GPG_PASSPHRASE = "passphrase"

Вместо key_name и passphrase следует указать действительное имя ключа и пароль. Кроме указанных переменных RPM_GPG_NAME и RPM_GPG_PASSPHRASE с подписями связаны две необязательных переменных:

  • GPG_BIN задает двоичный файл gpg, выполняемый при подписывании пакета;
  • GPG_PATH указывает домашний каталог gpg, используемый при подписывании пакета.
3.22.5.2. Подписывание хранилища пакетов

Можно организовать подписанные хранилища для пакетов IPK и RPM. Для этого нужно включить в local.conf или distro.conf приведенные ниже строки.

INHERIT += "sign_package_feed"
     PACKAGE_FEED_GPG_NAME = "key_name" PACKAGE_FEED_GPG_PASSPHRASE_FILE = "path_to_file_containing_passphrase"

Для хранилища подписанных пакетов парольная фраза должна храниться в отдельном файле, указанном переменной PACKAGE_FEED_GPG_PASSPHRASE_FILE. Вынос пароля за пределы конфигурации улучшает защиту.

Кроме переменных PACKAGE_FEED_GPG_NAME и PACKAGE_FEED_GPG_PASSPHRASE_FILE есть три необязательных переменных, относящихся к подписыванию пакетов:

  • GPG_BIN задает двоичный файл gpg, выполняемый при подписывании пакета;
  • GPG_PATH указывает домашний каталог gpg, используемый при подписывании пакета;
  • PACKAGE_FEED_GPG_SIGNATURE_TYPE задает тип подписи gpg. Переменная применима лишь к хранилищам пакетов RPM и IPK, а возможные значения включают ASC (принято по умолчанию) и BIN.

3.22.6. Тестирование пакетов с помощью ptest

Проверка пакетов (ptest) работает с пакетами, созданными системой сборки OE, на целевой платформе и содержит по меньшей мере два элемента — реальный тест и shell-сценарий (run-ptest) для запуска теста. Включение теста в сценарий запуска не разрешается. Сам тест может быть любым — от shell-сценария, запускающего двоичный файл и проверяющего результат, до сложной системы двоичных файлов для тестирования и файлов данных.

Вывод таста имеет формат, применяемый Automake, — result: testname, где result может принимать значение PASS, FAIL или SKIP, а testname может быть строкой идентификации. Список заданий YP, для которых уже включен ptest, приведен на странице Ptest. Такие задания наследуют класс ptest.

3.22.6.1. Добавление ptest в сборку

Для добавления тестирования пакетов в сборку нужно задать DISTRO_FEATURES и EXTRA_IMAGE_FEATURES в файле local.conf в каталоге сборки, как показано ниже.

     DISTRO_FEATURES_append = " ptest"
     EXTRA_IMAGE_FEATURES += "ptest-pkgs"

По завершении сборки файлы ptest размещаются в каталоге /usr/lib/package/ptest внутри образа (packageимя пакета).

3.22.6.2. Запуск ptest

Пакет ptest-runner устанавливает сценарий, который выполняет все установленные наборы тестов ptest в заданном порядке. Имеет смысл включать этот пакет в образ.

3.22.6.3. Подготовка пакета

Чтобы включить тесты ptest на целевом оборудовании, нужно подготовить задания к сборке.

  • Наследование класса ptest требует включения в задание строки inherit ptest.
  • Создание сценария run-ptest для запуска теста. Сценарий указывается в переменной SRC_URI. Например, для запуска теста dbus сценарий может иметь вид
         #!/bin/sh
         cd test
         make -k runtest-TESTS    
  • Контроль соблюдения зависимостей. Если тест добавляет зависимости при сборке или работе, которых обычно нет для пакета (например, запуск make при тестировании), нужно использовать переменные DEPENDS и RDEPENDS в задании для указания зависимостей. Например зависимость от make при работе задается строкой RDEPENDS_${PN}-ptest += «make».
  • Добавление функции для сборки теста. Не все пакеты поддерживают кросс-компиляцию своих тестов и может потребоваться добавление функции кросс-компиляции в пакет. Многие пакеты на основе Automake компилируют и запускают свои тесты с использованием одной команды, такой как make check. Однако на хосте сборки эта команда создаст и запустит тесты локально, тогда как кросс-компиляция требует сборки пакета на хосте и запуска на целевой системе. Версия Automake из состава YP включает исправления, разделяющие сборку и выполнение. Поэтому для пакетов кросс-компиляция make check выполняется автоматически. Тем не менее, все равно нужно добавить функцию do_compile_ptest для сборки теста в задание.
         do_compile_ptest() {
            oe_runmake buildtest-TESTS
         }    
  • Установка нужной конфигурации (если она нужна для компиляции тестового кода) с помощью функции do_configure_ptest в задании.
  • Установка тестов. Класс ptest автоматически копирует run-ptest в целевую систему, а затем запускает make install-ptest для инициирования тестов. Если этого не достаточно, нужно создать функцию do_install_ptest и обеспечить ее вызов по завершении make install-ptest.

3.22.7. Создание пакетов NPM

NPM является менеджером пакетов для JavaScript. YP поддерживает сборщик NPM (fetcher), который можно применять с devtool для подготовки заданий, создающих пакеты NPM. Имеется два метода создания пакетов NPM с помощью devtool — реестр модулей NPM и код проекта NPM. Можно создавать задания NPM вручную, но с devtool это проще.

3.22.7.1. Требования и предостережения

Перед использованием devtool для создания пакетов NPM нужно выполнить указанные ниже действия.

  • Можно использовать один из двух методов создания пакетов NPM и подход с реестром несколько проще. Однако можно рассмотреть и вариант с проектом поскольку модель может не публиковаться в общедоступном реестре NPM (npm-registry).
  • Следует ознакомиться с devtool.
  • На хосте сборки нужен пакет nodejs-npm, являющийся частью среды OE, который можно получить клонированием репозитория https://github.com/openembedded/meta-openembedded. Путь к локальной копии нужно указать в файле bblayers.conf.
  • devtool не может обнаруживать естественные библиотеки в зависимостях модуля, поэтому нужно вручную добавлять пакеты в задание.
  • При развертывании пакетов NPM devtool не может определить отсутствие нужного пакета на целевой платформе (например, nodejs), поэтому нужно проверять самостоятельно.
  • Хотя NPM может не требоваться для пакета, лучше иметь NPM (nodejs-npm) на целевой платформе.
3.22.7.2. Реестр модулей NPM

Здесь рассматривается пример модуля cute-files, который является программой web-браузера. Нужно знать версию модуля. Первым делом нужно использовать devtool и сборщик NPM для подготовки задания

     $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"

Команда devtool add запускает recipetool create и использует тот же URI выборки для загрузки каждой зависимости и деталей лицензирования, когда это возможно. Файл задания достаточно прост и содержит все лицензии, найденные recipetool, а также лицензии из переменных LIC_FILES_CHKSUM. Нужно проверить переменные на предмет значений unknown в поле LICENSE и добавить соответствующую информацию вручную.

Команда recipetool файлы shrinkwrap и lockdown для задания. Файлы shrinkwrap включают версии всех зависимых модулей, но многие пакеты не включают файлов shrinkwrap и recipetool создает их. Можно заменить файл shrinkwrap своим файлом, задав переменную NPM_SHRINKWRAP. Файлы lockdown содержат контрольные суммы каждого модуля, чтобы определить загрузку тех же файлов при сборке задания. Файлы lockdown обеспечивают сохранение зависимостей и сохранение в реестре NPM того же файла.

Пакет создается для каждого субмодуля. Это правило обеспечивает единственный практичный способ получения лицензий для всех зависимостей, представленных в манифесте лицензий образа. Команда devtool edit-recipe позволяет просматривать задание.

$ devtool edit-recipe cute-files
SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
LICENSE = "BSD-3-Clause & Unknown & MIT & ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
 file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \
 file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \
 ...

SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}"
NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
inherit npm
# Must be set after inherit npm since that itself sets S
S = "${WORKDIR}/npmpkg"

LICENSE_${PN}-content-disposition = "MIT"
...
LICENSE_${PN}-express = "MIT"
LICENSE_${PN} = "MIT"

В примере следует отметить 3 важных аспекта:

  • SRC_URI применяет схему NPM, поэтому используется сборщик NPM;
  • recipetool собирает данные о всех лицензиях и при отсутствии лицензии для субмодуля перед его именем помещается символ комментария;
  • оператор inherit npm заставляет класс npm упаковывать все модули.

Для сборки пакета cute-files можно воспользоваться командой devtool build cute-files. Следует помнить, что nodejs нужно установить на целевой платформе до пакета. Предположим, что целевая система имеет адрес 192.168.7.2 и введем команду devtool deploy-target -s cute-files root@192.168.7.2 для установки пакета, после чего можно будет протестировать приложение.

Известные проблемы не позволяют просто запустить cute-files как при запуске npm install.

     $ cd /usr/lib/node_modules/cute-files
     $ node cute-files.js

Если в браузере ввести http://192.168.7.2:3000, будет показана приведенная на рисунке страница.


Задание можно найти в каталоге workspace/recipes/cute-files и использовать на любом уровне.

3.22.7.3. Код проекта NPM

Хотя полезно упаковывать модули уже в реестре NPM, добавление проектов node.js более распространено. Этот метод очень похож на использование реестра и команде devtool предоставляется URL исходных файлов. Используя прошлый пример с cute-files, вводим команду devtool add https://github.com/martinaglv/cute-files.git. Эта команда создает задание, очень похожее на задание из предыдущего параграфа, однако переменная SRC_URI имеет вид

     SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \
   npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \
   npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \
   npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \
   "

Здесь основной модуль берется из репозитория Git, а зависимости — из реестра NPM. В остальном задания совпадают Можно собрать и развернуть пакет в соответствии с предыдущим параграфом.

3.23. Эффективная выборка файлов при сборке

Система сборки OE работает с файлами исходного кода, указанными переменной SRC_URI. При сборке с использованием BitBake значительную часть работы составляет нахождение и загрузка всех архивов источников. Для образов это может занимать много времени. В этом разделе описано использование зеркал для ускорения выборки исходных файлов, а также предварительная выборка файлов.

3.23.1. Установка эффективных зеркал

В сборке YP можно просто загрузить все архивы исходного кода. При наличии исходных кодов из других систем сборки можно обеспечить существенную экономию времени, добавив каталоги с этим кодом в переменные системы сборки. Ниже приведен вариант указания таких файлов в конфигурационном файле local.conf.

     SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
     INHERIT += "own-mirrors"
     BB_GENERATE_MIRROR_TARBALLS = "1"
     # BB_NO_NETWORK = "1"    

Здесь переменная BB_GENERATE_MIRROR_TARBALLS заставляет систему сборки OE создавать файлы репозиториев Git и сохранять их в каталоге DL_DIR. Из соображений производительности такое поведение системы сборки не задано по умолчанию. Можно также использовать переменную PREMIRRORS [3].

3.23.2. Подготовка исходных файлов без сборки

Другим вариантом является предварительная выборка исходных кодов без запуска сборки. Это позволяет избежать проблем с загрузкой и собрать весь исходный код в каталоге build/downloads внутри DL_DIR. Сделать это можно с помощью команды bitbake -c target runall=»fetch». Этот вариант гарантирует наличие всех исходных кодов и возможность сборки даже без доступа в Internet.

3.24. Выбор менеджера инициализации

По умолчанию YP использует менеджер инициализации SysVinit, однако поддерживается и менеджер systemd, который является полной заменой init с параллельным запуском служб, сниженной загрузкой оболочки и другими функциями. Для использования SysVinit ничего делать не нужно, но для systemd потребуются некоторые шаги, описанные ниже.

3.24.1. Использование только systemd

В файле конфигурации дистрибутива следует указать

     DISTRO_FEATURES_append = " systemd"
     VIRTUAL-RUNTIME_init_manager = "systemd"    

В первой строке могут присутствовать и другие свойства. Можно также отключить SysVinit с помощью DISTRO_FEATURES_BACKFILL_CONSIDERED += «sysvinit». В результате этого будут удалены ненужные сценарии SysVinit. Для полного удаления сценариев инициализации следует указать VIRTUAL-RUNTIME_initscripts = «».

3.24.2. Systemd для основного образа и SysVinit для восстановления

В этом случае следует включить в файл конфигурации дистрибутива приведенные ниже переменные.

     DISTRO_FEATURES_append = " systemd"
     VIRTUAL-RUNTIME_init_manager = "systemd"    

В этом случае основной образ будет использовать задание packagegroup-core-boot.bb и systemd, а восстановительный (минимальный) не будет применять указанную группу пакетов. Однако можно установить SysVinit и пакеты, поддерживающие systemd и SysVinit.

3.25. Выбор менеджера устройств

YP обеспечивает несколько способов управления менеджером устройств (/dev).

  • Постоянный и заранее заполненный каталог /dev. В этом случае каталог /dev существует всегда и требуется создание узлов для устройств в процесс сборки.
  • Использование devtmpfs с менеджером устройств. В этом случае каталог /dev обеспечивается ядром как файловая система в памяти и автоматически заполняется ядром при работе. Дополнительная настройка узлов для устройств выполняется в пользовательском пространстве менеджером устройств, таким как udev или busybox-mdev.

3.25.1. Использование постоянного заполненного каталога /dev

Для использования статического метода заполнения устройств нужно задать USE_DEVFS = «0». Содержимое получаемого каталога /dev определяется файлом с таблицей устройств. Переменная IMAGE_DEVICE_TABLES задает используемую таблицу и должна быть установлена в файле конфигурации машины или дистрибутива, но можно задать ее и в файле local.conf. По умолчанию применяется IMAGE_DEVICE_TABLES = «device_table-mymachine.txt». Заполнение каталога обеспечивается утилитой makedevs в процессе сборки образа.

3.25.2. Использование devtmpfs и менеджера устройств

Для динамического заполнения устройств нужно использовать USE_DEVFS = «1». При установленной переменной каталог /dev заполняется ядром с помощью devtmpfs, для чего в конфигурации ядра должна быть установлена переменная CONFIG_DEVTMPFS. Созданные devtmpfs устройства принадлежат пользователю root и имеют права доступа 0600.

Для управления узлами устройств можно использовать такие менеджеры устройств, как udev или busybox-mdev. Выбор менеджера задается переменной VIRTUAL-RUNTIME_dev_manager в файле конфигурации машины или дистрибутива или в файле local.conf, как показано ниже.

     VIRTUAL-RUNTIME_dev_manager = "udev"

     # Some alternative values
     # VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
     # VIRTUAL-RUNTIME_dev_manager = "systemd"    

3.26. Использование внешних SCM

При работе с заданием из внешней системы SCM система сборки OE может уведомлять об изменении заданий в SCM и соберет в результате пакеты, зависящие от новых заданий, используя последнюю версию. Это работает лишь с SCM, где можно получить номер выпуска для изменений. В настоящее время это возможно для репозиториев Apache Subversion (SVN), Git и Bazaar (BZR). Для включения такого режима следует указать в переменной задания PV значение SRCPV, например, PV = «1.2.3+git${SRCPV}», а в файл local.conf нужно добавить строку SRCREV_pn-PN = «${AUTOREV}». PNэто имя задания, для которого нужно включить автоматическое обновление исходного кода. Можно не менять файл local.conf, а добавить в задание строку SRCREV = «${AUTOREV}».

YP включает дистрибутив poky-bleeding с файлом конфигурации, содержащим строку

     require conf/distro/include/poky-floating-revisions.inc

Эта строка добавляет включаемый файл с множеством строк вида

     #SRCREV_pn-opkg-native ?= "${AUTOREV}"
     #SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
     #SRCREV_pn-opkg ?= "${AUTOREV}"
     #SRCREV_pn-opkg-utils-native ?= "${AUTOREV}"
     #SRCREV_pn-opkg-utils ?= "${AUTOREV}"
     SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
     SRCREV_pn-matchbox-common ?= "${AUTOREV}"
     SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
     SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
     SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
     SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
     SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
     SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
     SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
     SRCREV_pn-settings-daemon ?= "${AUTOREV}"
     SRCREV_pn-screenshot ?= "${AUTOREV}"
          ...

Это позволяет создать дистрибутив с отслеживанием обновления исходного кода для многих пакетов. Однако дистрибутив poky-bleeding не тестируется как другие дистрибутивы и применять его следует с осторожностью.

3.27. Создание корневой файловой системы лишь для чтения

Из соображений безопасности может потребоваться запрет операций записи в корневой файловой системе целевого устройства. Возможны также устройства хранения, не поддерживающие запись. В таких случаях нужно обеспечить соответствующее поведение образа. Для поддержки файловых систем без возможности записи требуется предотвращение попыток записи операционной системы и приложений в корневую файловую систему. Для этого нужно настроить все компоненты целевой системы на запись в другое место или аккуратно предотвращать попытки записи в корневую файловую систему.

3.27.1. Создание корневой файловой системы

Для создания файловой системы без возможности записи к образу просто добавляется свойство read-only-rootfs. Для этого можно указать в задании для образа или в файле local.conf каталога сборки строку IMAGE_FEATURES = «read-only-rootfs» или EXTRA_IMAGE_FEATURES += «read-only-rootfs». Дополнительная информация об использовании этих переменных дана в параграфе 3.2.2. Настройка с помощью IMAGE_FEATURES и EXTRA_IMAGE_FEATURES и описаниях переменных IMAGE_FEATURES и EXTRA_IMAGE_FEATURES.

3.27.2. Сценарии пост-установки

Важно обеспечить выполнение сценариев пост-установки (pkg_postinst) для пакетов, включенных в образ, при создании корневой файловой системы при сборке на хосте, поскольку эти сценарии не смогут работать при первой загрузке на целевой системе. При включенном свойстве read-only-rootfs система сборки проверяет в процессе создания файловой системы выполнение всех сценариев пост-утсановки. Если какой-то из этих сценариев требует запуска после создания файловой системы, сборка завершается отказом. Проверка во время сборки гарантирует отказ сборки, а не первой загрузки на целевой системе.

Большинство сценариев пост-установки, создаваемых системой сборки из состава YP, созданы с возможностью выполнения в процессе создания файловой системы (например, сценарий пост-установки для кэширования шрифтов). Однако при создании своих сценариев нужно обеспечить возможность их работы при создании файловой системы.

Ниже указаны некоторые общие проблемы, возникающие при работе сценариев пост-установки.

  • Не используется $D в начале абсолютного пути. Система сборки определяет $D при создании корневой файловой системы, а при запуске на целевом устройстве значение $D пусто. Это предполагает двойное назначение $D — обеспечения корректности путей на хосте сборки и в целевой системе, а также определение используемой среды для выполнения соответствующих действий.
  • Попытка запуска процессов, относящихся к целевой архитектуре или зависимых от нее. Это можно обойти путем использования естественных инструментов, работающих на хосте сборки для решения тех же задач, или запуска процессов в QEMU с функцией qemu_run_binary.

3.27.3. Области с доступом для записи

При включенном свойстве read-only-rootfs любая попытка записи в корневую файловую систему будет давать отказ. Поэтому нужно обеспечить запись процессов и приложений в иную область, например, /tmp или /var/run.

3.28. Поддержка качества вывода сборки

На качество сборки может влиять много факторов. Например, обновление версии задания из восходящего источника или эксперимент с опциями конфигурации могут привести к незаметным изменениям, которые проявятся позже. В случае задания, использующего обновленную версию программы это может вносить необязательную зависимость от другой библиотеки, нежели была определена автоматически. Если такая библиотека уже собрана, программа будет связана с ней и библиотека будет добавлена в образ вместе с новой программой, даже если вы не хотите ее использовать.

Класс buildhistory помогает поддерживать качество вывода сборки и его можно использовать для выявления неожиданных и возможно нежелательных изменений в выводе. При включении истории сборки записываются данные о содержимом каждого пакета и образа, а затем информация фиксируется в локальном репозитории Git, где можно ее проверить.

3.28.1. Управление историей сборки

История сборки выключена по умолчанию и для включения нужно добавить оператор INHERIT и установить переменную BUILDHISTORY_COMMIT в конце файла conf/local.conf в каталоге сборки.

     INHERIT += "buildhistory"
     BUILDHISTORY_COMMIT = "1"    

Включение истории сборки заставляет систему сборки OE собирать выходную информацию и представлять ее в форме одной фиксации (commit) в локальный репозиторий Git. Включение истории сборки несколько увеличивает время сборки и занимаемое на диске пространство.

3.28.2. Содержимое истории сборки

История сборки хранится в каталоге ${TOPDIR}/buildhistory внутри каталога сборки, как определено в переменной BUILDHISTORY_DIR. На рисунке представлена сокращенная структура истории сборки.


На верхнем уровне размещается файл metadata-revs со списком выпусков репозиториев для включенных при сборке уровней. Остальные данные поделены на отдельные каталоги для пакетов, образов и sdk, как описано ниже.

3.28.2.1. История сборки пакета

История сборки для каждого пакета включает текстовый файл с парами «имя-значение». Например, файл buildhistory/packages/i586-poky-linux/busybox/busybox/latest содержит приведенные ниже данные.

     PV = 1.22.1
     PR = r32
     RPROVIDES =
     RDEPENDS = glibc (>= 2.20) update-alternatives-opkg
     RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d
     PKGSIZE = 540168
     FILES = /usr/bin/* /usr/sbin/* /usr/lib/busybox/* /usr/lib/lib*.so.* \
        /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/udev/rules.d \
        /usr/lib/udev/rules.d /usr/share/busybox /usr/lib/busybox/* \
        /usr/share/pixmaps /usr/share/applications /usr/share/idl \
        /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
     FILELIST = /bin/busybox /bin/busybox.nosuid /bin/busybox.suid /bin/sh \
        /etc/busybox.links.nosuid /etc/busybox.links.suid

Большинство пар соответствует переменным, использованным для создания пакета. Исключением является переменная FILELIST со списком реальных файлов из пакета и PKGSIZE с общим размером файлов пакета в байтах.

Имеется также файл, соответствующий заданию, из которого получен пакет (например, buildhistory/packages/i586-poky-linux/busybox/latest).

     PV = 1.22.1
     PR = r32
     DEPENDS = initscripts kern-tools-native update-rc.d-native \
        virtual/i586-poky-linux-compilerlibs virtual/i586-poky-linux-gcc \
        virtual/libc virtual/update-alternatives
     PACKAGES = busybox-ptest busybox-httpd busybox-udhcpd busybox-udhcpc \
        busybox-syslog busybox-mdev busybox-hwclock busybox-dbg \
        busybox-staticdev busybox-dev busybox-doc busybox-locale busybox

Для заданий, извлеченных из систем контроля версий (например, Git), имеется файл со списком выпусков исходного кода, указанных в задании, и списком реальных выпусков, использованных для сборки. Эти списки могут различаться при установке SRCREV = ${AUTOREV}. Ниже приведен пример из файла buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev.

     # SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
     SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
     # SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
     SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"

Можно использовать команду buildhistory-collect-srcrevs с опцией -a для получения сохраненных значений SRCREV из истории сборки в формате, пригодном для использования в глобальной конфигурации (например, local.conf или включаемый файл дистрибутива) с целью переопределения значений AUTOREV фиксированным набором выпусков. Пример вывода представлен ниже.

     $ buildhistory-collect-srcrevs -a
     # i586-poky-linux
     SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
     SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
     SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
     SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
     # x86_64-linux
     SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
     SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
     SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
     SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
     SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
     SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
     SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
     SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
     SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
     # qemux86-poky-linux
     SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
     SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
     # all-poky-linux
     SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"

Ниже приведены некоторые замечания по использованию команды buildhistory-collect-srcrevs.

  • По умолчанию выводятся только значения, где SRCREV не задана жестко (обычно при использовании AUTOREV). Опция -a задает вывод всех значений SRCREV.
  • Выходные операторы могут не давать эффекта, если где-то в конфигурации системы сборки применены переопределения. Опция -f добавляет форсированные переопределения в каждую строку, если нужно обойти это ограничение.
  • Сценарий не использует особой обработки при сборке для нескольких машин, однако помещает символ комментария перед каждым набором значений, задающим триплет, который уже был показан (например, i586-poky-linux).
3.28.2.2. История сборки образа

Для каждого образа создается набор описанных ниже файлов.

  • image-filesкаталог с выбранными файлами из корневой системы (заданы в BUILDHISTORY_IMAGE_FILES).
  • build-id.txtпонятные человеку сведения о конфигурации сборки и метаданные выпусков исходного кода, а также полный заголовок сборки, выводимый BitBake.
  • *.dotграфы зависимостей для образа, совместимые с graphviz.
  • files-in-image.txtсписок файлов в образе с правами доступа, владельцами, группами, размером и символьными ссылками.
  • image-info.txtтекстовый файл с информацией об образе в виде пар «имя-значение».
  • installed-package-names.txtсписок имен установленных пакетов.
  • installed-package-sizes.txtсписок имен установленных пакетов, упорядоченный по размерам.
  • installed-packages.txtсписок имен установленных пакетов с полными именами.

Информация об установленных пакетах может собираться даже при запрете включения менеджера пакетов в финальный образ. Ниже приведен пример файла image-info.txt.

     DISTRO = poky
     DISTRO_VERSION = 1.7
     USER_CLASSES = buildstats image-mklibs image-prelink
     IMAGE_CLASSES = image_types
     IMAGE_FEATURES = debug-tweaks
     IMAGE_LINGUAS =
     IMAGE_INSTALL = packagegroup-core-boot run-postinsts
     BAD_RECOMMENDATIONS =
     NO_RECOMMENDATIONS =
     PACKAGE_EXCLUDE =
     ROOTFS_POSTPROCESS_COMMAND = write_package_manifest; license_create_manifest; \
        write_image_manifest ; buildhistory_list_installed_image ; \
        buildhistory_get_image_installed ; ssh_allow_empty_password;  \
        postinst_enable_logging; rootfs_update_timestamp ; ssh_disable_dns_lookup ;
     IMAGE_POSTPROCESS_COMMAND =   buildhistory_get_imageinfo ;
     IMAGESIZE = 6900

Размеры файлов указываются в килобайтах (кроме общего размера IMAGESIZE), пары «имя-значение» являются переменными, которые могут влиять на содержимое образа. Эта информация полезна для определения причин изменений в пакетах или файлах.

3.28.2.3. Использование истории сборки для получения информации только об образе

История сборки создает информацию об образе включая графы зависимостей, что позволяет увидеть причины добавления компонент в образ. Если нужны лишь сводные данные для образа и не интересуют отдельные пакеты или данные SDK, можно включить запись лишь данных образа без истории, указав в файле conf/local.conf каталога сборки

     INHERIT += "buildhistory"
     BUILDHISTORY_COMMIT = "0"
     BUILDHISTORY_FEATURES = "image"
3.28.2.4. История сборки SDK

Похожая информация собирается в истории и для сборки SDK (например, bitbake -c populate_sdk imagename). Эта информация различается для стандартных и расширяемых SDK. Список файлов истории сборки приведен ниже.

  • files-in-sdk.txtсписок файлов в SDK с правами доступа, владельцами, группами, размером и символьными ссылками для хостовой и целевой части SDK.
  • sdk-info.txtтекстовый файл с информацией об SDK в виде пар «имя-значение».
  • sstate-task-sizes.txtтекстовый файл в виде пар «имя-значение» с данными о размерах групп задач (например, do_populate_sysroot), создаваемый только при сборке расширяемых SDK.
  • sstate-package-sizes.txtтекстовый файл в виде пар «имя-значение» с данными о пакетах с общим состоянием и размерах в SDK, создаваемый только при сборке расширяемых SDK.
  • sdk-filesкаталог с копиями файлов, указанных в BUILDHISTORY_SDK_FILES, если эти файлы имеются в выводе. По умолчанию BUILDHISTORY_SDK_FILES относится к расширяемым SDK, но его можно установить и для стандартных. Файлы conf/local.conf, conf/bblayers.conf, conf/auto.conf, conf/locked-sigs.inc и conf/devtool.conf копируются по умолчанию в этот каталог для расширяемых SDK.
  • В каталоги для хоста и цели включаются перечисленные ниже файлы частей SDK, работающих на хосте и цели. Большая часть этих файлов для расширяемого SDK будет пустой, поскольку расширяемые SDK не состоят из пакетов, как стандартные SDK.
    • depends.dot графы зависимостей для SDK, совместимые с graphviz.
    • installed-package-names.txtсписок имен установленных пакетов.
    • installed-package-sizes.txtсписок имен установленных пакетов, упорядоченный по размерам.
    • installed-packages.txtсписок имен установленных пакетов с полными именами.

Ниже представлен пример файла sdk-info.txt.

     DISTRO = poky
     DISTRO_VERSION = 1.3+snapshot-20130327
     SDK_NAME = poky-glibc-i686-arm
     SDK_VERSION = 1.3+snapshot
     SDKMACHINE =
     SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
     BAD_RECOMMENDATIONS =
     SDKSIZE = 352712

Размеры файлов указываются в килобайтах (кроме общего размера IMAGESIZE), пары «имя-значение» являются переменными, которые могут влиять на содержимое образа. Эта информация полезна для определения причин изменений в пакетах или файлах.

3.28.2.5. Просмотр данных истории сборки

Историю сборки можно посмотреть с помощью команды или через web-интерфейс. Для просмотра изменений (в предположении BUILDHISTORY_COMMIT = «1») можно использовать обычную команду Git, например, git log -p. Следует помнить, что этот метод показывает и несущественные изменений (например, размер пакета). Имеется команда buildhistory-diff, которая обращается к репозиторию Git и выводит существенные различия в удобной форме. Например,

     $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
     Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
        /etc/anotherpkg.conf was added
        /sbin/anotherpkg was added
        * (installed-package-names.txt):
        *   anotherpkg was added
     Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):
        anotherpkg was added
     packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
        * PR changed from "r0" to "r1"
        * PV changed from "0.1.10" to "0.1.12"
     packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
        * PR changed from "r0" to "r1"
        * PV changed from "0.1.10" to "0.1.12"


Для buildhistory-diff нужен пакет GitPython, который можно установить с помощью команды pip3 install GitPython —user или менеджера пакетов (пакет python3-git). Просмотр изменений истории через web-интерфейс описан в файле README (http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/). Пример вывода показан на рисунке.

3.29. Автоматизированное тестирование при работе

Система сборки OE обеспечивает автоматизированные тесты для образов, позволяющие проверить функциональность при работе. Тесты можно запустить в QEMU или на реальном оборудовании. Тесты написаны на языке Python с применениям модуля unittest и большинство из них запускают команды на целевой системе через SSH. Сведения о тестах и инфраструктуре QA в составе YP приведены в разделе Testing and Quality Assurance [3].

3.29.1. Включение тестов

Управление тестами различается для случаев QEMU и реального оборудования, как описано ниже.

3.29.1.1. Включение тестов при выполнении в QEMU

Для запуска тестов нужно выполнить перечисленные ниже операции.

  • Настройка для работы через сеть без sudo.
    • Добавить NOPASSWD для нужного пользователя в файл /etc/sudoers для всех команд или runqemu-ifup. Нужно указать полный путь, поскольку он может меняться для разных копий репозитория источников.
    • В некоторых дистрибутивах нужно также «закомментировать» строку Defaults requiretty в /etc/sudoers.
    • Вручную настроить интерфейс tap в системе.
    • Запустить от имени root сценарий scripts/runqemu-gen-tapdevs, который должен создать список устройств tap. Обычно эта опция выбирается для сред Autobuilder.
      • Обеспечить использование абсолютного пути при вызове сценария с sudo.
      • Для работы сценария нужно собрать задание qemu-helper-native командой bitbake qemu-helper-native.
  • Установка переменной DISPLAY для работы с X-сервером (например, vncserver для машин без монитора).
  • Настройка на межсетевом экране входящих соединений из сети 192.168.7.0/24. Некоторые тесты (например, DNF) запускают сервер HTTP на случайном порту с большим номером, используемый для работы с файлами на целевой системе. Модуль DNF обслуживает ${WORKDIR}/oe-rootfs-repo, поэтому он может запускать команды DNF, требующие, чтобы межсетевой экран хоста пропускал входящие соединения из сети 192.168.7.0/24, которая по умолчанию используется runqemu для устройств tap.
  • Проверка наличия на хосте нужных пакетов:
    • Ubuntu и Debian — sysstat и iproute2;
    • OpenSUSE — sysstat и iproute2;
    • Fedora — sysstat и iproute;
    • CentOS — sysstat и iproute.

После запуска тестов выполняются перечисленные ниже действия.

  1. Копия корневой файловой системы записывается в ${WORKDIR}/testimage.
  2. Образ загружается в QEMU с помощью стандартного сценария runqemu.
  3. По умолчанию используется время ожидания 500 секунд для завершения процесса загрузки и вывода приглашения на вход в систему. Время задает переменная TEST_QEMUBOOT_TIMEOUT в файле local.conf.
  4. После появления приглашения на вход в систему запускается тест. Полный журнал загрузки будет доступен в каталоге ${WORKDIR}/testimage/qemu_boot_log.
  5. Загружаются модули тестов в порядке, заданном переменной TEST_SUITES. Вывод команд, выполняемых через SSH доступен в файле ${WORKDIR}/testimgage/ssh_target_log.
  6. При отсутствии отказов тестирование выполняется до завершения с записью вывода в файл ${WORKDIR}/temp/log.do_testimage.
3.29.1.2. Включение тестов при работе на аппаратной платформе

Система сборки OE может выполнять тесты на реальном оборудовании, а для некоторых устройств можно развернуть образ для предварительного тестирования на устройстве. Для автоматизированного развертывания на устройстве устанавливается первичный (master) образ. Затем при каждом запуске теста выполняются перечисленные операции.

  1. Загружается первичный образ, используемый для записи тестируемого образа во второй раздел.
  2. Устройство перезагружается с помощью внешнего сценария, который нужно создать.
  3. Загружается тестируемый образ.

При запуске тестов (независимо от способа разворачивания образа) устройство предполагается подключенным к сети с известным адресом IP, который может быть статическим или полученным от сервера DHCP. Для запуска тестов на устройстве нужно установить в переменной TEST_TARGET подходящее значение (для QEMU это не требовалось).

  • SimpleRemoteTarget для запуска тестов на целевой системе, в которой уже имеется тестируемый образ и доступна сеть. Этот вариант пригоден для реального устройства или образа, запущенного в QEMU или на иной виртуальной машине.
  • SystemdbootTarget для машин на основе EFI с загрузчиком systemd-boot и установленным core-image-testmaster (или аналогом). Устройство должно быть подключено к сети с поддержкой DHCP и сохранением IP-адреса при перезагрузке. Для этого режима имеются дополнительные требования, описанные в параграфе 3.29.1.3. Выбор SystemdbootTarget.
  • BeagleBoneTarget при разворачивании образов и запуске тестов на устройстве BeagleBone «Black» или оригинальном «White». Описание тестов дано в файле meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py.
  • EdgeRouterTarget при разворачивании образов и запуске тестов на устройстве Ubiquiti Networks EdgeRouter Lite. Описание тестов дано в файле meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py.
  • GrubTarget при разворачивании образов и запуске тестов на ПК с загрузчиком GRUB. Описание тестов дано в файле meta-yocto-bsp/lib/oeqa/controllers/grubtarget.py.
  • your-target при разворачивании образов и запуске тестов на машине с пользовательским уровнем BSP. Для этого нужно добавить модуль Python, определяющий класс цели, в каталог lib/oeqa/controllers/ на своем уровне, а также обеспечить пустой файл __init__.py. Примеры даны в meta-yocto-bsp/lib/oeqa/controllers/.
3.29.1.3. Выбор SystemdbootTarget

При выборе TEST_TARGET = «SystemdbootTarget» нужно выполнить однократную настройку первичного образа.

  1. Установка EFI_PROVIDER = «systemd-boot».
  2. Сборка первичного образа core-image-testmaster. Задание для образа приведено в качестве примера и может быть настроено в соответствии с задачей. Требования к образу приведены ниже.
    • Наследование core-image для установки модулей ядра.
    • Установка обычных утилит Linux, а не busybox (bash, coreutils, tar, gzip, kmod).
    • Применение образа initramfs с настроенным установщиком. Обычно образ создает один раздел rootfs, но здесь применяется образ, создающий определенный набор разделов. Установщик подходит не для всех BSP и может потребоваться создание разделов вручную по описанной ниже схеме.
      • Первый раздел с точкой монтирования /boot и меткой «boot».
      • Основной раздел rootfs для установки образа с точкой монтирования /.
      • раздел с меткой «testrootfs» для разворачивания тестируемого образа.
  3. Установка образа, созданного для целевой системы.

В заключение нужно установить тестируемый образ.

  1. Настройка файла local.conf путем включения приведенных ниже строк.
         IMAGE_FSTYPES += "tar.gz"
         INHERIT += "testimage"
         TEST_TARGET = "SystemdbootTarget"
         TEST_TARGET_IP = "192.168.2.3"    
  2. Сборка тестируемого образа с помощью команды bitbake core-image-sato.
3.29.1.4. Управление питанием

Для большинства аппаратных платформ (кроме SimpleRemoteTarget) возможно управление питанием.

  • Можно использовать TEST_POWERCONTROL_CMD вместе с TEST_POWERCONTROL_EXTRA_ARGS как команду, выполняемую на хосте для управления питанием. Код теста передает один аргумент — off, on или cycle (off, затем on). Например, в файле local.conf можно задать TEST_POWERCONTROL_CMD = «powercontrol.exp test 10.11.12.1 nuc1». В этом случае предполагается, что сценарий выполняет команду ssh test@10.11.12.1 «pyctl nuc1 arg«, затем выполняется сценарий Python для управления питанием с именем nuc1. Нужно настроить TEST_POWERCONTROL_CMD и TEST_POWERCONTROL_EXTRA_ARGS для своей ситуации. Единственным требованием является указание on, off или cycle в качестве последнего аргумента.
  • Когда команда не задана, происходит подключение к устройству через SSH и выполняется обычная команда reboot для перезагрузки устройства. Это хорошо в тех случаях, когда машина действительно перезагружается (тест SSH не дает отказа). Это полезно в простых ситуациях, обычно с одной платой, где время от времени возможно ручное воздействие.

Если оборудование не поддерживает управление питанием, но нужно провести эксперимент с автоматизированным тестированием устройства, можно использовать сценарий dialog-power-control, который выводит диалог, приглашающий выполнить нужную операцию управления питанием. Для этого сценария нужно установить KDialog или Zenity и задать TEST_POWERCONTROL_CMD = «${COREBASE}/scripts/contrib/dialog-power-control».

3.29.1.5. Подключение последовательной консоли

Если тест на целевой машине требует последовательную консоль для взаимодействия с загрузчиком (например, BeagleBoneTarget, EdgeRouterTarget, GrubTarget), нужно указать команду соединения с консолью на целевой машине в переменной TEST_SERIALCONTROL_CMD и возможно в TEST_SERIALCONTROL_EXTRA_ARGS.

Это может быть терминальная программа, если машина подключена к локальному последовательному порту, а также telnet или ssh при удаленном подключении к консоли. Независимо от способа программе нужно просто подключиться к последовательной консоли и перенаправить это соединение на стандартный ввод и вывод, как делает любая терминальная программа. Например, при использовании программы picocom на последовательном порту /dev/ttyUSB0 во скоростью 115200 бит/с можно задать TEST_SERIALCONTROL_CMD = «picocom /dev/ttyUSB0 -b 115200».

Для локальных устройств, где последовательное устройство исчезает при перезагрузке, предоставляется дополнительный сценарий serdevtry, который просто указывается в качестве префикса команды вызова терминала с указанием пути. Например, TEST_SERIALCONTROL_CMD = «${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0».

3.29.2. Запуск тестов

Тесты можно запускать автоматически или вручную.

  • Автоматический запуск. Для автоматического запуска теста после создания образа системой сборки OE нужно сначала установить в файле local.conf каталога сборки TESTIMAGE_AUTO = «1», а затем собрать образ. После успешной сборки вводится команда bitbake core-image-sato.
  • Запуск вручную. Для запуска вручную нужно сначала глобально унаследовать класс testimage, включив в файл local.conf строку INHERIT += «testimage», а затем запустить тесты командой bitbake -c testimage image.

Все файлы тестов хранятся в каталоге meta/lib/oeqa/runtime внутри дерева исходных кодов, имена тестов напрямую отображаются на модули Python. Каждый модуль может включать множество тестов, которые обычно группируются по функциональным областям (например, тесты для systemd собраны в модуле meta/lib/oeqa/runtime/systemd.py).

Тесты можно добавить на любой уровень, разместив их в подходящем месте (layer/lib/oeqa/runtime) и добавив его в переменную BBPATH файла local.conf file. Имена модулей не должны совпадать с именами из meta/lib/oeqa/runtime.

Можно изменить набор тестов путем добавления или переопределения переменной TEST_SUITES в local.conf, где каждое имя представляет требуемый для образа тест. Модули из TEST_SUITES не могут быть пропущены, даже когда тест не подходит для образа (например, запуск тестов RPM на образе без rpm). Добавление auto в TEST_SUITES заставляет систему сборки пытаться запустить все подходящие для образа тесты (т. е. каждый модуль может пропустить себя). Порядок тестов в TEST_SUITES важен и зависит от зависимостей между тестами, поэтому тест, зависящий от другого теста, нужно указывать после того, от которого он зависит. Например, поскольку тест ssh зависит от теста ping, следует помещать ssh в список после ping. Класс test не меняет порядок и не контролирует зависимости.

Каждый метод может иметь несколько классов с разными методами тестирования. Применяются правила Python unittest. Ниже указаны некоторые обстоятельства, которые нужно принимать во внимание при запуске тестов.

  • По умолчанию тесты для образа определяется в виде DEFAULT_TEST_SUITES_pn-image = «ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg».
  • Добавление своих тестов в список имеет форму TEST_SUITES_append = » mytest».
  • Конкретный набор тестов запускается в виде TEST_SUITES = «test1 test2 test3».

3.29.3. Экспорт тестов

Можно экспортировать тесты для запуска независимо от системы сборки. Экспорт требуется, если нужно запускать тесты вручную без планировщика. Можно экспортировать лишь тесты, указанные в TEST_SUITES.

Если образ уже собран, нужно проверить наличие в local.conf приведенных ниже строк.

INHERIT +="testexport"
     TEST_TARGET_IP = "IP-address-for-the-test-target" TEST_SERVER_IP = "IP-address-for-the-test-server"

После этого тесты можно экспортировать командой bitbake image -c testexport. Экспортируемые тесты помещаются в каталог tmp/testexport/image области сборки, указываемый переменной TEST_EXPORT_DIR.

Экспортированные тесты можно запускать извне среды сборки, как показано ниже.

$ cd tmp/testexport/image $ ./runexported.py testdata.json  

Ниже приведен пример, показывающий адреса IP и использующий образ core-image-sato:

     INHERIT +="testexport"
     TEST_TARGET_IP = "192.168.7.2"
     TEST_SERVER_IP = "192.168.7.1"    

Тест экспортируется командой bitbake core-image-sato -c testexport и запускается извне, как показано ниже.

     $ cd tmp/testexport/core-image-sato
     $ ./runexported.py testdata.json

3.29.4. Создание новых тестов

Все новые тесты нужно размещать в корректном месте, чтобы система сборки могла найти их. Тесты функций, добавляемых тем или иным уровнем, следует размещать в каталоге layer/lib/oeqa/runtime (при условии обычного расширения переменной BBPATH в файле уровня layer.conf). Следует помнить отмеченные ниже детали.

  • Имена файлов должны напрямую отображаться на имена тестов (модулей).
  • Недопускается использование имен, совпадающих с именами имеющихся тестов.
  • Как минимум в каталоге запуска тестов должен быть пустой файл __init__.py.

Создание нового теста уместно начать с копирования имеющегося (например, syslog.py или gcc.py удобны в качестве образца). Модули тестов могут использовать код из вспомогательных классов meta/lib/oeqa/utils.

Команды оболочки следует структурировать так, чтобы на них можно было полагаться, а при успехе они бы возвращали один код. Следует учитывать необходимость анализа вывода в некоторых случаях. Примеры модулей можно найти в файлах df.py и date.py.

Все классы тестов наследуют oeRuntimeTest из файла meta/lib/oetest.py. Этот базовый класс предлагает некоторые атрибуты, описанные ниже.

3.29.4.1. Методы класса
  • hasPackage(pkg) возвращает True, если пакет pkg имеется в списке установленных в образ, основанном на файле манифеста, создаваемом задачей do_rootfs task.
  • hasFeature(feature) возвращает True если feature имеется в IMAGE_FEATURES или DISTRO_FEATURES.
3.29.4.2. Атрибуты класса
  • pscmd эквивалентна «ps -ef», если procps имеется в образе. В остальных случаях pscmd будет «ps» (busybox).
  • tcконтекст вызванного теста с доступом к перечисленным ниже атрибутам.
    • dхранилище данных BitBake, позволяющие использовать такие вызовы, как oeRuntimeTest.tc.d.getVar(«VIRTUAL-RUNTIME_init_manager»).
    • testslist и testsrequired служат для внутреннего использования и не нужны тестам.
    • filesdirабсолютный путь к meta/lib/oeqa/runtime/files, где содержатся вспомогательные файлы тестов для копирования в целевую систему (такие, как небольшие файлы C для компиляции).
    • targetобъект контроллера целевой системы, используемый для развертывания и запуска определенного образа (например, QemuTarget, SimpleRemote, SystemdbootTarget). Тесты обычно используют приведенные ниже элементы.
      • ip — IP-адрес целевой системы.
      • server_ip — IP-адрес хоста, который обычно используется тестами DNF.
      • run(cmd, timeout=None) единственный, наиболее используемый метод. Команда служит «оболочкой» для ssh root@host «cmd» и возвращает пару (status, output) — код возврата cmd и ее вывод. Необязательный аргумент timeout указывает число секунд, в течение которых тесту следует ожидать возврата cmd. Значение None задает принятый по умолчанию интервал 300 секунд, 0 задает неограниченное ожидание.
      • copy_to(localpath, remotepath) — scp localpath root@ip:remotepath.
      • copy_from(remotepath, localpath) — scp root@host:remotepath localpath.
3.29.4.3. Атрибуты экземпляра

Имеется один атрибут экземпляраtarget, который идентичен атрибуту класса с тем же именем, описанному выше. Этот атрибут существует для экземпляра и класса, поэтому тесты могут использовать в методах экземпляра self.target.run(cmd) вместо oeRuntimeTest.tc.target.run(cmd).

3.29.5. Установка пакетов на тестируемом устройстве без менеджера пакетов

Когда для теста нужен пакет, созданный BitBake, этот пакет можно установить для чего на тестируемом устройстве не требуется менеджер пакетов. Однако потребуется соединение SSH, а целевая система должна использовать класс sshcontrol. Этот метод использует команду scp для копирования файлов между хостом и целью, что ведет к потере прав доступа и специальных атрибутов.

Используется файл JSON для определения требуемых тесту пакетов. Этот файл должен размещаться там же, где находится определяющий тест файл. Кроме того, имя файла должно напрямую отображаться на имя тестового модуля и использовать расширение .json. Файл должен включать объект с именем теста в качестве ключа объекта или массива. Этот объект (массив объектов) использует указанные ниже данные.

  • «pkg» — обязательная строка, указывающая имя устанавливаемого пакета.
  • «rm» — необязательное логическое значение, управляющее удалением пакета после теста (по умолчанию false).
  • «extract» — необязательное логическое значение, управляющее распаковкой формата пакета (по умолчанию false). При значении true пакет не устанавливается автоматически на тестируемом устройстве.

Далее приведен пример файла JSON для теста foo, устанавливающего пакет bar, и теста foobar, устанавливающего пакеты foo и bar. По завершении теста пакеты на устройстве удаляются.

     {
         "foo": {
 "pkg": "bar"
         },
         "foobar": [
 {
     "pkg": "foo",
     "rm": true
 },
 {
     "pkg": "bar",
     "rm": true
 }
         ]
     }

3.30. Средства и методы отладки

Конкретный метод отладки зависит от природы проблемы и области, где возникает ошибка. Стандартные методы отладки на основе сравнение с последним работающим вариантом и проверки внесенных изменений и поэтапным их анализом для поиска источника проблемы применимы в YP как и других системах. Хоть и невозможно детализировать каждый отказ, в этом разделе даны некоторые базовые советы, которые помогут при устранении проблем.

Для отладки полезны инструменты отчетов об ошибках. Включение этих инструментов в YP заставляет систему сборки OE выводить сообщения об ошибках на консоль сборки. По завершении сборки можно сохранить эту информацию в общей базе данных, которая может помочь в поиске источников проблем. Информация о работе с инструментом информирования об ошибках приведена в параграфе 3.33. Использование инструмента отчетов об ошибках.

3.30.1. Просмотр журналов отказов задач

Журнал задачи можно найти в файле ${WORKDIR}/temp/log.do_taskname. Например, журнал задачи do_compile минимального образа QEMU для машины x86 (qemux86) будет в файле tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile. Для просмотра команд BitBake, связанных с журналом, следует обратиться к соответствующему файлу run.do_taskname в том же каталоге. Файлы log.do_taskname и run.do_taskname на деле являются символьными ссылками на файлы log.do_taskname.pid и log.run_taskname.pid, где pid является идентификатором PID выполнявшейся задачи. Символьный ссылки всегда указывают на последние файлы.

3.30.2. Просмотр значений переменных

Иногда нужно узнать значение переменной на этапе анализа BitBake. Это может быть связано с неожиданным поведением проекта. Причиной может быть, например, неудачная попытка изменить переменную. Опция BitBake -e позволяет увидеть значения переменных после анализа файлов конфигурации (local.conf, bblayers.conf, bitbake.conf и т. д.). Команда bitbake -e recipename выведет значения переменных после анализа указанного задания.

Каждое задание имеет свой набор переменных (хранилище данных). После анализа конфигурации делается копия хранилища до начала анализа заданий. Такое копирование предполагает, что набор переменных одного задания не виден другим заданиям. В задании каждая задача имеет доступ к хранилищу данных задания и установленные задачей переменные доступны другим задачам в рамках этого задания.

В выводе команды bitbake -e каждой переменной предшествует информация о способе ее назначения, включая временные значения, которые были переопределены, и установленные флаги (varflags). Это удобно для отладки. Переменные, экспортируемые в среду, указываются с префиксом export в выводе bitbake -e. Например, export CC=»i586-poky-linux-gcc -m32 -march=i586 —sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86″.

Кроме значений переменных по команде bitbake -e или bitbake -e recipe выводятся приведенные ниже данные.

  • Вывод начинается с дерева, где указаны все файлы конфигурации и классы, включенные глобально, с рекурсивным указанием включаемых и наследуемых файлов. Большая часть поведения системы сборки OE (включая поведение обычных задач сборки задания) реализована в классе base и наследуемых им классах, а не в самой программе BitBake.
  • После значений переменных выводятся все функции. Для функций оболочки включенные в них переменные преобразуются. Если функция изменяется путем переопределения или операторов со стилем переопределения, таких как _append и _prepend, выводится окончательная функция.

3.30.3. Просмотр данных пакетов с помощью oe-pkgdata-util

Утилита oe-pkgdata-util позволяет запрашивать PKGDATA_DIR и выводит связанную с пакетом информацию для пакетов, которые уже собраны. Ниже описаны некоторые субкоманды oe-pkgdata-util. В именах пакетов и путях допускается использование обычных шаблонов * и ?.

  • oe-pkgdata-util list-pkgs [pattern] выводит данные о всех или соответствующих шаблону pattern пакетах.
  • oe-pkgdata-util list-pkg-files package … выводит файлы и каталоги указанных пакетов. Другим вариантом просмотра содержимого пакетов является изучение каталога ${WORKDIR}/packages-split в задании для пакета. Этот каталог создается задачей do_package и включает один подкаталог для каждого создаваемого заданием пакета. Для просмотра каталогов ${WORKDIR}/packages-split нужно отключить rm_work при сборке задания.
  • oe-pkgdata-util find-path path … выводит имена всех пакетов, включающих указанные пути. Например, приведенная ниже команда говорит, что файл /usr/share/man/man1/make.1 включен в пакет make-doc.
         $ oe-pkgdata-util find-path /usr/share/man/man1/make.1
         make-doc: /usr/share/man/man1/make.1
  • oe-pkgdata-util lookup-recipe package … выводит имена заданий, создавших указанные пакеты.

Для получения дополнительной информации о командах oe-pkgdata-util можно использовать команды

$ oe-pkgdata-util ‐‐help
     $ oe-pkgdata-util subcommand --help 

3.30.4. Просмотр зависимостей между заданиями и задачами

Иногда бывает сложно понять, почему BitBake хочет собрать другие задания перед сборкой указанного. Информация о зависимостях помогает в этом. Для получения данных о зависимостях задания служит команда bitbake -g recipename, которая выводит в текущий каталог два файла, указанных ниже.

  • pn-buildlistсписок задач и целей, вовлеченных в сборку задания recipename. Вовлеченность означает, что по меньшей мере одна из задач задания нужна при сборке recipename с нуля. Цели, указанные в ASSUME_PROVIDED, не выводятся.
  • task-depends.dotграф зависимостей между задачами.

Граф выводится в формате DOT и может быть преобразован в изображение (например, с помощью dot из Graphviz).

  • Файлы DOT имеют текстовый формат. Граф создается с помощью команды bitbake -g и часто бывает достаточно большим для чтения без специальной очистки (например, опции Bitbake -I) и обработки. Тем не менее, файлы .dot могут быть полезны для получения информации. Например, строка «libxslt.do_configure» -> «libxml2.do_populate_sysroot» в файле task-depends.dot указывает, что задача do_configure в libxslt зависит от задачи do_populate_sysroot в libxml2, которая указана в DEPENDS.
  • Примером обработки файлов .dot является сценарий Python scripts/contrib/graph-tool, который находит и показывает пути между узлами графа.

Другим вариантом просмотра данных о зависимостях служит команда bitbake -g -u taskexp recipename, которая выводит окно графического интерфейса с зависимостями при сборке и работе для заданий, включенных в сборку recipename.

3.30.5. Просмотр зависимостей между переменными задач

Как отмечено в разделе Checksums (Signatures) [6], BitBake пытается автоматически определить, от каких переменных зависит задача, если значения переменных меняются. Это определение обычно надежно, однако в таких ситуациях, как создание имен переменных в процессе работы, может потребоваться вручную указывать зависимости от этих переменных с помощью vardeps, как описано в разделе Variable Flags [6]. Если нет уверенности в автоматическом определении зависимостей переменной для данной задачи, можно посмотреть зависимости, найденные BitBake.

  1. Сборка задания, содержащего задачу по команде bitbake recipename.
  2. Просмотр в каталоге STAMPS_DIR файла данных подписи (sigdata), соответствующего задаче. Файлы sigdata содержат базу данных Python со всеми метаданными, использованными при создании контрольной суммы для задачи. Например, для do_fetch в задании db файл sigdata можно найти в каталоге ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1. Для задач, ускоренных через кэш общего состояния (sstate), создается дополнительный файл siginfo в SSTATE_DIR вместе с кэшированным выводом задачи. Файлы siginfo содержат те же данные, что и sigdata.
  3. Ввод команды bitbake-dumpsig для файла sigdata или siginfo. Например, bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1. Вывод этой команды позволяет увидеть строки предполагаемых зависимостей переменных для задачи с учетом рекурсивных зависимостей. Например, Task dependencies: [‘PV’, ‘SRCREV’, ‘SRC_URI’, ‘SRC_URI[md5sum]’, ‘SRC_URI[sha256sum]’, ‘base_do_fetch’]. Функции (например, base_do_fetch) также учитываются в зависимостях переменных и сами зависят от указанных в них переменных. Вывод bitbake-dumpsig включает также значение каждой переменной, список ее зависимостей, и данные BB_HASHBASE_WHITELIST.

Имеется также команда bitbake-diffsigs для сравнения двух файлов siginfo или sigdata, которая может быть полезна при поиске различий между двумя версиями задачи. При вызове команды для одного файла она ведет себя как bitbake-dumpsig. Можно также использовать BitBake для вывода данных подписи без выполнения задачи с помощью опции BitBake ‐‐dump-signatures=SIGNATURE_HANDLER или -S SIGNATURE_HANDLER. Основными значениями SIGNATURE_HANDLER являются none и printdiff, обеспечивающие вывод лишь подписи или сравнение подписи с кэшированной. Использование BitBake с любой из этих опций заставляет BitBake вывести дамп файлов sigdata в каталоге stamps для каждой задачи, которая будет выполняться, без реальной сборки указанного пакета.

3.30.6. Просмотр метаданных, использованных для создания входной подписи

Просмотр метаданных, используемых для создания входной подписи sstate также может помочь при отладке. Эта информация доступна в файлах siginfo каталога SSTATE_DIR. Интерпретация данных описана в предыдущем параграфе. Концепции общего состояния рассмотрены в разделе Shared State [1].

3.30.7. Аннулирование общего состояния для повторного запуска задачи

Система сборки OE использует контрольные суммы и кэш общего состояния для предотвращения ненужного повтора сборки задач. Эту схему называют кодом общего состояния и как все схемы, она обладает некоторыми недостатками. Возможны случаи неявного внесения в код изменений, которые не будут учтены при расчете контрольной суммы. Эти изменения влияют на вывод задачи, но не вызывают код общего состояния в повторной сборке задания. Рассмотрим пример, где инструмент меняет вывод rpmdeps. Результатом изменения должна стать недействительность всех элементов кэша общего состояния для package и package_write_rpm. Однако изменение является внешним (неявным), поэтому записи кэша общего состояния остаются корректными и процесс сборки будет использовать их вместо перезапуска задачи, что может вызвать проблемы.

Для предотвращения проблем при сборке нужно понимать последствия вносимых изменений, помня о том, что вносимые напрямую в функцию изменения отражаются в контрольной сумме, делая соответствующую область кэша общего состояния недействительной. Однако следует помнить, что неявные изменения не очевидны и могут влиять на результаты выполнения задачи. При обнаружении неявных изменений можно предпринять действия по аннулированию кэша для повторного запуска задачи. Например, для аннулирования файлов общего состояния пакета можно изменить комментарии задачи do_package или какой-либо из вызываемых ею функций. Хотя это изменение будет косметическим, оно повлияет на контрольную сумму и заставит систему сборки заново выполнить задачу. Пример такого подхода доступен по ссылке.

3.30.8. Запуск конкретных задач

Любое задание состоит из набора задач. Стандартный порядок выполнения задач в BitBake имеет вид — do_fetch, do_unpack, do_patch, do_configure, do_compile, do_install, do_package, do_package_write_*, do_build. По умолчанию выполняется задача do_build и все задачи, которые требуется выполнить до нее. Некоторые задачи (например, do_devshell) не входят по умолчанию в цепочку сборки. Для запуска таких задач можно использовать опцию -c в BitBake, например,

     $ bitbake matchbox-desktop -c devshell

Опция -c учитывает зависимости задач и будет заранее запускать все задачи, от которых зависит выполняемая задача (включая задачи из других заданий). Даже при указании задачи вручную с помощью опции -c программа будет запускать лишь те задачи, которые она сочтет нужными. Выбор актуальных задач описан в разделе Stamp Files and the Rerunning of Tasks [1].

Если нужно форсировать запуск устаревшей задачи (например, после внесения вручную изменений в каталог WORKDIR задания), можно воспользоваться опцией -f. Эта опция никогда не требуется при работе с задачей do_devshell, поскольку для этой задачи уже установлен флаг переменной [nostamp]. Ниже приведен пример использования опции -f.

     $ bitbake matchbox-desktop
   ...
     Внесение изменений в рабочий каталог
   ...
     $ bitbake matchbox-desktop -c compile -f
     $ bitbake matchbox-desktop    

Эта последовательность сначала собирает, а затем заново компилирует matchbox-desktop. Последняя команда перезапускает все задачи (в основном, упаковку) поле компиляции. BitBake понимает, что задача do_compile была запущена повторно и это требует перезапуска других задач.

Более короткий способ перезапуска задачи и всех обычных задач сборки задания, зависящих от нее, обеспечивает опция -C (не следует путать с -c). Опция аннулирует данную задачу и запускает задачу do_build, которая используется по умолчанию, и задачи от которых та зависит. Для этого две последних команды в приведенном выше примере следует заменить командой bitbake matchbox-desktop -C compile. Опции -f и -C работают за счет изменения входной контрольной суммы указанной задачи, что косвенно вызывает перезапуск задачи и зависимых от нее задач с использованием обычных механизмов зависимости.

BitBake явно отслеживает изменение задач таким способом и будет выдавать при следующей сборке, включающей такие задачи, предупреждение вида WARNING: /home/ulf/poky/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run. Цель этого предупреждения заключается в уведомлении пользователя о том, что рабочий каталог и вывод сборки могут не быть «чистыми» как при нормальной сборке. Чтобы избежать таких предупреждений, можно очистить рабочий каталог и заново собрать задание, как показано ниже.

     $ bitbake matchbox-desktop -c clean
     $ bitbake matchbox-desktop

Список задач данного пакета можно посмотреть, запустив задачу do_listtasks командой вида bitbake matchbox-desktop -c listtasks. Результат будет выведен на консоль и записан в файл ${WORKDIR}/temp/log.do_listtasks.

3.30.9. Отладочный вывод BitBake

Отладочный вывод BitBake обеспечивает опция -D, которую можно указывать до 3 раз (-DDD) для расширения подробностей. Команда bitbake -DDD -v targetname может показать, почему программа BitBake выбрала ту или иную версию пакета и провайдера, а также помогает в ситуациях, когда результат представляется неожиданным.

3.30.10. Сборка без зависимостей

Для сборки конкретного задания ( файл.bb) можно применить команду вида bitbake -b somepath/somerecipe.bb. Команда не проверяет зависимостей, поэтому нужно проверить их выполнение. Имя файла можно указать частично и BitBake будет искать уникальное совпадение.

3.30.11. Механизмы протоколирования заданий

YP обеспечивает несколько механизмов протоколирования для отладочного вывода и уведомлений об ошибках и предупреждениях. Ниже перечислены функции Python для протоколирования, обеспечивающие запись в файлы журналов ${T}/log.do_task и на стандартный вывод.

  • bb.plain(msg) записывает msg в журнальный файл и на стандартный вывод.
  • bb.note(msg) записывает «NOTE: msg» в журнальный файл, а также на стандартный вывод (с опцией -v).
  • bb.debug(level, msg) записывает «DEBUG: msg» в журнальный файл, а также на стандартный вывод, если уровень не меньше значения level (см. опцию -D [6]).
  • bb.warn(msg) записывает «WARNING: msg» в журнальный файл и на стандартный вывод.
  • bb.error(msg) записывает «ERROR: msg» в журнальный файл и на стандартный вывод. Вызов этой функции не ведет к отказу задачи.
  • bb.fatal(msg) похожа на bb.error(msg), но ведет к отказу задачи.bb.fatal() создает исключительную ситуацию, означающую, что не нужно помещать return после функции.

Такие же функции протоколирования доступны для функций оболочки bbplain, bbnote, bbdebug, bbwarn, bberror, bbfatal) и реализованы в классе logging (см. каталог meta/classes в дереве исходных кодов).

3.30.11.1. Журналы Python

При подготовке заданий, использующих Python, с кодом обслуживания журналов сборки следует учитывать, что журналы предназначены в основном для информирования с минимизацией вывода на консоль. Если нужны сообщения о состоянии, следует указывать уровень протоколирования debug.

Ниже приведен пример на языке Python для обработки журналов в плане определения числа задач, которые нужно запустить. Дополнительная информация приведена в разделе do_listtasks [3]).

     python do_listtasks() {
         bb.debug(2, "Starting to figure out the task list")
         if noteworthy_condition:
 bb.note("There are 47 tasks to run")
         bb.debug(2, "Got to point xyz")
         if warning_trigger:
 bb.warn("Detected warning_trigger, this might be a problem later.")
         if recoverable_error:
 bb.error("Hit recoverable_error, you really need to fix this!")
         if fatal_error:
 bb.fatal("fatal_error detected, unable to print the task list")
         bb.plain("The tasks present are abc")
         bb.debug(2, "Finished figuring out the tasklist")
     }
3.30.11.2. Журналы Bash

При подготовке заданий, использующих Bash, с кодом обслуживания журналов сборки следует учитывать, что журналы предназначены в основном для информирования с минимизацией вывода на консоль. Синтаксис, применяемый для заданий, написанных на Bash, аналогичен синтаксису заданий на Python, описанных в предыдущем параграфе. Ниже приведен пример для Bash, регистрирующий выполнение функции do_my_function.

     do_my_function() {
         bbdebug 2 "Running do_my_function"
         if [ exceptional_condition ]; then
 bbnote "Hit exceptional_condition"
         fi
         bbdebug 2  "Got to point xyz"
         if [ warning_trigger ]; then
 bbwarn "Detected warning_trigger, this might cause a problem later."
         fi
         if [ recoverable_error ]; then
 bberror "Hit recoverable_error, correcting"
         fi
         if [ fatal_error ]; then
 bbfatal "fatal_error detected"
         fi
         bbdebug 2 "Completed do_my_function"
     }

3.30.12. Отладка конфликтов параллельной сборки

Параллельная сборка представляет собой одновременное выполнение нескольких частей задания, при котором могут возникать ситуации, когда требуемые для работы результаты еще не готовы. Такие конфликты раздражают, а порой их сложно воспроизвести и устранить. Однако есть ряд простых рекомендаций, которые помогают решить проблему. Ниже представлен реальный пример ошибки, с которой сталкивается YP autobuilder и способ ее исправления.

Если конфликт не удается исправить, можно попытаться сбросить PARALLEL_MAKE или PARALLEL_MAKEINST.

3.30.12.1. Отказы

Предположим, например, что собирается образ, который зависит от пакета neard, и при сборке BitBake сталкивается с проблемой, выводя показанные ниже сообщения (строки вывода дополнительно разбиты для удобства восприятия).

| DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common']
| DEBUG: Executing shell function do_compile
| NOTE: make -j 16
| make --no-print-directory all-am
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/types.h include/near/types.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/log.h include/near/log.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/tag.h include/near/tag.h
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/setting.h include/near/setting.h
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/device.h include/near/device.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/snep.h include/near/snep.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/version.h include/near/version.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
  0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h
| ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h
| i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/
  build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus  -I/home/pokybuild/
  yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
  -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
  lib/glib-2.0/include  -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/
  tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/
  nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include  -I/home/pokybuild/yocto-autobuilder/
  yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
  -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\"
  -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c
  -o tools/snep-send.o tools/snep-send.c
| In file included from tools/snep-send.c:16:0:
| tools/../src/near.h:41:23: fatal error: near/dbus.h: No such file or directory
|  #include <near/dbus.h>
|                        ^
| compilation terminated.
| make[1]: *** [tools/snep-send.o] Error 1
| make[1]: *** Waiting for unfinished jobs....
| make: *** [all] Error 2
| ERROR: oe_runmake failed
3.30.12.2. Воспроизведение ошибок

Конфликты при параллельной сборке могут не возникать каждый раз, поэтому нужен способ воспроизведения таких ошибок. В приведенном ниже примере компиляция пакета neard вызывает проблему. Поэтому сначала нужно собрать neard локально. Перед началом сборки в переменной PARALLEL_MAKE файла local.conf устанавливается большое значение (например, «-j 20»), что повысит вероятность возникновения ошибки. Далее выполняется сборка по команде bitbake neard, а по ее завершении запускается сборка командой bitbake neard -c devshell (см. раздел 3.8. Использование среды devshell). В среде devshell вводятся команды

     $ make clean
     $ make tools/snep-send.o

Это позволит четко увидеть отказ. В данном случае отсутствует зависимость neard для цели Makefile, как можно видеть из сокращенного вывода, представленного ниже.

     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/scott-lenovo/......
        ...
     tools/snep-send.c
     In file included from tools/snep-send.c:16:0:
     tools/../src/near.h:41:23: fatal error: near/dbus.h: No such file or directory
      #include <near/dbus.h>
           ^
     compilation terminated.
     make: *** [tools/snep-send.o] Error 1
     $
3.30.12.3. Подготовка исправлений

Поскольку отсутствует зависимость для цели Makefile, нужно исправить файл Makefile.am, создаваемый из Makefile.in. Можно использовать Quilt для создания patch-файла (см. раздел 3.7. Использование Quilt).

     $ quilt new parallelmake.patch
     Patch patches/parallelmake.patch is now on top
     $ quilt add Makefile.am
     File Makefile.am added to patch patches/parallelmake.patch

Здесь нужно отредактировать файл Makefile.am для добавления нужной зависимости. Например, это может быть строка вида

     tools/snep-send.$(OBJEXT): include/near/dbus.h

После редактирования файла нужно создать patch-файл с помощью команды

     $ quilt refresh
     Refreshed patch patches/parallelmake.patch

Полученный файл исправления нужно добавить в каталог задания командой вида

     $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard

В заключение нужно применить правки к сборке задания neard (neard-0.14.bb), чтобы оператор SRC_URI включал patch-файл. Переменная в результате будет иметь вид

     SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
    file://neard.in \
    file://neard.service.in \
    file://parallelmake.patch \
   "

После этого можно завершить работу с devshell командой exit.

3.30.12.4. Тестирование сборки

После внесений всех исправления можно повторить локальную сборку командой bitbake neard и результат должен быть положительным. Затем можно снова открыть devshell и повторить очистку и сборку, как показано ниже.

     $ bitbake neard -c devshell
     $ make clean
     $ make tools/snep-send.o

Проблем возникать не должно. После внесения всех корректировок их следует зафиксировать для задания в OE-Core и восходящем репозитории, чтобы проблема не повторялась у других (см. параграф 3.31.2. Представление изменений в YP).

3.30.13. Удаленная отладка с помощью GDB

GDB2 позволяет проверять запущенные программы с целью поиска и исправления неполадок, а также выполнять анализ данных после отказа программ. GDB доступен в составе YP и по умолчанию устанавливается в образах SDK, описание которых приведено в разделе Images [3]. Описание GDB доступно на странице http://sourceware.org/gdb/. Для более эффективной работы следует установить отладочные (-dbg) пакеты для приложений, которые планируется отлаживать. Это сделает доступными отладочные символы и сделает вывод более информативным.

Иногда нехватка памяти или дискового пространства не позволяет использовать GDB на целевой платформе напрямую. GDB для работы нужно загрузить отладочную информацию и двоичные файлы, кроме того программе приходиться выполнять много расчетов для поиска информации (имена и значения переменных, трассировка стека и т. п.). Эти издержки повышают нагрузку на устройство и могут менять характеристики отлаживаемых программ. Для решения проблемы можно использовать на целевой платформе программу gdbserver, которая не загружает отладочную информацию. Вместо этого отладочную информацию обрабатывает экземпляр GDB на хосте отладки. Этот хост передает команды управления программе gdbserver для запуска и остановки отлаживаемой программы, а считывания и записи информации в память отлаживаемой программы. Вся отладочная информация загружается и обрабатывается на хосте GDB, что позволяет сервер gdbserver быть компактным и быстрым.

Поскольку хост GDB отвечает за загрузку и обработку отладочной информации, для отладки нужно убедиться, что этот хост имеет доступ к двоичным файлам с отладочными символами, а также обеспечить компиляцию для целевой платформы без оптимизации. Хост GDB также должен иметь локальный доступ ко всем библиотекам, используемым отладочной программой. Поскольку для gdbserver отладочная информация локально не нужна, ее можно исключить из двоичных файлов для целевой системы. Однако для соответствия с двоичными файлами на хосте отладки компиляция должна выполняться без оптимизации. В соответствии с документацией GDB будем называть двоичный файл на целевой системе «подчиненным» (inferior). Ниже описан процесс удаленной отладки с использованием GDB.

  1. Настройка системы сборки для создания отладочной файловой системы. В файле local.conf следует указать
         IMAGE_GEN_DEBUGFS = "1"
         IMAGE_FSTYPES_DEBUGFS = "tar.bz2"

    Эти опции заставят систему сборки OE создать специальную файловую систему для отладки, которая будет включать соответствующий исходный код и символы отладки для развертываемой файловой системы. Система сборки делает это путем просмотра содержимого разворачиваемой файловой системы и извлечения соответствующих пакетов -dbg. Отладочная файловая система не является полной и содержит лишь компоненты отладки. Она должна применяться вместе с полной файловой системой, как показано ниже.

  2. Настройка системы для включения gdbserver на удаленной файловой системе. В файл local.conf или задание для образа нужно включить строку IMAGE_INSTALL_append = “ gdbserver», которая обеспечит сервер.
  3. Сборка среды для создания образа и сопровождающей отладочной файловой системы командой bitbake image. Сборку кросс-компоненты GDB и ее подготовку для отладки лучше всего выполнить путем сборки SDK с помощью команды bitbake -c populate_sdk image. Другим вариантом является сборка минимального инструментария, соответствующего целевой системе. Этот вариант более компактный и реализуется командой bitbake meta-toolchain.Еще один метод заключается в автономной сборке GDB по команде bitbake gdb-cross-architecture. Это создает временную копию cross-gdb, которую можно использовать для отладки. Этот решение наиболее быстрое, но два предыдущих более эффективны при продолжительном использовании отладчика. При запуске gdb-cross, система сборки OE предложит реальный образ (например, gdb-cross-i586).
  4. Установка debugfs, как показано ниже.
    $ mkdir debugfs
         $ cd debugfs
         $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2 $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2
  5. Установка GDB. Установите SDK (в случае его использования) и выполните сценарий настройки среды. Если применялась система сборки, GDB будет в каталоге build-dir/tmp/sysroots/host/usr/bin/architecture/architecture-gdb
  6. Загрузка целевой системы. В случае использования QEMU следует прочесть документацию QEMU. Проверьте доступ хоста к целевой системе по протоколу TCP.
  7. Отладка программы включает запуск gdbserver на целевой системе и GDB на хосте отладки. В приведенном ниже примере отлаживается пакет gzip
         root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help

    Опции gdbserver описаны в документации GDB Server. После запуска gdbserver нужно запустить GDB на хосте отладки и настроить для отладчика соединение с целевой системой, как показано ниже.

    $ cd directory-holding-the-debugfs-directory $ arch-gdb (gdb) set sysroot debugfs (gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug (gdb) target remote IP-of-target:1234

    После этого все остальное должно загружаться автоматически (двоичные файлы, символы и заголовки). Команда GDB set в примере может быть включена в пользовательский файл ~/.gdbinit и при запуске GDB будут выполнены остальные команды из файла.

  8. Развертывание без пересборки образа. Во многих случаях при отладке может потребоваться быстрое развертывание нового двоичного файла в целевой системе без пересборки образа целиком. Одним из вариантов решения этой задачи является просто сборка нужной компоненты и копирование файлов непосредственно в debugfs целевой системы и хоста отладки. Например,
    $ bitbake bash
         $ bitbake -c devshell bash
         $ cd ..
         $ scp packages-split/bash/bin/bash target:/bin/bash $ cp -a packages-split/bash-dbg/* path/debugfs

3.30.14. Отладка на целевой платформе с помощью GDB

В предыдущем параграфе описана удаленная отладка с помощью GDB, которая применяется чаще по причине аппаратных ограничений встраиваемых систем. Однако возможна отладка и непосредственно на целевой платформе для более мощных устройств, описанная ниже. Для реализации такой отладки нужно выполнить ряд действий.

  1. Установить GDB на целевой платформе, путем добавления в конфигурацию строки IMAGE_INSTALL_append = » gdb» или IMAGE_FEATURES_append = » tools-debug».
  2. Обеспечить наличие отладочных символов, например, с помощью строки IMAGE_INSTALL_append = » packagename-dbg» или IMAGE_FEATURES_append = » dbg-pkgs».

Для повышения точности отладочной информации можно снизить уровень оптимизации, используемый компилятором. Например, можно добавить в файл local.conf строку DEBUG_BUILD = «1», что снизит уровень оптимизации с FULL_OPTIMIZATION = «-O2» до DEBUG_OPTIMIZATION = «-O -fno-omit-frame-pointer». Это одновременно снизит производительность приложений, поэтому по завершении отладки следует восстановить оптимизацию.

3.30.15. Рекомендации по отладке

При добавлении пакетов нужно отслеживать появление нежелательных элементов в командах компилятора. Например, это могут быть ссылки на локальные файловые системы, такие как /usr/lib/ или /usr/include/. Если нужно исключить при загрузке заставку psplash, следует добавить psplash=false в командную строку ядра. Это позволит видеть консольный вывод. Можно также переключить виртуальную консоль (например, Fn+-> или Fn+<- на Zaurus).

Удаление TMPDIR (обычно tmp/ в каталоге сборки) часто решает временные проблемы сборки. Это не влечет значительных издержек, поскольку вывод задач кэшируется в SSTATE_DIR (обычно sstate-cache/ в каталоге сборки). Однако это может быть лишь обходом, а не решением проблемы. Поэтому неплохо поискать решение до удаления каталога.

Понимание практического применения свойства (функции) в задании очень важно, поэтому рекомендуется настроить тот или иной метод поиска в файлах. Например, можно использовать приведенную ниже shell-функцию на основе GNU Grep, которая выполняет рекурсивный поиск теста в связанных с заданиями файлах, пропуская двоичные файлы, каталоги .git и каталог сборки (в предположении, что его имя начинается с build).

     g() {
         grep -Ir \
  --exclude-dir=.git \
  --exclude-dir='build*' \
  --include='*.bb*' \
  --include='*.inc*' \
  --include='*.conf*' \
  --include='*.py*' \
  "$@"
     }

Ниже приведено несколько примеров использования функции.

     $ g FOO    # рекурсивный поиск FOO
     $ g -i foo # рекурсивный поиск  foo без учета регистра
     $ g -w FOO # рекурсивный поиск FOO как слова с игнорированием FOOBAR

Если поиск информации о работе функции требует слишком много времени, это может говорить о необходимости расширить или улучшить документацию. В таких случаях уместно сообщить об ошибке с использованием YP Bugzilla. Работа с этим ресурсом описана на странице YP Bugzilla wiki и в параграфе 3.31.1. Фиксация ошибок в YP. В руководствах может не быть описания переменных, которые являются сугубо внутренними и имеют ограниченную область действия (например, переменные, используемые внутри одного файла .bbclass).

3.31. Внесение изменений в YP

Поскольку YP является открытым проектом, разрабатываемым сообществом, каждый может предложить в проект свои изменения или дополнения. В этом разделе описаны процедуры информирования о дефектах и внесения правок.

3.31.1. Фиксация ошибок в YP

Для сообщений о дефектах (ошибках) YP служит ресурс YP Bugzilla, информацию о котором можно найти в разделе Yocto Project Bugzilla [3]. Описание работы с ресурсом имеется на странице YP Bugzilla wiki. Ниже кратко описаны этапы информирования об ошибках.

  1. Открыть страницу YP Bugzilla.
  2. Выбрать ссылку File a Bug для ввода информации об ошибке.
  3. Выбрать подходящие варианты Classification, Product и Component для информации об ошибке. Ошибки YP делятся на несколько категорий, включающих разную продукцию и компоненты. Например, для ошибки на уровне meta-intel следует выбрать Build System, Metadata & Runtime, BSPs и bsps-meta-intel.
  4. Выбрать Version для YP в соответствии с версией, где найдена ошибка (например, 2.7.1).
  5. Определить и выбрать важность (Severity) ошибки.
  6. Выбрать оборудование (Hardware), с которым связана ошибка.
  7. Выбрать архитектуру (Architecture), с которой связана ошибка.
  8. Выбрать пункт изменения документации (Documentation change) для ошибки. Если влияние ошибки на документацию не понятно, следует выбрать Don’t Know.
  9. Представить краткое описание (Summary) ошибки в одну или две строки.
  10. Представить подробное описание ошибки (Description), указав детали контекста, поведение, вывод и т. п. Здесь можно присоединить файлы с информацией, используя кнопку Add an attachment.
  11. Нажать кнопку Submit Bug для фиксации сообщения, которому будет присвоен номер Bugzilla, а информация будет сохранена в системе отслеживания ошибок.

Полученные сообщения обрабатывает команда YP Bug Triage Team, присваивая ему дополнительные атрибуты (например, приоритет). Вы будете считаться «подателем» (Submitter) сообщения при всех последующих контактах. Bugzilla автоматически будет уведомлять по электронной почте о всех событиях, связанных с обработкой сообщения.

3.31.2. Представление изменений в YP

Приветствуется вклад в YP и OE. Поскольку система является настраиваемой и гибкой, очевидно, что разработчики захотят настроить и оптимизировать ее для своих задач.

YP использует списки рассылки и рабочий процесс на основе исправления (patch), похожие на процессы для ядра Linux, но с существенными отличиями. Имеются специальные списки рассылки для представления правок. Сообщения из этих списков просматриваются и обрабатываются сопровождающими и нужно выбрать список в соответствии с размещением кода, который вы хотите изменить. Каждая компонента (например, уровень) должна включать файл README, указывающий, куда направить изменения и как их следует обрабатывать.

Можно отправить исправления в список рассылки, используя удобный способ создания patch-файлов. После отправки исправлений они обычно рассматриваются сообществом в целом и при обнаружении каких-либо проблем они указываются. Если исправления не создают негативных последствий, сопровождающий обычно принимает исправление, проверяет его и после успешного тестирования добавляет в код.

Репозиторий poky, являющийся эталонной средой сборки YP, является гибридным и состоит из нескольких частей (BitBake, Metadata, документация и т. п.), созданных с помощью инструмента combo-layer. Отправка изменений зависит от компонент, как указано ниже.

  • Core Metadata. Отправляйте правки в список рассылки openembedded-core. Например, в этот список следует отправлять исправления для каталогов meta или scripts.
  • BitBake. Отправляйте правки в список рассылки bitbake-devel.
  • meta-*. Отправляйте правки в список рассылки poky.

Для изменений на других уровнях репозитория YP (yoctoproject.org), в инструментах и документации YP следует направлять правки в рассылку YP. Иногда конкретный список указан в документации уровня и следует применять его.

Для дополнительных заданий, не вписывающихся в основные метаданные, следует определить уровень, к которому относится задание, и представить правки в соответствии с документацией этого уровня (например, README). При наличии сомнений можно задать вопрос в общей рассылке Yocto или openembedded-devel.

Можно также отправить изменения в восходящий репозиторий и попросить сопровождающего внести их. Эти процедуры описаны в разделе Git Workflows and the Yocto Project [1].

В OpenEmbedded-Core имеется два тестовых репозитория:

  • ветвь «ross/mut» дерево mut (master-under-test) в репозитории poky-contrib источников YP;
  • ветвь «master-next» branch является частью основного репозитория poky в репозитории источников YP.

Сопровождающие используют эти ветви для тестирования предложений перед включением правок. Включение правки в одну из этих ветвей позволяет получить представление о состоянии предложенных правок.

Эта система несовершенна и изменения могут иногда теряться в общем потоке. Запрос о статусе исправления или изменения является вполне уместным, если на предложение не было отклика. В YP планируется использование Patchwork для отслеживания статуса правок и автоматического предварительного просмотра.

3.31.2.1. Использование сценариев для представления изменений

Описанная здесь процедура служит для внесения изменений в восходящий репозиторий Git «contrib». Базовая информация о работе с репозиториями представлена в Git Community Book.

  1. Внесите изменения локально в свой репозиторий Git. Изменения следует делать компактными, контролируемыми и изолированными. Компактность и изолированность изменений упрощает их просмотр, слияние и перебазирование, а также позволяет сохранять историю изменений.
  2. Добавьте свои изменения с помощью команды git add для каждого измененного файла.
  3. Зафиксируйте изменения с помощью команды git commit. Данные фиксации должны соответствовать стандартным соглашениям, приведенным ниже.Обязательно включите строку «Signed-off-by:», как это требуется для ядра Linux. Добавление строки означает, что податель согласен с Developer’s Certificate of Origin 1.1, текст которого приведен ниже.Сертификат происхождения для разработчика, версия 1.1Внося свой вклад в проект, я подтверждаю указанное ниже.
      1. Вклад полностью или частично создан мной и я имею право представить его в соответствии с лицензией для открытого кода, указанной в файле.
      2. Или вклад основан на предыдущей работе, которая, насколько мне известно, покрывается подходящей лицензией для открытого кода и я имею право в соответствии с этой лицензией представить эту работу с изменениями, независимо от того, созданы ли они полностью мной, на условиях той же лицензии (если мне не разрешено применять иную лицензию), которая указана в файле.
      3. Вклад был предоставлен мне напрямую другим лицом, которое подтвердило пп. (a), (b) или (c), и я не менял его.
      4. Я понимаю и согласен с тем, что этот проект и вклад являются общедоступными и запись вклада (включая все предоставленные мной персональные данные) хранится в течение неопределенного времени и может распространяться в соответствии с этим проектом и лицензиями для открытого кода.

Представьте краткое описание изменений в 1 строку (если требуется более полное описание, его следует включить в тело сообщения). Краткое описание обычно выводится в коротком списке изменений. Если изменения относятся к заданию, следует указать имя задания в качестве префикса краткого описания. В остальных случаях следует указывать в качестве префикса сокращенный путь к измененному файлу.

В теле сообщения следует указать более подробные сведения, описывающие суть изменений, их причины и использованный подход. Полезно также привести данные о тестировании правок.

Если изменение связано с конкретной ошибкой, для которой уже имеется идентификатор отслеживания (bug-tracking ID), следует включить этот идентификатор в подробное описание. Например, в YP применяется соглашение для указания ошибок и фиксациям с устранением конкретной ошибки следует использовать в начале подробного описания строку Fixes [YOCTO #bug-id].

  1. Поместите свои фиксации в репозиторий Contrib, если у вас есть право записи в него.
    $ git push upstream_remote_repo local_branch_name

    Предположим, что у вас есть право добавления в восходящий репозиторий meta-intel-contrib и вы работаете с локальной ветвью your_name/README. Команда git push meta-intel-contrib your_name/README поместит выши локальные фиксации в в репозиторий meta-intel-contrib (ветвь your_name/README).

  2. Определить, кого следует уведомить. Это может быть сопровождающий или список рассылки, определенный одним из указанных ниже способов.
    1. Файл сопровождения maintainers.inc в каталоге meta/conf/distro/include дерева исходных кодов.
    2. Поиск по файлам с помощью команды git shortlog — filename, выводящей список фиксаций для указанного файла. Список не упорядочен, но включает всех, кто представлял фиксации.
    3. Просмотр списков рассылки YP и др., перечисленных в разделе Mailing lists [3].
  3. Сделайте запрос на извлечение. Сообщите сопровождающему или в список рассылки сообщение об отправке изменений, передав запрос на извлечение.YP включает два сценария для создания и отправки запросов — create-pull-request и send-pull-request. Эти сценарии хранятся в каталоге scripts дерева исходных кодов (например, ~/poky/scripts). Сценарии корректно формируют запросы без добавления пробелов и тегов HTML. Сопровождающему, который получит запрос напрямую или через список рассылки, сможет сохранить и применить изменения непосредственно из почтового сообщения. Такой метод отправки является предпочтительным.Сначала создается запрос на извлечение. Например, команда ~/poky/scripts/create-pull-request -u meta-intel-contrib -s «Updated Manual Section Reference in README» запускает сценарий, указывает каталог восходящего репозитория для записи изменений (contrib) и задает строку темы в создаваемых patch-файлах. Запуск сценария создает файлы правок *.patch в каталоге pull-PID внутри текущего каталога. Одним из файлов является сопроводительное письмо.Перед использованием сценария send-pull-request нужно отредактировать сопроводительное письмо, указав сведения об изменениях. Затем можно отправить запрос на извлечение. Например, команда ~/poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org запускает сценарий и указывает каталог исправления и адрес электронной почты для отправки. Сценарий является интерактивным и нужно следовать выводимым на экран инструкциям.

    Справка об использовании сценариев выводится при указании опции -h.

         $ poky/scripts/create-pull-request -h
         $ poky/scripts/send-pull-request -h
3.31.2.2. Использование электронной почты для представления изменений

Можно представлять изменения с помощью электронной почты, отправляя их в соответствующий список рассылки (см. раздел Mailing Lists [3]), как описано ниже.

  1. Внесите изменения локально в свой репозиторий Git. Изменения следует делать компактными, контролируемыми и изолированными. Компактность и изолированность изменений упрощает их просмотр, слияние и перебазирование, а также позволяет сохранять историю изменений.
  2. Добавьте свои изменения с помощью команды git add для каждого измененного файла.
  3. Зафиксируйте изменения с помощью команды git commit —signoff. Опция —signoff указывает, что изменения внесены вами и подтверждает DCO3, как описано выше. Данные фиксации должны соответствовать стандартным соглашениям, описанным в п. 3 предыдущего параграфа.
  4. Формат представлениясообщение электронной почты, создаваемое с помощью команды git format-patch. При вызове команды нужно указать список выпусков или число правок (patch). Например, любая из команда git format-patch -1 и git format-patch HEAD~ берет последнюю одиночную фиксацию (commit) и форматирует ее как почтовое сообщение в текущем каталоге. После выполнения команды в текущем каталоге будут созданы нумерованные файлы .patch для представления. При наличии нескольких patch-файлов следует указывать в команде опцию —cover, которая создает сопроводительное письмо, как первый patch-файл серии. Это письмо затем можно отредактировать для описания серии правок. Информация о команде git format-patch выводится по команде man git-format-patch. Если предполагается частое представление правок для IYP или OE, можно запросить область contrib и связанные с этим права.
  5. Импорт файлов в почтовый клиент с помощью команды git send-email. Для этого на хосте должна быть установлен и должным образом настроен соответствующий пакет Git Ubuntu, Debian и Fedora это git-email). Команда git send-email передает сообщение с использованием локального или удаленного агента MTA4, такого как msmtp, sendmail, или через прямую настройку в конфигурационном файле Git ~/.gitconfig. Если правки представляются только по электронной почте, важно отправлять их без пробелов и тегов HTML. Сопровождающему, который получит сообщение нужно его сохранить и применить прямо из почты. Хорошим способом проверки корректности сообщения служит отправка его по своему адресу для тестового сохранения и применения. Команда git send-email является предпочтительным методом отправки patch-файлов по электронной почте, поскольку нет риска появления в сообщении ненужных пробелов, которые могут вносить почтовые клиенты. Команда имеет опции для указания получателей и дополнительного редактирования сообщения. Сведения об опциях можно получить с помощью команды man git-send-email.

3.32. Работа с лицензиями

Как отмечено в разделе Licensing [1], проекты с открытым кодом доступны для всех и могут использовать разные лицензии. Здесь описаны механизмы, используемые системой сборки OE для отслеживания изменений в текстах лицензий, и поддержка лицензирования открытого кода в течение жизненного цикла проекта. Рассмотрено также использование в заданиях коммерческих лицензий, которое по умолчанию отключено.

3.32.1. Отслеживание изменений в лицензиях

Лицензия восходящего проекта может с течением времени измениться. Для того, чтобы такие изменения не осталибс незаметными, переменная LIC_FILES_CHKSUM отслеживает изменения в тексте лицензии. Контрольная сумма проверяется в конце настройки конфигурации и сборка прерывается при несоответствии контрольной суммы.

3.32.1.1. Указание переменной LIC_FILES_CHKSUM

Переменная LIC_FILES_CHKSUM содержит контрольные суммы текста лицензий в исходном коде задания.

     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
 file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
 file://licfile2.txt;endline=50;md5=zzzz \
 ..."
  • При использовании beginline и endline следует учитывать, что нумерация строк начинается с 1, а не с 0. Начальная и конечная строка учитываются в контрольной сумме, т. е. в примере будут учитываться строки 1 — 29 в файле licfile1.txt и 1 — 50 в файле licfile2.txt.
  • При несоответствии контрольной суммы указанная часть текста лицензии включается в сообщение QA, что позволяет проверить начало и конец учитываемого текста.

Система сборки использует переменную S в качестве принятого по умолчанию каталога при поиске файлов из LIC_FILES_CHKSUM. В примере используются файлы текущего каталога. Рассмотрим еще один пример.

     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
     md5=bb14ed3c4cda583abc85401304b5cd4e"
     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"

Первая строка указывает файл ${S}/src/ls.c с учетом строк 5 — 16, вторая указывает файл в WORKDIR. Переменная LIC_FILES_CHKSUM обязательная для всех заданий, где не установлено LICENSE = «CLOSED».

3.32.1.2. Разъяснение синтаксиса

Как отмечено выше, в переменной LIC_FILES_CHKSUM указаны все важные файлы, содержащие текст лицензий для исходного кода. Можно задать контрольную сумму файла целиком или его части, указанной первой и последней учитываемой строкой (полезно для документов, включающих заголовок, файлов README и т. п.). Если параметр beginline или endline опущен, предполагается учет с первой или до последней строки, соответственно.

Параметр md5 указывает сохраненное значение контрольной суммы md5. Если контрольная сумма отличается от этого значения, лицензия считается измененной. Если различие обнаруживается при сборке, полученная контрольная сумма md5 помещается в журнал сборки и ее можно потом скопировать в задание.

Число файлов, включаемых в LIC_FILES_CHKSUM не ограничивается, однако на практике обычно нужно указывать лишь несколько файлов. Во многих проектах имеется файл COPYING, в котором хранятся сведения о лицензиях для всех файлов исходного кода. Это позволяет отслеживать лишь файл COPYING.

  • Если задан пустой или недействительный параметр md5, BitBake возвращает ошибку md5 mis-match и выводит корректное значение параметра в процессе сборки, записывая его также в журнал сборки.
  • Если файл содержит лишь текст лицензии, параметры beginline и endline не нужны.

3.32.2. Включение заданий с коммерческими лицензиями

По умолчанию система сборки OE исключает компоненты с коммерческими и иными специальными лицензиями. Это требование определяется на уровне заданий в переменной LICENSE_FLAGS. Например, задание poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly содержит LICENSE_FLAGS = «commercial». Имеется более сложный пример, содержащий явное имя и версию задания (после преобразования переменной).

     LICENSE_FLAGS = "license_${PN}_${PV}"

Для включения в образ компоненты, ограниченной определением LICENSE_FLAGS, нужно добавить соответствующую запись в переменную LICENSE_FLAGS_WHITELIST, которая обычно задается в файле local.conf. Например, для включения пакета poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly можно добавить строку commercial_gst-plugins-ugly или более общий вариант commercial в переменную LICENSE_FLAGS_WHITELIST. Полное описание работы переменной приведено в параграфе 3.32.2.1. Соответствие флагов лицензий.

Для дополнительного включения пакета, собранного из задания с LICENSE_FLAGS = «license_${PN}_${PV}», в предположении, что файл задания называется emgd_1.10.bb в следующем примере добавлено license_emgd_1.10.

     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"

Не требуется указывать полную строку лицензии в списке разрешений и можно применять сокращенную форму, которая состоит из первой части строки лицензии до первого символа _. Сокращенная строка будет соответствовать любой лицензии, содержащей эту подстроку. Например, LICENSE_FLAGS_WHITELIST = «commercial license» будет соответствовать обоим пакетам, упомянутым выше, а также все прочим пакетам с лицензией, начинающейся с commercial или license.

3.32.2.1. Соответствие флагов лицензий

Соответствие флагов лицензий позволяет контролировать задания, включаемый в сборку системой OE. По сути система сборки пытается сопоставить строки LICENSE_FLAGS из заданий со строками LICENSE_FLAGS_WHITELIST и при совпадении включает задание в сборку, а при различии исключает. Сопоставление флагов в общем случае просто, однако понимание некоторых нюансов облегчит его использование.

Перед сравнением флага, определенного конкретным заданием, с содержимым разрешенного списка к этому флагу добавляется преобразованная переменная _${PN}. Преобразование делает каждое значение LICENSE_FLAGS зависящим от задания. Например, указание LICENSE_FLAGS = «commercial» в задании foo ведет к строке commercial_foo. Соответствующая строка сравнивается со списком разрешений.

Разумное применение строк LICENSE_FLAGS и содержимого LICENSE_FLAGS_WHITELIST обеспечивает гибкость включения и исключения заданий на основе лицензии. Например, можно расширить сопоставление использованием подстрок флагов лицензий. В этом случае нужно применять ту часть преобразованной строки, которая предшествует добавленному символу _ (например usethispart для usethispart_1.3, usethispart_1.4 и т. п.).

Например, простое указание строки commercial в списке разрешений, будет соответствовать любому преобразованному определению LICENSE_FLAGS, начинающемуся с commercial (commercial_foo, commercial_bar), которое автоматически создается системой сборки для гипотетических заданий foo и bar в предположении, что эти задания включают LICENSE_FLAGS = «commercial».

Таким образом можно задать исчерпывающий список флагов лицензий в списке разрешений и разрешить использование в образе только определенных заданий или использовать подстроки для расширения совпадений, чтобы разрешить включение более широкого спектра заданий. Эта схема работает даже в тех случаях, когда к строке LICENSE_FLAGS уже добавлен суффикс _${PN}. Например, система сборки преобразует флаг лицензии commercial_1.2_foo в commercial_1.2_foo_foo и задание будет соответствовать в списке разрешений строкам commercial и commercial_1.2_foo.

Ниже приведены несколько других вариантов.

  • Можно указать в задании foo строку с версией, такую как commercial_foo_1.2. Система сборки преобразует эту строку в commercial_foo_1.2_foo. Комбинация этого флага со списком разрешений, включающим commercial, обеспечит совпадение как и для любого другого флага, начинающегося со строки commercial.
  • В некоторый случаях можно использовать commercial_foo в списке разрешений совпадать будет не только commercial_foo_1.2, но и любой флаг, начинающийся с commercial_foo, независимо от версии.
  • Можно задать в списке разрешений пакет и версию (например, commercial_foo_1.2) для точного совпадения.
3.32.2.2. Другие варианты, связанные с коммерческими лицензиями

Другие полезные переменные для работы с коммерческими лицензиями определены в файле poky/meta/conf/distro/include/default-distrovars.inc.

     COMMERCIAL_AUDIO_PLUGINS ?= ""
     COMMERCIAL_VIDEO_PLUGINS ?= ""

Для включения этих компонент можно указать в файле local.conf строки вида

     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
        gst-plugins-ugly-mpegaudioparse"
     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"

Можно конечно создать для этих компонент список разрешений LICENSE_FLAGS_WHITELIST = «commercial», но он включит и другие пакеты, где LICENSE_FLAGS содержит commercial, что может оказаться нежелательным. Указание подключаемых модулей в операторах COMMERCIAL_AUDIO_PLUGINS и COMMERCIAL_VIDEO_PLUGINS (вместе с разрешением LICENSE_FLAGS_WHITELIST) включает плагины или компоненты в сборку образа.

3.32.3. Поддержка соответствия лицензиям в жизненном цикле проекта

Одной из задач разработки программ с открытым кодом является обеспечение соответствия требованиям лицензий для открытого кода в течение жизненного цикла программы. В этом разделе нет юридических консультаций и не рассматриваются все варианты, но описаны некоторые методы, которые позволят обеспечить соответствие требованиям при выпуске программ.

Среди сотен разных лицензий, отслеживаемых YP, сложно знать требования каждой из них. Однако требования основных лицензий FLOSS могут выполняться, если соблюдаются три главных условия:

  • предоставлен исходный код программы;
  • предоставлен текст лицензии для программы;
  • предоставлены сценарии компиляции и изменения исходного кода.

Имеются и другие требования, а также методы, описанные здесь (например, механизм распространения исходного кода). Поскольку в разных организациях применяются различные методы соблюдения лицензий, здесь не описывается универсальный способ выполнить требования, а рассматриваются методы обеспечения соответствия путем выполнения трех приведенных выше условий. После их соблюдения перед выпуском образа, исходных кодов или системы сборки следует проверить полноту всех компонент. В процессе сборки образа YP создает манифест лицензий, размещаемый в каталоге ${DEPLOY_DIR}/licenses/image_name-datestamp, который поможет при проверке.

3.32.3.1. Предоставление исходного кода

Работа по обеспечению соответствия должна начинаться до создания финального образа. Первым делом нужно обратить внимание на предоставление исходного кода. YP обеспечивает несколько способов решения этой задачи.

Одним из простейших способов является предоставление всего каталога DL_DIR, используемого для сборки. Однако этот метод имеет ряд недостатков и прежде всего размер, поскольку каталог включает все исходные коды, используемые при сборке, а не только код выпускаемого образа. В каталоге размещены исходные коды инструментария, который обычно не включается в образ. Но более серьезной проблемой может стать непредусмотренный выпуск кода фирменных программ. Для устранения проблемы YP поддерживает класс archiver.

Прежде чем использовать DL_DIR или класс archiver, нужно решить вопрос о способе представления кода. Класс archiver может создавать архивы и SRPM с разными уровнями соответствия. Один из способов заключается просто в выпуске архива (tarball) исходного кода. Это можно сделать, добавив в файл local.conf каталога сборки строки вида

     INHERIT += "archiver"
     ARCHIVER_MODE[src] = "original"

В процессе создания образа исходный код всех включенных в образ заданий помещается в каталоги DEPLOY_DIR/sources на основе переменной LICENSE для каждого задания. Выпуск каталога целиком позволяет выполнить требования по предоставлению исходного кода без изменений. Важно отметить, что размер каталога может оказаться большим. Решением проблемы размера может быть выпуск лишь архивов, для которых лицензия требует предоставление кода. Предположим, что нужен лишь код GPL, определяемый приведенным ниже сценарием.

     # Сценарий для архивирования пакетов с определенными требованиями лицензий
     # Файлы исходного кода и лицензий копируются в каталоги пакетов
     # Сценарий нужно запускать из каталога сборки (build)
     #!/bin/bash
     src_release_dir="source-release"
     mkdir -p $src_release_dir
     for a in tmp/deploy/sources/*; do
        for d in $a/*; do
           # Get package name from path
           p=`basename $d`
           p=${p%-*}
           p=${p%-*}
           # Архивировать только пакеты GPL (измените *GPL* для других лицензий)
           numfiles=`ls tmp/deploy/licenses/$p/*GPL* 2> /dev/null | wc -l`
           if [ $numfiles -gt 1 ]; then
  		echo Archiving $p
  		mkdir -p $src_release_dir/$p/source
  		cp $d/* $src_release_dir/$p/source 2> /dev/null
  		mkdir -p $src_release_dir/$p/license
  		cp tmp/deploy/licenses/$p/* $src_release_dir/$p/license 2> /dev/null
           fi
        done
     done

На этом этапе можно создать архив из каталога gpl_source_release и предоставить его пользователям. Этот метод является этапом соблюдения разделов 3a в GPLv2 и 6 в GPLv3.

3.32.3.2. Предоставление текста лицензий

Одним из требований, которое часто игнорируют, является включение текста лицензии. Это требование тоже нужно выполнить до создания финального образа. Некоторые лицензии требуют предоставлять их текст вместе с двоичными файлами. Это можно сделать, добавив в файл local.conf строки вида

     COPY_LIC_MANIFEST = "1"
     COPY_LIC_DIRS = "1"
     LICENSE_CREATE_PACKAGE = "1"

В результате тексты лицензий в процессе сборки будут включены в образ. Установка значения 1 для всех трех переменных приводит к наличию двух копий файла лицензии (в /usr/share/common-licenses и /usr/share/license). Это обусловлено тем, что переменные COPY_LIC_DIRS и COPY_LIC_MANIFEST добавляют копию лицензии при сборке образа, но не предлагают путь добавления лицензий для недавно установленных в образ пакетов. Переменная LICENSE_CREATE_PACKAGE добавляет отдельный пакет и путь обновления при добавлении лицензий в образ.

Поскольку класс archiver уже заархивировал исходный код без изменений, содержащий файлы лицензий, требования по представлению лицензии с исходным кодом, заданные GPL и другими лицензиями для открытого кода, выполнены.

3.32.3.3. Предоставление сценариев компиляции и изменений исходного кода

После выполнения рекомендаций предыдущих параграфов можно собирать образ. Выпуск версии системы сборки OE и использованных при сборке уровней выполняет сразу требования к сценариям компиляции и изменениям кода.

При наличии уровней BSP и дистрибутива эти уровни используются для правки, компиляции, упаковки или изменения (если оно имеется) всех программ с открытым кодом, включенных в образ, может потребоваться выпуск этих уровней в соответствии с разделом 3 лицензии GPLv2 или разделом 1 лицензии GPLv3. Одним из способов решения задачи является явный выбор версии YP и уровней, используемых при сборке. Например,

     # Сборка с использованием ветви warrior репозитория poky
     $ git clone -b warrior git://git.yoctoproject.org/poky
     $ cd poky
     # Сборка с использованием release_branch для уровней
     $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
     $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
     # Очистка репозиториев .git
     $ find . -name ".git" -type d -exec rm -rf {} \;

Для удобства конечных пользователей разработчики могут рассмотреть изменение файла meta-poky/conf/bblayers.conf.sample, чтобы обеспечить автоматическое включение созданных организацией уровнем уровней при использовании выпущенной системы сборки для создания образа, как показано ниже.

     # POKY_BBLAYERS_CONF_VERSION каждый раз увеличивается в build/conf/bblayers.conf
     # changes incompatibly
     POKY_BBLAYERS_CONF_VERSION = "2"

     BBPATH = "${TOPDIR}"
     BBFILES ?= ""

     BBLAYERS ?= " \
       ##OEROOT##/meta \
       ##OEROOT##/meta-poky \
       ##OEROOT##/meta-yocto-bsp \
       ##OEROOT##/meta-mylayer \
       "

Создание и предоставление архива метаданных уровней (задания, файлы конфигурации и т. п.) обеспечивает соблюдение требований по включению сценариев управления компиляцией и всех изменений оригинального кода.

3.32.4. Копирование отсутствующих лицензий

Некоторые пакеты (например, linux-firmware) могут иметь лицензии, которые мало распространены. Можно избежать применения множества лицензий общего назначения, применимых лишь к определенным пакетам, путем использования переменной NO_GENERIC_LICENSE. Это также позволяет избежать ошибок QA при использовании в задании необычной, но и не закрытой лицензии. Ниже приведен пример использования файла LICENSE.Abilis.txt в качестве лицензии для извлеченного исходного кода.

     NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"

3.33. Использование инструмента отчетов об ошибках

Инструмент отчетов об ошибках позволяет представлять ошибки, возникшие в процессе сборки, в центральную базу данных. Извне системы сборки можно использовать web-интерфейс базы для поиска и просмотра ошибок, а также статистики. Инструмент использует модель «клиент-сервер» с реализацией клиентской части в дереве исходных кодов YP (например, poky). Сервер получает данные от клиента и записывает их в базу.

Действующий сервер отчетов об ошибках доступен по ссылке http://errors.yoctoproject.org. Этот сервер организован для того, чтобы можно было получить помощь при возникновении ошибок и предоставить полную информацию об ошибке, а затем указать ссылку на нее (URL) и отправить сообщение в список рассылки. Отправленные на сервер отчеты доступны для всех.

3.33.1. Включение отчетов

По умолчанию инструмент отчетов об ошибках отключен и для его включения нужно наследовать класс report-error, добавив в конце файла local.conf в каталоге сборки строку INHERIT += «report-error». Данные отчетов по умолчанию записываются в файл ${LOG_DIR}/error-report, однако можно задать другое место хранения командой вида ERR_REPORT_DIR = «path».

Включение отчетов об ошибках заставляет систему сборки фиксировать все сообщения и записывать их в указанный файл. При возникновении ошибки система сборки включает в консольный вывод команду для отправки файла с информацией на сервер. Например, для передачи информации на восходящий сервер может служить команда $ send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt, которая отправит информацию в общедоступную базу данных на сервере http://errors.yoctoproject.org. При указании конкретного сервера сведения можно отправить в другую базу данных. Информация о работе с инструментом доступна по команде send-error-report —help.

При отправке файла выводится приглашение на просмотр передаваемых данных, а также указание имени и (необязательного) почтового адреса. После ввода информации команда возвращает идентификатор переданных сведений на сервере, например, http://errors.yoctoproject.org/Errors/Details/9522/, который можно использовать для последующей работы с этой ошибкой.

3.33.2. Отключение отчетов

Для отключения отчетов об ошибках следует указать в конце файла local.conf строку INHERIT += «report-error».

3.33.3. Установка своего сервера отчетов об ошибках

При желании можно установить свой сервер отчетов об ошибках, загрузив его код из репозитория Git http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/. Установка сервера описана в файле README.

3.34. Использование Wayland и Weston

Waylandпротокол сервера отображения, обеспечивающий менеджерам окон возможность прямого взаимодействия с приложениями и видеосистемой при использовании других библиотек. Использование Wayland с поддерживающими протокол платформами может обеспечить лучшее управления разбором графических кадров.

YP включает библиотеки протокола Wayland и эталонный сборщик Weston, размещая их в дереве источников. В частности, задания для Wayland и Weston находятся в каталоге meta/recipes-graphics/wayland. Можно собрать пакеты Wayland и Weston для использования с платформами, принимающими инфраструктуру Mesa 3D и Direct Rendering (Mesa DRI). Это означает, что вы не сможете собрать и использовать пакеты, если ваша платформа поддерживает, например, Intel® Embedded Media и Graphics Driver (Intel® EMGD), которые переопределяют Mesa DRI.

По причине отсутствия поддержки EGL пакет Weston 1.0.3 не работает напрямую на эмулируемом в QEMU оборудовании. Однако эта версия Weston без проблем работает с X=эмуляцией.

3.34.1. Включение Wayland в образе

Для включения Wayland нужно добавить его в сборку и установить в образ.

3.34.1.1. Сборка

Чтобы заставить Mesa собрать платформу wayland-egl, а Weston — собрать Wayland с поддержкой KMS5, нужно добавить флаг wayland в оператор DISTRO_FEATURES в файле local.conf в форме DISTRO_FEATURES_append = » wayland». Если где-нибудь включена поддержка X11, Weston будет собирать Wayland с поддержкой X11.

3.34.1.2. Установка

Для установки Wayland в образ нужно включить в файл local.conf оператор CORE_IMAGE_EXTRA_INSTALL += «wayland weston».

3.34.2. Запуск Weston

Для запуска Weston в среде X11 нужно включить пакет, как описано выше и собрать образ Sato. В этом случае Weston Launcher помещается в категорию Utility.

Можно запустить Weston из командной строки, что зачастую удобней в среде разработки. Для этого следует выполнить указанные ниже действия.

  1. Ввести для экспорта XDG_RUNTIME_DIR команды
         mkdir -p /tmp/$USER-weston
         chmod 0700 /tmp/$USER-weston
         export XDG_RUNTIME_DIR=/tmp/$USER-weston
  2. Запустить Weston из оболочки командой weston.

Глава 4. Использование QEMU

YP использует открытую реализацию эмулятора QEMU6 как часть инструментария. В этой главе рассмотрена работа с эмулятором и его применение в разработке.

4.1. Обзор

В контексте YP эмулятор и машина виртуализации QEMU позволяет запускать полные образы, собранные в YP, как задачи системы сборки. Эмулятор QEMU полезен для запуска и тестирования образов и приложений для поддерживаемой YP архитектуры без реального оборудования. YP также использует QEMU для запуска автоматизированных тестов QA на финальных образах, включаемых в каждый выпуск. Реализация эмулятора несколько отличается от обычного QEMU и здесь приведен ее краткий обзор. Официальная информация доступна на сайте QEMU и в руководстве пользователя.

4.2. Запуск QEMU

Для использования QEMU нужно установить и инициализировать эмулятор, а также иметь нужные для работы элементы (образы и файловые системы). Ниже описаны этапы подготовки к работе с QEMU.

  1. Установка QEMU. Эмулятор можно сделать доступным в YP разными способами, одним из которых является установка SDK (см. раздел The QEMU Emulator [2]).
  2. Настройка среды.
    • При выборе репозитория poky с загрузкой и распаковкой архива YP можно организовать среду сборки приведенными ниже командами.
           $ cd ~/poky
           $ source oe-init-build-env    
    • При установке кросс-инструментов можно запустить сценарий их инициализации. Например, приведенная ниже команда запускает сценарий из принятого по умолчанию каталога poky_sdk.
           . ~/poky_sdk/environment-setup-core2-64-poky-linux
  3. Проверка наличия нужных элементов. Нужно убедиться в наличии собранного ядра, которое будет загружаться в QEMU, а также корневой файловой системы для целевой машины и архитектуры.
    • Если был собран образ для QEMU (qemux86, qemuarm и т. п.), его элементы будут находиться в каталоге сборки.
    • Если образа еще нет, нужно зайти на страницу machines/qemu и загрузить готовый образ для целевой машины и архитектуры.

    Извлечение корневой файловой системы описано в разделе Extracting the Root Filesystem [2].

  4. Запуск QEMU командой вида $ runqemu [option ] […]. В соответствии с введенной командой runqemu выполнит заданные действия. Например, по умолчанию QEMU ищет собранный последним образ по временной метке. В параметрах нужно указать по меньшей мере машину, образ виртуальной машины (*wic.vmdk) или образ ядра (*.bin). Ниже приведено несколько примеров запуска QEMU:
    • Запуск QEMU с MACHINE = «qemux86». В предположении стандартного каталога сборки runqemu автоматически найдет образ bzImage-qemux86.bin и файловую систему core-image-minimal-qemux86-20140707074611.rootfs.ext3 (для образа core-image-minimal). При наличии нескольких образов с одним именем, QEMU использует более свежий.
           $ runqemu qemux86
    • Похож на предыдущий пример, но явно указывается образ и тип корневой файловой системы.
           $ runqemu qemux86 core-image-minimal ext3
    • Загрузка образа initramfs для включения звука в QEMU. В этом случае runqemu устанавливает внутреннюю переменную FSTYPE = «cpio.gz». Для включения звука должен быть установлен подходящий драйвер.
           $ runqemu qemux86 ramfs audio
    • В этом примере не представлено информации, достаточной для запуска QEMU. Хотя корневая файловая система задана, нужно еще указать хотя бы MACHINE, KERNEL или VM.
           $ runqemu ext3
    • Этот пример задает загрузку образа виртуальной машины (файл .wic.vmdk). Из .wic.vmdk программа runqemu определяет архитектуру QEMU (MACHINE) qemux86 и корневую файловую систему vmdk.
           $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk

4.3. Переключение консоли

При загрузке и работе QEMU можно переключаться между поддерживаемыми консолями с помощью клавиш Ctrl+Alt+цифра. Например, Ctrl+Alt+3 переключает на последовательную консоль, если она активна. Возможность переключения полезна, например, при нарушении по какой-либо причине работы основной консоли QEMU. Обычно 2 служит для переключения на основную консоль, 3 — на последовательную.

4.4. Удаление заставки

Можно удалить заставку при загрузке QEMU с помощью клавиш Alt+<-. Это позволяет увидеть фоновый вывод.

4.5. Запрет захвата курсора

Используемая по умолчанию интеграция QEMU захватывает курсор в главном окне. Это обусловлено тем, что стандартные мыши обеспечивают только относительные перемещения, а не абсолютные координаты. Можно отменит захват курсора с помощью клавиш Ctrl+Alt. Интеграция QEMU в YP поддерживает сенсорные панели wacom USB, которые обеспечивают абсолютные координаты, что позволяет курсору входит в главное окно и выходить из него без захвата, упрощая работу пользователя.

4.6. Запуск на сервере NFS

Одним из вариантов работы QEMU является запуск на сервере NFS. Это полезно в тех случаях, когда нужно обращаться к одной файловой системы с хоста сборки и эмулируемой системы. Следует отметить, что для запуска здесь не нужны полномочия root, поскольку применяется сервер NFS в пользовательском пространстве. Ниже описана процедура запуска QEMU с использованием сервера NFS.

  1. Извлечение корневой файловой системы. Когда все готово к запуску QEMU в среде, можно использовать сценарий runqemu-extract-sdk из каталога scripts. Сценарий runqemu-extract-sdk принимает архив корневой файловой системы и распаковывает его в указанное место. Например, команда runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs распаковывает файловую систему в каталог test-nfs.
  2. Запуск QEMU. После извлечения корневой файловой системы можно запустить runqemu, указав расположение файловой системы. При этом изменения, внесенные в каталог ./test-nfs будут видны при работе. Например, для работы с образом qemux86 служит команда runqemu qemux86 ./test-nfs.

Для запуска, остановки или перезапуска общего ресурса NFS служат приведенные ниже команды.

  • Запуск общего раздела NFS — runqemu-export-rootfs start file-system-location.
  • Остановка общего раздела NFS — runqemu-export-rootfs stop file-system-location.
  • Перезапуск общего раздела NFS — runqemu-export-rootfs restart file-system-location.

4.7. Совместимость QEMU с CPU при работе с KVM

По умолчанию сборка QEMU компилируется для 64-битовых и x86 Intel® Core™2 Duo процессоров, а также 32-битовых x86 Intel® Pentium® II. QEMU собирается для этих CPU по причини их совместимости с широким спектром менее распространенных CPU.

Однако, несмотря на широкую совместимость, эти процессоры могут использовать функции, не поддерживаемые процессором вашего хоста. Это не вызывает проблем при использовании в QEMU программной эмуляции функций, но проблемы могут возникать при работе QEMU со включенным KVM. В частности, программы, скомпилированные для некоторых CPU, не могут работать на CPU под управлением KVM без поддержки функции. Для решения проблемы можно переопределить настройку CPU в QEMU путем установки переменной QB_CPU_KVM в файле qemuboot.conf в каталоге deploy/image. Эта установка задает опцию -cpu, передаваемую QEMU в сценарии runqemu. Для просмотра списка поддерживаемых типов служит команда qemu -cpu.

4.8. Производительность QEMU

При использовании QEMU для эмуляции оборудования могут возникать проблемы производительности в зависимости от комбинации целевой системы и архитектуры. Например, работа образа qemux86 на 32-битовом хосте Intel x86 достаточно производительна в результате соответствия архитектуры целевой системы и хоста. При использовании образа qemuarm на том же хосте Intel производительность может упасть. Но специфические аспекты ARM будут эмулироваться достаточно точно.

Для ускорения работы образы QEMU поддерживают использование distcc для вызова кросс-компилятора вне эмулируемой системы. Если для запуска QEMU применяется runqemu и на хосте имеется приложение distccd, любой инструмент кросс-компиляции BitBake, доступный системе сборки, может автоматически использоваться из QEMU просто путем вызова distcc. Это можно сделать, определив переменную кросс-компилятора (например, export CC=»distcc»). При использовании подходящего образа SDK или автономного инструментария можно также применять эти инструменты.

Имеется несколько механизмов для подключения к системе, работающей на эмуляторе QEMU.

  • QEMU предоставляет интерфейс framebuffer, делающий доступными стандартные консоли.
  • Обычно устройства без монитора имеют стандартный последовательный порт. В этом случае можно настроить операционную систему работающего образа для использования последовательной консоли. Соединение использует стандартную сеть IP.
  • Для некоторых образов QEMU имеются серверы SSH. В образе core-image-sato QEMU сервер Dropbear (SSH) работает без доступа пользователя root. Образы core-image-full-cmdline и core-image-lsb используют OpenSSH вместо Dropbear. Эти серверы поддерживают стандартные команды ssh и scp. Однако в core-image-minimal сервера SSH нет.
  • Можно использовать сервер NFS в пользовательском пространстве для загрузки сессии QEMU с использованием локальной копии корневой файловой системы на хосте. Для организации соединения нужно распаковать архив корневой файловой системы с помощью команды runqemu-extract-sdk, а после этого указать сценарию runqemu распакованный каталог вместо образа коревой файловой системы (см. раздел 4.6. Запуск на сервере NFS).

4.9. Синтаксис командной строки QEMU

Базовый синтаксис команды runqemu имеет форму runqemu [option ] […]. В соответствии с введенной командой runqemu выполнит заданные действия. Например, по умолчанию QEMU ищет собранный последним образ по временной метке. В параметрах нужно указать по меньшей мере машину, образ виртуальной машины (*wic.vmdk) или образ ядра (*.bin). Ниже приведен вывод команды с опцией —help, описывающий команды runqemu.

     $ runqemu --help

     Usage: you can run this script with any valid combination
     of the following environment variables (in any order):
       KERNEL - the kernel image file to use
       ROOTFS - the rootfs image file or nfsroot directory to use
       MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified)
       Simplified QEMU command-line options can be passed with:
         nographic - disable video console
         serial - enable a serial console on /dev/ttyS0
         slirp - enable user networking, no root privileges is required
         kvm - enable KVM when running x86/x86_64 (VT-capable CPU required)
         kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU required)
         publicvnc - enable a VNC server open to all hosts
         audio - enable audio
         [*/]ovmf* - OVMF firmware file or base name for booting with UEFI
       tcpserial=<port> - specify tcp serial port number
       biosdir=<dir> - specify custom bios dir
       biosfilename=<filename> - specify bios filename
       qemuparams=<xyz> - specify custom parameters to QEMU
       bootparams=<xyz> - specify custom kernel parameters during boot
       help, -h, --help: print this text

     Examples:
       runqemu
       runqemu qemuarm
       runqemu tmp/deploy/images/qemuarm
       runqemu tmp/deploy/images/qemux86/<qemuboot.conf>
       runqemu qemux86-64 core-image-sato ext4
       runqemu qemux86-64 wic-image-minimal wic
       runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
       runqemu qemux86 iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
       runqemu qemux86 qemuparams="-m 256"
       runqemu qemux86 bootparams="psplash=false"
       runqemu path/to/<image>-<machine>.wic
       runqemu path/to/<image>-<machine>.wic.vmdk

4.10. Опции команды runqemu

Ниже приведено описание опций команды runqemu. При некорректной комбинации опций или их нехватке runqemu выдает сообщение, помогающее найти и устранить проблему.

  • QEMUARCH архитектура машины QEMU (qemuarm, qemuarm64, qemumips, qemumips64, qemuppc, qemux86, qemux86-64).
  • VMобраз виртуальной машины (.wic.vmdk) для загрузки. Имя файла должно включать qemux86-64, qemux86, qemuarm, qemumips64, qemumips, qemuppc или qemush4.
  • ROOTFS корневая файловая система ext2, ext3, ext4, jffs2, nfs или btrfs. Для nfs нужен полный путь к корню.
  • KERNELобраз ядра (.bin). При наличии файла .bin runqemu обнаруживает его и считает образом ядра.
  • MACHINEархитектура машины QEMU (qemux86, qemux86-64, qemuarm, qemuarm64, qemumips, qemumips64, qemuppc). Опции MACHINE и QEMUARCH в основном идентичны. Если опция MACHINE не задана, runqemu пытается определить машину из других опций.
  • ramfs указывает загрузку образа initramfs, означающего тип файловой системы (FSTYPE) cpio.gz.
  • iso указывает загрузку образа ISO, означающего тип файловой системы (FSTYPE) .iso.
  • nographic отключает графическую консоль, устанавливая консоль на ttys0. Опция полезна, когда вы подключены к серверу и не хотите отключать пересылку X11 на рабочую станцию.
  • serial включает последовательную консоль на порту /dev/ttyS0.
  • biosdir устанавливает пользовательский каталог для BIOS, VGA BIOS и keymap.
  • biosfilename устанавливает пользовательское имя BIOS.
  • qemuparams=\»xyz\» задает пользовательские параметры QEMU и служит для передачи опций, отличных от kvm и serial.
  • bootparams=\»xyz задает пользовательские параметры для загрузки ядра.
  • audio включает звук в QEMU. Опция MACHINE при этом должна иметь значение qemux86 или qemux86-64. Кроме того, нужен драйвер snd_intel8x0 или snd_ens1370 на гостевой системе linux.
  • slirp включает сеть slirp, для которой не требуется доступ root, но использование сложнее и менее функционально.
  • kvm включает KVM для архитектуры qemux86 или qemux86-64. Для работы KVM нужно выполнить 3 условия:
    • опция MACHINE должна иметь значение qemux86 или qemux86-64;
    • на хосте сборки должны быть установлены модули KVM (/dev/kvm);
    • каталог /dev/kvm на сборочном хосте должен быть открыт для чтения и записи.
  • kvm-vhost включает KVM с поддержкой VHOST для архитектуры qemux86 или qemux86-64. Для работы KVM с VHOST нужно выполнить 3 условия:
    • должны быть выполнены условия для опции kvm;
    • на хосте сборки должно быть устройство virtio net (/dev/vhost-net);
    • каталог /dev/vhost-net на сборочном хосте должен быть открыт для чтения и записи, а также требуется поддержка slirp;
  • publicvnc включает сервер VNC на всех хостах.

Литература

[1] Yocto Project Overview and Concepts Manual, https://www.yoctoproject.org/docs/2.7.1/overview-manual/overview-manual.html.

[2] Yocto Project Application Development and the Extensible Software Development Kit (eSDK), http://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html.

[3] Yocto Project Reference Manual, http://www.yoctoproject.org/docs/2.7.1/ref-manual/ref-manual.html.

[4] Yocto Project Quick Build, http://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html.

[5] Yocto Project Board Support Package (BSP) Developer’s Guide, https://www.yoctoproject.org/docs/2.7.1/bsp-guide/bsp-guide.html.

[6] BitBake User Manual, http://www.yoctoproject.org/docs/2.7.1/bitbake-user-manual/bitbake-user-manual.html.

[7] Yocto Project Linux Kernel Development Manual, https://www.yoctoproject.org/docs/2.7.1/kernel-dev/kernel-dev.html.

[8] Toaster User Manual, http://www.yoctoproject.org/docs/2.7.1/toaster-manual/toaster-manual.html.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1OpenEmbedded Image Creator — создатель образов OpenEmbedded.

2GNU Project Debugger — отладчик проекта GNU.

3Developer’s Certificate of Origin.

4Mail Transport Agent — агент доставки почты.

5Kernel Mode Setting — установка режима ядра.

6Quick EMUlator.

Рубрика: Linux | Комментарии к записи Руководство по разработке проектов в Yocto Project (часть 2) отключены

Руководство по разработке проектов в Yocto Project

Yocto Project Development Tasks Manual

PDF

Scott Rifenbark

Scotty’s Documentation Services, INC

<srifenbark@gmail.com>

Copyright © 2010-2019 Linux Foundation

Разрешается копирование, распространение и изменение документа на условиях лицензии Creative Commons Attribution-Share Alike 2.0 UK: England & Wales, опубликованной Creative Commons.

Этот документ основан на переводе Yocto Project Development Tasks Manual для выпуска 2.7.1. Свежие версии оригинальных документов можно найти на странице Yocto Project documentation. Размещенные там материалы более актуальны, нежели включенные в архивы пакета Yocto Project.

Глава 1. Руководство по разработке проектов в Yocto Project

1.1. Введение

В этом руководстве описаны процедуры разработки в среде Yocto Project (YP) образов Linux для встраиваемых систем и пользовательских приложений для работы на таких системах. Документ разбит на несколько разделов, описывающих связанные между собой процедуры.

Документ включает приведенные ниже описания.

  • Процедуры, помогающие начать работу с YP, например, процедуры организации хоста для сборки и работы с репозиториями YP.
  • Процедуры фиксации изменений в YP (улучшения, новые функции, исправления ошибок).
  • Процедуры общего назначения при разработке образов и приложений с использованием YP, например, процедуры создания уровней, настройки образов, создания новых заданий (recipe) и т. п.

Глава 2. Настройка YP

В этой главе описаны процедуры подготовки к работе с YP, включая создание среды командной работы с использованием YP, настройку хоста для сборки, поиск репозиториев YP создание локального репозитория Git.

2.1. Создание среды для командной работы

Использование YP для командной работы на первый взгляд может показаться не очевидным. Одной из сильных сторон YP является гибкость системы. Вы можете настроить ее для множества вариантов использования. Однако эта гибкость может вызывать сложности при настройке системы для работы большой команды.

В этом параграфе описана организация среды коллективной разработки и представлена процедура для решения этой задачи. Эта процедура реализуется на верхнем уровне и проверена на практике. Следует учитывать, что описанная процедура обеспечивает лишь стартовую точку и вам в любом случае придется приложить усилия по настройке системы в соответствии со своими реальными потребностями и задачами.

  1. Определение состава команды разработчиков. Определение участников разработки с использованием YP и их ролей. Это важно для выполнения пп. 2 и 3 при выборе оборудования и топологии. Ниже перечислены возможные роли участников процесса.
    • Разработчик приложений создает программы, работающие на базе имеющегося программного стека.
    • Разработчик ядра системы создает образы операционной системы.
    • Инженер сборки управляет автоматическими сборщиками (Autobuilder) и выпусками. Эта роль присутствует не всегда.
    • Инженер тестирования создает автоматизированные тесты и управляет ими для проверки качества приложений и операционной системы, а также соответствия стандартам.
  2. Подбор оборудования. Соберите оборудование с учетом размера и состава команды. В идеальном варианте всем членам команды лучше работать в среде на основе поддерживаемого дистрибутива Linux. Рабочие станции должны быть достаточно производительными (например, два 6-ядерных процессора Xeon с 24 Гбайт ОЗУ и достаточным пространством на диске). Для тестирования производительности и использования Autobuilder потребуются высокопроизводительные компьютеры.
  3. Анализ аппаратной топологии оборудования. После выбора оборудования для работы команды нужно разобраться с топологией среды разработки.
  4. Использование Git в качестве менеджера исходных кодов (SCM1). Рекомендуется хранить метаданные (задания, файлы конфигурации, классы и т. п.) и все разрабатываемые программы под контролем системы SCM, совместимой с системой сборки OpenEmbedded (OE). Из числа SCM, поддерживаемых BitBake, команда YP настоятельно рекомендует выбрать Git. Это распределенная система с простым резервированием, позволяющая работать удаленно, а затем возвращаться в инфраструктуру. Дополнительная информация о BitBake представлена в [6].Сравнительно просто организовать службы Git и создать инфраструктуру похожую на http://git.yoctoproject.org, которая основана на серверной программе gitolite с использованием cgit для генерации web-интерфейса, позволяющего просматривать репозитории. Программа gitolite идентифицирует пользователей с помощью ключей SSH и обеспечивает управление доступом по ветвям для репозиториев. Организация этих служб выходит за рамки документа, но ниже приведены ссылки на документы, описывающие эти процессы.
  5. Организация машин для разработки приложений. Как отмечено выше, разработчики приложений создают программы для работы на имеющемся программном стеке. Ниже приведены рекомендации по организации машин для такой работы.
    • Используйте собранный набор инструментов с нужным стеком программ и создавайте приложения для работы в этом стеке. Этот метод хорош для небольшого числа сравнительно изолированных приложений.
    • Поддерживайте инструменты кросс-разработки в актуальном состоянии. Это можно делать путем загрузки новых версий инструментальных пакетов или обновления с помощью механизма opkg. Выбор варианта зависит от ваших потребностей и принятой политики.
    • Используйте множество инструментальных пакетов, установленных локально в разных местах для работы с разными версиями.
  6. Организация машин для разработки ядра системы. Как отмечено выше, разработчики ядра системы работают непосредственно с образами операционных систем. Ниже приведены рекомендации по организации машин для такой работы.
    • Настройте систему сборки OE [3] на рабочих станциях разработчиков, чтобы они могли создавать свои сборки и напрямую пересобирать образы.
    • Сохраняйте систему сборки неизменной и вносите свои изменения в своих уровнях на основе этой системы. Это обеспечит переносимость работы при обновлении системы или пакетов BSP2.
    • Созданные уровни следует местно использовать всем разработчикам в соответствии с политикой настройки, определенной для проекта.
  1. Установка системы Autobuilder. Средства автоматической сборки зачастую являются ядром среды разработки. Именно здесь собираются вместе и тестируются результаты отдельных разработчиков. На базе этой автоматизированной среды сборки и тестирования принимается решение о выпуске. Autobuilder также позволяет тестировать программные компоненты в стиле «непрерывной интеграции» с обнаружением и отслеживанием регрессии.На странице YP Autobuilder представлена подробная информация и ссылка на buildbot, который команда YP сочла подходящим для автоматического тестирования. Общедоступным примером является YP Autobuilder, используемый командой YP для тестирования проекта в целом. Свойства системы приведены ниже.
    • Указание фиксаций (commit), нарушающих сборку.
    • Заполнение кэша sstate [1], из которого разработчики могут извлекать данные ,ез локальной сборки.
    • Поддержка триггеров фиксаций, включающих сборки при новом представлении (commit).
    • Возможность включать автоматизированную загрузку и тестирование образов в QEMU3.
    • Поддержка пошагового тестирования сборки и сборок «с нуля».
    • Общий доступ к выводу сборки, позволяющий разработчикам выполнять тестирование и искать проблемы.
    • Создание вывода, который можно использовать в выпусках системы.
    • Возможность сборки по расписанию для эффективного использования ресурсов.
  1. Установка машин для тестов. Используйте несколько высокопроизводительных систем для тестирования. Разработчики могут применять эти машины для масштабного тестирования, продолжая работу на своих системах.
  2. Правила документирования и поток изменений. YP использует иерархическую структуру и модель извлечения. Имеются сценарии для создания и отправки pull-запросов (create-pull-request и send-pull-request). Эта модель соответствует другим проектам с открытым кодом, где сопровождающие отвечают за определенные области проекта, а один обрабатывает слияния на вершине дерева (top-of-tree). Можно также использовать коллективную модель выталкивания (push), поскольку gitolite одинаково легко поддерживает модели push и pull. Как в любой среде разработки важно документировать используемые правила, а также основные принципы проекта, чтобы они были понятны каждому. Хорошо также структурировать сообщения фиксации (commit), что обычно делается в описании принципов проекта. Четкие сообщения фиксации нужны для понимания внесенных в проект изменений.При необходимости внесения изменений в ядро проекта следует как можно скорее поделиться ими с сообществом. Скорее всего другие члены сообщества также нуждаются в этих изменениях.
  3. Дополнительные рекомендации.
    • Используйте Git в качестве системы управления исходными файлами.
    • Поддерживайте метаданные на уровнях, которые имеют смысл для вашей ситуации (см. раздел The Yocto Project Layer Model [1] и параграф 3.1. Уровни и их создание).
    • Разделяет метаданные и код проекта, используя разные репозитории Git (см. раздел Yocto Project Source Repositories [1] и параграф 2.3. Доступ к исходным файлам YP.
    • Создайте каталог для кэширования общих данных состояния (SSTATE_DIR). Например создайте кэш sstate на системе разработчиков и используйте одинаковые каталоги исходных кодов на их машинах.
    • Установите систему Autobuilder и поместите в нее кэш sstate и каталоги с исходными кодами.
    • Сообщество YP призывает отправлять исправления (patch) в проекте для устранения ошибок и расширения возможностей. Если вы представляете изменения, следуйте правилам фиксации (см. параграф 3.31.2. Представление изменений в YP.
    • Отправляйте изменения в ядре системы как можно скорей, поскольку с этими же проблемами могут столкнуться другие люди. Рекомендации и списки рассылок приведены в параграфе 3.31.2. Представление изменений в YP и разделе Mailing Lists [3].

2.2. Подготовка сборочного хоста

В этом параграфе описана настройка системы, которая будет служить сборочным хостом для разработки с использованием YP. Хост может быть Linux-машиной (рекомендуется) или машиной (Linux, Mac, Windows) с CROPS и контейнерами Docker. Хост с WSL4 не подойдет в качестве сборочного по причине несовместимости YP с WSL.

После установки YP на сборочном хосте дальнейшие шаги зависят от ваших задач. Ниже представлены ссылки на информацию для случаев работы с BSP и ядром Linux.

2.2.1. Установка сборочного хоста Linux

  1. Используйте поддерживаемый дистрибутив Linux. Вам следует выбрать хост с текущей версией того или иного дистрибутива Linux. Рекомендуется применять свежий выпуск Fedora, openSUSE, Debian, Ubuntu или CentOS, поскольку эти дистрибутивы тестируются с YP и поддерживаются официально5. Список всех поддерживаемых дистрибутивов и детали работы с ними представлены в разделе Supported Linux Distributions [3] и на странице Distribution Support.
  2. Обеспечьте достаточный объем свободного пространства на диске. Для работы потребуется не менее 50 Гбайт свободного пространства на диске при сборке образов6.
  3. Выполните требования к версиям программ на хосте. Система сборки OE может работать с любым современным дистрибутивом, включающим
    • Git 1.8.3.1 и выше;
    • tar 1.27 и выше;
    • Python 3.4.0 и выше.

Если на сборочном хосте не выполняется какое-либо из этих требований, следует предпринять действия, указанные в разделе Required Git, tar, and Python Versions [3].

  1. Установка пакетов на хост разработки сильно зависит от операционной системы и задач, которые планируется выполнять в YP. Если вы хотите работать со всеми классами, потребуется установка достаточно большого числа пакетов, как указано в разделе Required Packages for the Build Host [3].

После выполнения перечисленных действий система будет готова к использованию. Работа с рассмотрена в параграфе 2.4.1. Клонирование репозитория poky, использование расширяемого SDK7 описано в разделе Using the Extensible SDK [2]. Работа с ядром Linux описана [7]. При использовании интерфейса управления Toaster следует обратиться к разделу Setting Up and Using Toaster [8].

2.2.2. Настройка CROPS

С CROPS8 и контейнерами Docker можно создать среду разработки YP, независимую от операционной системы хоста. Можно организовать контейнер, который будет работать на машинах Windows, Mac, Linux для разработки в среде YP.

  1. Определение потребностей сборочного хоста. Docker представляет собой платформу программных контейнеров, которую нужно установить на сборочном хосте. В зависимости от конкретного хоста можно установить разные программы для работы с контейнерами Docker. Информацию о поддерживаемых системах и установке программ для работы с контейнерами можно найти на странице Supported Platforms.
  2. Выбор устанавливаемых компонент. В зависимости от соответствия сборочного хоста системным требованиям нужно установить пакет Docker CE Stable (в большинстве случаев) или Docker Toolbox.
  3. Переход на сайт установки для вашей платформы. Воспользуйтесь ссылкой для выпуска Docker, соответствующего программной платформе сборочного хоста. Например, для Microsoft Windows версии 10 следует выбрать Docker CE Stable из списка поддерживаемых платформ.
  4. Установка программ. После проверки соответствия установочного требованиям можно загрузить и установить программу, следуя инструкциям пакета установки.
  5. Знакомство с системой Docker. При необходимости ознакомьтесь с Docker и концепцией контейнеров на странице https://docs.docker.com/get-started/.
  6. Запуск Docker или Docker Toolbox активизирует терминальное окно системы на вашем сборочном хосте.
  7. Настройка контейнеров для работы с YP. На странице https://github.com/crops/docker-win-mac-docs/wiki приведены инструкции для работы на разных платформах (Linux, Mac или Windows). После выполнения установочных инструкций для вашей машины вы получите контейнеры Poky, eSDK и Toaster. Для знакомства с ними можно воспользоваться ссылками на указанной выше странице.

После установки контейнеров все готово для работы, как будто вы используете естественную машину Linux. Работа с контейнером Poky описана в параграфе 2.4.1. Клонирование репозитория poky. Описание работы с контейнером eSDK дано в разделе Using the Extensible SDK [2], а работа с системой Toaster в разделе Setting Up and Using Toaster [8].

2.3. Доступ к исходным файлам YP

В этом разделе описано как найти исходные файлы YP и работать с ними в проекте. Концепции и рекомендации по использованию Git с YP приведены в разделе Git [1]. Концепции работы с репозиторием YP описаны в разделе Yocto Project Source Repositories [1].

2.3.1. Доступ к репозиториям исходных кодов

Работа с копией репозитория исходных кодов является предпочтительным вариантов получения и использования выпуска YP. Список репозиториев YP можно найти на сайте http://git.yoctoproject.org. В частности, репозиторий poky размещается по ссылке http://git.yoctoproject.org/cgit/cgit.cgi/poky/. Процедура установки свежей версии описана ниже.

  1. Доступ к репозиториям. Перейдите в браузере по ссылке http://git.yoctoproject.org с интерфейсом к репозиториям исходных кодов YP.
  2. Выбор репозитория по ссылке (например, poky).
  3. Определение URL для клонирования репозитория. В нижней части страницы приведен идентификатор URL для клонирования репозитория (например, http://git.yoctoproject.org/poky). Процесс клонирования описан в параграфе 2.4.1. Клонирование репозитория poky.

2.3.2. Доступ к списку выпусков

YP поддерживает список выпусков (Index of Releases), где указаны файлы, включенные в YP. В отличие от репозиториев Git эти файлы являются архивами, соответствующими определенному времени. Рекомендуемым методом доступа к компонентам YP является клонирование репозитория Git и работа с локальной копией. Описанная в этом параграфе процедура относится к установке компонент из архивов.

  1. Доступ к списку выпусков. Откройте браузер и перейдите по ссылке http://downloads.yoctoproject.org/releases для доступа к Index of Releases, где представлены компоненты выпуска (bitbake, sato и т. д.). Каталог yocto содержит архивы всех выпусков Poky, а каталог poky в Index of Releases применялся лишь для самых первых выпусков и сохранен только для полноты.
  2. Выберите компоненту по ссылке в списке (например, yocto).
  3. Выберите архив из списка выпусков. Например, щелчок по ссылке yocto-2.7.1 покажет файлы, связанные с выпуском YP 2.7.1 (например, poky-warrior-21.0.0.tar.bz2 для Poky).
  4. Загрузка архива. Щелкните по имени нужного архива для его загрузки.

2.3.3. Использование страницы загрузки

На сайте YP страница DOWNLOADS предназначена для выбора и загрузки архивов имеющихся выпусков YP. В отличие от репозиториев Git эти файлы представляют архив, сделанный в определенный момент, подобно файлам из Index of Releases, описанным в параграфе 2.3.2. Доступ к списку выпусков. Рекомендуемым методом доступа к компонентам YP является клонирование репозитория Git и работа с локальной копией. Описанная в этом параграфе процедура относится к установке компонент из архивов.

  1. Откройте сайт YP в браузере по ссылке.
  2. Перейдите в область загрузки файлов, выбрав опцию DOWNLOADS в раскрывающемся меню SOFTWARE наверху страницы.
  3. Выберите выпуск YP в меню RELEASE (например, warrior, thud и т. д). Для сопоставления имен выпусков YP с номерами версий используйте страницу Releases. Можно воспользоваться ссылкой RELEASE ARCHIVE для получения меню выбора из всех выпусков YP.
  4. Загрузите инструменты или BSP со страницы DOWNLOADS.

2.3.4. Доступ к «ночным сборкам»

YP поддерживает область «ночных сборок» в архивами на странице https://autobuilder.yocto.io//pub/nightly/. Эти архивы включают выпуски YP (poky), инструменты и сборки для поддерживаемых машин. Процедура получения ночных сборок описана ниже.

  1. Перейдите к списку ночных сборок, открыв в браузере ссылку https://autobuilder.yocto.io//pub/nightly/.
  2. Выберите дату, щелкнув по нужной ссылке. Для получения последней сборки используйте CURRENT.
  3. Выберите сборку. Например, для получения наиболее свежих инструментов служит ссылка toolchain.
  4. Выберите архив, прокручивая список.
  5. Загрузите архив, соответствующий выбранной дате и компоненте.

2.4. Клонирование и выбор ветвей

Для использования YP при разработке нужно установить выпуск пакета на хосте разработки. Этот набор локально установленных файлов называется в документации YP деревом (каталогом) исходных кодов (Source Directory).

Предпочтительным методом создания дерева кодов является использование Git для клонирования репозитория poky. Работа с клонированной копией репозитория позволяет включить ваши результаты в YP или просто использовать последние версии программ из ветви разработки. Поскольку Git клонирует и поддерживает репозиторий с полной историей изменений, а вы работаете с локальной копией репозитория, вы получаете доступ ко всем разрабатываемым ветвям YP и тегам, применяемым в репозитории.

2.4.1. Клонирование репозитория poky

Ниже перечислены этапы создания локальной копии репозитория Git poky.

  1. Организация локального каталога. Создайте каталог для локального репозитория poky и перейдите в него.
  2. Клонирование репозитория. Ниже приведен пример команды клонирования репозитория poky и ее вывод.
         $ git clone git://git.yoctoproject.org/poky
         Cloning into 'poky'...
         remote: Counting objects: 432160, done.
         remote: Compressing objects: 100% (102056/102056), done.
         remote: Total 432160 (delta 323116), reused 432037 (delta 323000)
         Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
         Resolving deltas: 100% (323116/323116), done.
         Checking connectivity... done.

    Если не задана конкретная ветвь репозитория или тег, Git клонирует ветвь master в ее текущем состоянии. Информация о выборе ветви или указании тега приведена в параграфах 2.4.2. Выбор ветви в Poky и 2.4.3. Выбор в Poky по тегу, соответственно.

    После создания локального репозитория можно проверить его состояние. В примере показана 1 ветвь master.

         $ git status
         On branch master
         Your branch is up-to-date with 'origin/master'.
         nothing to commit, working directory clean
         $ git branch
         * master

    Это говорит об идентичности локальной копии репозитория poky и его оригинала. При работе с локальной копией можно периодически использовать команду git pull ‐‐rebase для поддержки актуальности копии.

2.4.2. Выбор ветви в Poky

После клонирования репозитория poky вы получаете доступ ко всем его ветвям, каждая из которых уникальна и начинается от ветви master. Для просмотра и использования файлов той или иной ветви нужно узнать ее имя, а затем переключиться (check out) на эту ветвь. Переключение на определенную ветвь по имени предоставляет доступ к текущему состоянию файлов этой ветви. Дальнейшая разработка будет выполняться применительно к файлам выбранной ветви.

  1. Переход в каталог Poky. При наличии локальной копии репозитория poky Git, перейдите в соответствующий каталог. Создание локальной копии репозитория описано в параграфе 2.4.1. Клонирование репозитория poky.
  2. Определение ветвей репозитория.
         $ git branch -a
         * master
           remotes/origin/1.1_M1
           remotes/origin/1.1_M2
           remotes/origin/1.1_M3
           remotes/origin/1.1_M4
           remotes/origin/1.2_M1
           remotes/origin/1.2_M2
           remotes/origin/1.2_M3
               ...
           remotes/origin/pyro
           remotes/origin/pyro-next
           remotes/origin/rocko
           remotes/origin/rocko-next
           remotes/origin/sumo
           remotes/origin/sumo-next
           remotes/origin/thud
           remotes/origin/thud-next
           remotes/origin/warrior
  3. Выбор ветви. Выберите интересующую ветвь и перейдите в нее. Например, для доступа к файлам выпуска YP 2.7.1 (Warrior) используется приведенная ниже команда.
         $ git checkout -b warrior origin/warrior
         Branch warrior set up to track remote branch warrior from origin.
         Switched to a new branch 'warrior'

    Команда переключает ваш репозиторий на ветвь warrior и сообщает об отслеживании восходящей ветви origin/warrior.

    Ниже приведена команда, отображающая ветви вашего текущего локального репозитория. Выбранная для работы ветвь помечена звездочкой (*).

         $ git branch
           master
         * warrior

2.4.3. Выбор в Poky по тегу

Подобно ветвям, восходящий репозиторий использует теги для маркировки определенных фиксаций (commit), связанных со значимыми изменениями ветвей (например, точка официального выпуска). Можно связать локальный репозиторий с таким тегом, используя процедуру, похожую на выбор ветви. Переход на ветвь по тегу обеспечивает стабильный набор файлов, на которые не влияют изменения ветви, к которой относится этот тег.

  1. Переход в каталог Poky. При наличии локальной копии репозитория poky Git, перейдите в соответствующий каталог. Создание локальной копии репозитория описано в параграфе 2.4.1. Клонирование репозитория poky.
  2. Получение тегов. Для выбора ветви по имени тега нужно извлечь теги из восходящего репозитория в локальную копию с помощью приведенной ниже команды.
         $ git fetch --tags
  3. Список имен тегов с помощью команды git tag.
         $ git tag
         1.1_M1.final
         1.1_M1.rc1
         1.1_M1.rc2
         1.1_M2.final
         1.1_M2.rc1
            ...
         yocto-2.5
         yocto-2.5.1
         yocto-2.5.2
         yocto-2.5.3
         yocto-2.6
         yocto-2.6.1
         yocto-2.6.2
         yocto-2.7
         yocto_1.5_M5.rc8        
  4. Выбор ветви.
         $ git checkout tags/yocto-2.7.1 -b my_yocto_2.7.1
         Switched to a new branch 'my_yocto_2.7.1'
         $ git branch
           master
         * my_yocto_2.7.1

    Команда создает локальную ветвь my_yocto_2.7.1 (основанную на фиксации в восходящем репозитории с указанным тегом) и переключается на нее. В этом примере предоставляются файлы, связанные с выпуском YP 2.7.1 в ветви warrior.

Глава 3. Базовые задачи

В этой главе описаны фундаментальные процедуры, такие как создание уровней, добавление новых программных пакетов, перенос программ на новое оборудование (добавление машины) и т. п. Описанные здесь процедуры часто применяются в процессе работы с YP.

3.1. Уровни и их создание

Система сборки OE поддерживает организацию метаданных с множеством уровней (layer), позволяющих разделить разные типы настроек. Базовая информация об уровнях YP приведена в разделе The Yocto Project Layer Model [1].

3.1.1. Создание своего уровня

Создать свой уровень в OE очень просто. YP поставляется с инструментами для создания уровней. В этом параграфе описаны этапы создания уровней для лучшего понимания процесса. Средства для создания уровней описаны в разделе Creating a New BSP Layer Using the bitbake-layers Script [5] и параграфе 3.1.8. Создание базового уровня с помощью сценария bitbake-layers.

Ниже описаны этапы создания уровня без использования специальных инструментов

  1. Просмотр имеющихся уровней. Перед созданием нового уровня нужно убедиться, что кто-либо уже не создал уровень с нужными вам метаданными. Можно просмотреть список OpenEmbedded Metadata Index, где указаны уровни, созданные сообществом OE, которые можно использовать в YP. Там может оказаться нужный или близкий к желаемому уровень.
  2. Создание каталога. Создайте каталог для нового уровня в области, не связанной каталогом исходных кодов YP (например, клонированным репозиторием poky). Хотя это не требуется, лучше использовать имена каталогов с префиксом meta-, например, meta-mylayer, meta-GUI_xyz, meta-mymachine.За редкими исключениями для имен уровней используют форму meta-root_name. Соблюдение этих соглашений об именах поможет предотвратить возникновение проблем, когда инструменты, компоненты или переменные «предполагают» имена уровней с префиксом meta-. Ярким примером служат файлы конфигурации, описанные на следующем этапе, где имена без префикса meta- добавляются в некоторые переменные, используемые в конфигурации.
  3. Создание файла конфигурации уровня. В новом каталоге уровня нужно создать файл conf/layer.conf. Проще всего для этого взять файл конфигурации имеющегося уровня, скопировать его и внести требуемые изменения.Файл meta-yocto-bsp/conf/layer.conf в YP Source Repositories демонстрирует синтаксис конфигурационного файла. Следует заменить yoctobsp идентификатором своего уровня (например, machinexyz для уровня с именем meta-machinexyz).
         # We have a conf and classes directory, add to BBPATH
         BBPATH .= ":${LAYERDIR}"
    
         # We have recipes-* directories, add to BBFILES
         BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
         ${LAYERDIR}/recipes-*/*/*.bbappend"
    
         BBFILE_COLLECTIONS += "yoctobsp"
         BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
         BBFILE_PRIORITY_yoctobsp = "5"
         LAYERVERSION_yoctobsp = "4"
         LAYERSERIES_COMPAT_yoctobsp = "warrior"
    • BBPATHдобавляет корневой каталог уровня в путь поиска BitBake. С помощью этой переменной BitBake находит файлы классов (.bbclass), конфигурационные файлы и файлы, включенные операторами include и require. BitBake в этих случаях использует первый файл, найденный по пути из переменной BBPATH. Это похоже на использование системной переменной PATH для поиска двоичных файлов. Поэтому рекомендуется применять для классов и конфигурации уникальные имена.
    • BBFILES определяет местоположение всех заданий уровня.
    • BBFILE_COLLECTIONSорганизует текущий уровень с помощью уникального идентификатора, используемого в системе сборки OE для указания этого уровня. В нашем примере идентификатор yoctobsp представляет контейнерный уровень meta-yocto-bsp.
    • BBFILE_PATTERNпреобразуется в процессе разбора для представления имени каталога уровня.
    • BBFILE_PRIORITYзадает приоритет для использования заданий уровня при поиске системой сборки OE заданий с одним именем из разных уровней.
    • LAYERVERSIONзадает номер версии для уровня. Этот номер можно применять для указания точной версии уровня в качестве зависимости при использовании переменной LAYERDEPENDS.
    • LAYERSERIES_COMPAT содержит список выпусков YP с которыми совместима данная версия. Это хороший способ указать, является ли ваш уровень текущим.
  4. Добавление содержимого в зависимости от типа уровня. Если уровень добавляет поддержку машины, добавляется ее конфигурация в каталог conf/machine/ внутри уровня. Если уровень добавляет правила distro указывается конфигурация дистрибутива в каталоге conf/distro/. При добавлении заданий их нужно помещать в подкаталоги recipes-* внутри уровня. Описание совместимой с YP иерархии уровней приведено в разделе Example Filesystem Layout [5].
  5. Необязательная проверка на совместимость. Если вы хотите получить разрешение на использование логотипа YP Compatibility для уровня или приложения, использующего ваш уровень, нужно выполнить этот этап. Подробная информация приведена в параграфе 3.1.3. Подтверждение совместимости уровня с YP.

3.1.2. Рекомендации по организации уровней

Для создания уровней, которые будут просты в поддержке и не станут мешать другим уровням, следуйте приведенным ниже рекомендациям.

  • Избегайте полного перекрытия с заданиями из других уровней. Избегайте копирования задания целиком на свой уровень с последующим изменением задания. Лучше использовать файл добавления (.bbappend) для переопределения лишь тех частей исходного задания, которые требуют этого.
  • Избегайте дублирования включаемых файлов. Применяйте файлы добавления (.bbappend) для каждого задания, которое использует включаемый файл. Для нового задания, которому нужны включаемые файлы, используйте путь относительно каталога исходного уровня для ссылки на файл. Например, следует указывать require recipes-core/package/file.inc, а не просто require file.inc. Если возникает перекрытие включаемых файлов, это может говорить о недостатках включаемого файла на уровне, к которому он изначально относится. В таких случаях следует попытаться устранить недостаток, чтобы включаемые файлы не перекрывались. Например, можно попросить сопровождающего включаемый файл человека добавить в файл нужные переменные, чтобы упростить требуемые переопределения частей.
  • Структурируйте свои уровни. Аккуратное использование переопределений в файлах добавления и размещение относящихся к конкретным машинам файлов внутри своего уровня может гарантировать предотвращения использования при сборке ошибочных метаданных и негативного влияния на сборку других машин. Ниже приведено несколько примеров.
    • Изменяйте переменные для поддержки разных машин. Предположим, что у вас есть уровень meta-one для сборок под машину one, применяется файл добавления base-files.bbappend и создана зависимость от foo в переменной DEPENDS = «foo»Зависимость создается в процессе любой сборки, включающей уровень meta-one. Однако эта зависимость может оказаться нужной не для всех машин. Например, предположим, что собирается образ для машины two и файл bblayers.conf включает уровень meta-one. В процессе сборки base-files для машины two будет добавлять зависимость от foo.Для того, чтобы изменения затрагивали только машину one используется переопределение в операторе DEPENDS_one = «foo».Аналогичный подход применяется при использовании операций _append и _prepend
           DEPENDS_append_one = " foo"
           DEPENDS_prepend_one = "foo "

      В качестве реального примера ниже приведена строка из задания для gnutls, добавляющая зависимость от argp-standalone при сборке с библиотекой musl C.

           DEPENDS_append_libc-musl = " argp-standalone"

      Избегайте операций += и =+, а также _append и _prepend.

    • Размещайте файлы для конкретных машин в каталогах этих машин. При наличии базового задания, такого как base-files.bb, которое содержит оператор SRC_URI, можно использовать файл добавления, заставляющий сборку использовать вашу версию файла. Например, файл добавление на вашем уровне meta-one/recipes-core/base-files/base-files.bbappend может расширять FILESPATH с использованием FILESEXTRAPATHS_prepend := «${THISDIR}/${BPN}:»Сборка для машины one возьмет ваш файл для машины при его наличии в meta-one/recipes-core/base-files/base-files/. Однако, если сборка выполняется для другой машины и файл bblayers.conf включает уровень meta-one, а ваш файл, связанный с машиной, расположен в месте, которое задано первым в FILESPATH, сборка для всех машин будет использовать этот связанный с машиной файл.Можно обеспечить использование машинозависимого файла для конкретной машины путем его размещения в связанном с этой машиной каталоге. Например, вместо размещения в каталоге meta-one/recipes-core/base-files/base-files/, как показано выше, файл помещается в каталог meta-one/recipes-core/base-files/base-files/one/. Это не только гарантирует использование файла при сборке для машины one, но и существенно ускоряет процесс сборки.Таким образом, следует поместить все файлы, указанные в SRC_URI в связанный с машиной каталог внутри вашего уровня, чтобы использовать эти файлы только в сборках для данной машины.
  • Применение этапов YP Compatibility. Если вы хотите получить право использовать логотип Yocto Project Compatibility со своим уровнем или приложением нужно выполнить действия, описанные в параграфе 3.1.3. Подтверждение совместимости уровня с YP.
  • Выполнение соглашений по именованию уровней. Сохраняйте свои уровни в репозитории Git, используя формат meta-layer_name.
  • Группируйте свои уровни локально. Клонируйте свой репозиторий вместе с другими мета-каталогами из дерева исходных кодов.

3.1.3. Подтверждение совместимости уровня с YP

При создании уровня для использования в YP полезно убедиться, что этот уровень хорошо взаимодействует с имеющимися уровнями YP (т. е. с уровнями, совместимыми с YP). Обеспечение совместимости упрощает использование уровня другими членами сообщества YP и позволяет использовать Yocto Project Compatible Logo. Знак Yocto Project Compatible Logo могут использовать только организации, являющиеся членами YP. Информация о членстве в YP представлена на сайте YP.

Программа совместимости YP включает процесс применения уровня, который запрашивает использование Yocto Project Compatibility Logo для уровня и приложений, состоящий из двух частей.

  1. Успешное прохождение на уровне сценария (yocto-check-layer), проверяющего соблюдение ограничений, основанных на опыте использования уровней в реальном мире, и прохождение известных ловушек. Результат PASS в конце сценария говорит о совместимости уровня.
  2. Заполнение заявки (https://www.yoctoproject.org/webform/yocto-project-compatible-registration).

Для получения права использовать логотип, нужно выполнить несколько условий:

  • иметь возможность установить флажок, показывающий результат PASS при запуске сценария проверки;
  • ответить Yes на вопросы заявки и предоставить приемлемое разъяснение для всех ответов No;
  • быть членом Yocto Project Member Organization.

В оставшейся части этого раздела представлена информация о регистрационной форме и сценарии yocto-check-layer.

3.1.3.1. Применение программы Yocto Project Compatible

Используйте форму для подачи заявки на утверждение вашего уровня. После утверждения вы сможете указывать Yocto Project Compatibility Logo для уровня и использующих его приложений. При заполнении заявки следуйте инструкциям.

  • Контактные данные. Предоставьте сведения для контактов с вами в требуемых полях. Укажите также версии выпусков YP, с которыми совместим ваш уровень.
  • Критерии согласия. Укажите Yes или No для каждой записи в списке вопросов. В конце заявки имеется место для пояснений по всем пунктам, где вы ответили No.
  • Рекомендации. Ответьте на вопросы, относящиеся к ядру Linux и результатам сборки.
3.1.3.2. Сценарий yocto-check-layer

Сценарий yocto-check-layer позволяет оценить совместимость вашего уровня с YP. Сценарием следует воспользоваться до подачи заявки, описанной в предыдущем параграфе. Для успешной обработки заявки нужно обеспечить получение результата PASS при работе сценария.

Сценарий включает 3 области проверки — COMMON, BSP и DISTRO. Например, для уровня дистрибутива (DISTRO) должны пройти тесты COMMON и DISTRO. Если ваш уровень является BSP, нужно пройти тесты COMMON и BSP.

Команды для запуска сценария приведены ниже.

$ source oe-init-build-env
     $ yocto-check-layer your_layer_directory

В качестве your_layer_directory нужно указать реальное имя каталога с вашим уровнем.

Сценарий определяет тип уровня и запускает для него соответствующие тесты. Обзор тестов представлен ниже.

  • common.test_readme проверяет наличие файла README на уровне и наличие содержимого в файле.
  • common.test_parse проверяет возможность BitBake проанализировать файл без ошибок (bitbake -p).
  • common.test_show_environment проверяет наличие ошибок в глобальном окружении и окружении для задания (bitbake -e).
  • common.test_signatures проверяет отсутствие на уровнях BSP и DISTRO заданий, меняющих подписи.
  • bsp.test_bsp_defines_machines проверяет наличие конфигураций для машин на уровне BSP.
  • bsp.test_bsp_no_set_machine проверяет, что уровень BSP не задает машину при его добавлении.
  • distro.test_distro_defines_distros проверяет наличие конфигураций на уровне DISTRO.
  • distro.test_distro_no_set_distro проверяет, что уровень DISTRO не задает дистрибутив при своем добавлении.

3.1.4. Включение уровня

Перед началом использования уровня системой сборки OE уровень нужно включить, для чего просто добавляется путь к этому уровню в переменную BBLAYERS файла conf/bblayers.conf, хранящегося в каталоге сборки. Ниже приведен пример добавления уровня meta-mylayer.

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
     # changes incompatibly
     POKY_BBLAYERS_CONF_VERSION = "2"

     BBPATH = "${TOPDIR}"
     BBFILES ?= ""

     BBLAYERS ?= " \
       /home/user/poky/meta \ /home/user/poky/meta-poky \ /home/user/poky/meta-yocto-bsp \ /home/user/poky/meta-mylayer \ "

BitBake анализирует каждый файл conf/layer.conf сверху вниз в соответствии с переменной BBLAYERS в файле conf/bblayers.conf. При обработке каждого файла conf/layer.conf программа BitBake добавляет задания, классы и конфигурации, содержащиеся в указанном уровне.

3.1.5. Использование файлов .bbappend на уровне

Задание, добавляющее метаданные в другое задание, называется в BitBake файлом добавления. Эти файлы используют расширение .bbappend, тогда как файлы, в которые метаданные добавляются, — расширение .bb.

Можно применять файл .bbappend на своем уровне или менять содержимое задания на другом уровне без копирования таких заданий на свой уровень. Файлы .bbappend размещаются на вашем уровне, тогда как файл .bb, в который добавляются метаданные, может размещаться на другом уровне.

Возможность добавлять информацию в имеющиеся задания не только избавляет от дублирования, но и автоматически переносит изменения заданий других уровней на ваш уровень. Если бы вы копировали эти задания, пришлось бы вручную вносить изменения.

При создании файла добавления нужно использовать корневое имя соответствующего файла задания. Например, файл добавления someapp_2.7.1.bbappend должен применяться к файлу someapp_2.7.1.bb. Это означает зависимость исходного задания и файла добавления от номера версии. Если задание переименовано с учетом новой версии, нужно будет обновить и, возможно, переименовать соответствующий файл .bbappend. В процессе сборки BitBake выводит сообщения об ошибках при запуске, если обнаруживается, что для файла .bbappend нет задания с соответствующим именем. Обработка таких ошибок рассмотрена в описании переменной BB_DANGLINGAPPENDS_WARNONLY.

Рассмотрим в качестве примера задание formfactor и соответствующий файл добавления formfactor, хранящиеся в дереве исходных кодов. Ниже показан основной файл задания formfactor_0.0.bb, хранящийся на уровне meta в каталоге meta/recipes-bsp/formfactor.

SUMMARY = "Device formfactor information"
SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
PR = "r45"

SRC_URI = "file://config file://machconfig"
S = "${WORKDIR}"

PACKAGE_ARCH = "${MACHINE_ARCH}"
INHIBIT_DEFAULT_DEPS = "1"

do_install() {
        # Install file only if it has contents
        install -d ${D}${sysconfdir}/formfactor/
        install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
        if [ -s "${S}/machconfig" ]; then
    install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
        fi
}

Отметим в этом файле переменную SRC_URI, которая указывает системе сборки OE места поиска файлов при сборке.

Ниже показано содержимое файла добавления formfactor_0.0.bbappend с уровня Raspberry Pi BSP Layer называющегося meta-raspberrypi. Файл хранится на этом уровне в каталоге recipes-bsp/formfactor.

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

По умолчанию система сборки применяет для поиска файлов переменную FILESPATH. Этот файл добавления расширяет сферу поиска путем установки переменной FILESEXTRAPATHS. Задание этой переменной в файле .bbappend является наиболее надежным и рекомендуемым методом добавления каталогов в путь поиска при сборке.

Оператор в этом примере расширяет переменную путем добавления в конце ${THISDIR}/${PN}, преобразуемого в каталог formfactor в том же каталоге, где хранится файл добавления (meta-raspberrypi/recipes-bsp/formfactor). Это предполагает наличие структуры каталогов поддержки для файлов и исправлений (patch), применяемых уровнем.

Использование оператора непосредственного преобразования := в этом случае важно, поскольку указывается текущий каталог THISDIR. Двоеточие в конце обеспечивает отделение последующих элементов.

BitBake автоматически определяет значение переменной THISDIR и вам не следует устанавливать его. Использование _prepend с переменной FILESEXTRAPATHS обеспечивает добавление пути поиска в начало имеющегося списка.

Не все файлы .bbappend добавляют новые файлы, многие просто добавляют опции сборки (например, systemd). В таких случаях файл добавления не будет включать оператора FILESEXTRAPATHS.

3.1.6. Приоритизация уровня

Каждый уровень имеет определенный приоритет, который определяет предпочтительность уровня при наличии одноименных файлов заданий на нескольких уровнях. В таких случаях берется задание уровня с высшим приоритетом. Значения приоритета влияют также на порядок применения файлов .bbappend к одному заданию. Приоритет можно задать вручную или позволить рассчитать его системе сборки на основе зависимостей между уровнями.

Для задания приоритета вручную служит переменная BBFILE_PRIORITY с добавлением корневого файла уровня.

     BBFILE_PRIORITY_mylayer = "1"

Возможны ситуации, когда задание с меньшим номером версии PV на уровне будет иметь более высокий приоритет.

Уровень приоритета не влияет на порядок предпочтения файлов .conf и .bbclass, но это может появиться в будущих версиях BitBake.

3.1.7. Управление уровнями

Можно использовать инструмент управления уровнями bitbake-для просмотра структуры заданий в проекте с множеством уровней. Возможность увидеьб отчет о настроенных уровнях с их путями и приоритетами, файлами .bbappend и заданиями, к которым они относятся, может оказать помощь при поиске неполадок.

Информацию о работе с инструментом можно получить по команде

     $ bitbake-layers --help
     NOTE: Starting bitbake server...
     usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h] <subcommand> ...

     BitBake layers utility

     optional arguments:
       -d, --debug           Enable debug output
       -q, --quiet           Print only errors
       -F, --force           Force add without recipe parse verification
       --color COLOR         Colorize output (where COLOR is auto, always, never)
       -h, --helpshow this help message and exit

     subcommands:
       <subcommand>
         show-layers         show current configured layers.
         show-overlayed      list overlayed recipes (where the same recipe exists
     				   in another layer)
         show-recipes        list available recipes, showing the layer they are
				   provided by
         show-appends        list bbappend files and recipe files they apply to
         show-cross-depends  Show dependencies between recipes that cross layer
				   boundaries.
         add-layer           Add one or more layers to bblayers.conf.
         remove-layer        Remove one or more layers from bblayers.conf.
			         flatten flatten layer configuration into a separate output
				   directory.
         layerindex-fetch    Fetches a layer from a layer index along with its
				   dependent layers, and adds them to conf/bblayers.conf.
         layerindex-show-depends
				   Find layer dependencies from layer index.
         create-layer        Create a basic layer

     Use bitbake-layers <subcommand> --help to get help on a specific command

Краткие описания команд приведены ниже.

help

Выводит общую справку или информацию о конкретной команде.

show-layers

Показывает настроенные в данный момент уровни.

show-overlayed

Показывает перекрывающиеся задания, т. е. одноименные задания на разных уровнях.

show-recipes

Показывает задания и уровни, к которым они относятся.

show-appends

Показывает файлы .bbappend и задания, к которым они относятся.

show-cross-depends

Перечисляет зависимости между заданиями разных уровней.

add-layer

Добавляет уровень в файл bblayers.conf.

remove-layer

Удаляет уровень из файла bblayers.conf.

flatten

Собирает конфигурацию уровня с отельный выходной каталог. При сборке конфигурации создается «плоский» каталог с содержимым всех уровней и удалением всех перекрывающихся заданий и файлов .bbappend для них. Возможно после этого потребуется некоторая очистка вручную, как описано ниже.

  • Не являющиеся заданиями файлы (например, исправления) переписываются и команда flatten выдает для них предупреждения.
  • Все, что выходит за пределы обычной установки уровня, добавляется в файл layer.conf. Используется лишь файл layer.conf уровня с наименьшим приоритетом.
  • Переписанные и добавленные элементы из файлов .bbappend должны быть очищены. Содержимое каждого файла .bbappend в конечном итоге попадает в «плоское» задание. Однако при наличии добавленных или измененных значений переменных потребуется самостоятельно привести их в порядок. Рассмотрим пример, где команда bitbake-layers добавляет строку #### bbappended … (чтобы понять, откуда берутся следующие строки).
     ...
     DESCRIPTION = "A useful utility"
     ...
     EXTRA_OECONF = "--enable-something"
     ...

     #### bbappended from meta-anotherlayer ####

     DESCRIPTION = "Customized utility"
     EXTRA_OECONF += "--enable-somethingelse"

В идеальном случае это следует привести к виду, показанному ниже.

     ...
     DESCRIPTION = "Customized utility"
     ...
     EXTRA_OECONF = "--enable-something --enable-somethingelse"
     ...

layerindex-fetch

Извлекает уровень из списка уровней вместе с зависимыми уровнями и добавляет их в файл conf/bblayers.conf.

layerindex-show-depends

Определяет зависимости уровня из списка уровней.

create-layer

Создает базовый уровень.

3.1.8. Создание базового уровня с помощью сценария bitbake-layers

Сценарий bitbake-layers с параметром create-layer упрощает создание нового уровня общего назначения. Для использования уровня в системе сборки OE нужно добавить этот уровень в конфигурационный файл bblayers.conf (см. 3.1.9. Добавление уровня с помощью сценария bitbake-layers). По умолчанию bitbake-layers create-layer создает уровень со следующими параметрами:

  • приоритет уровня 6;
  • каталог conf содержит файл layer.conf;
  • создается каталог recipes-example с подкаталогом example, содержащим файл задания example.bb;
  • файл COPYING.MIT с лицензией (сценарий предполагает использование лицензии MIT, типичной для большинства уровней), относящейся к содержимому уровня;
  • файл README с описанием содержимого нового уровня.

В простейшем случае для создания уровня можно использовать приведенную ниже команду, которая создает в текущем каталоге уровень, имя которого соответствует параметру your_layer_name.

$ bitbake-layers create-layer your_layer_name

Например, приведенная ниже команда создаст уровень meta-scottrif в домашнем каталоге.

     $ cd /usr/home
     $ bitbake-layers create-layer meta-scottrif
     NOTE: Starting bitbake server...
     Add your new layer with 'bitbake-layers add-layer meta-scottrif'

Если нужно установить для уровня приоритет, отличный от 6, можно использовать опцию ‐‐priority или отредактировать значение BBFILE_PRIORITY в файле conf/layer.conf после его создания сценарием. Если нужно изменить имя примера файла задания, его можно задать с помощью опции ‐‐example-recipe-name.

Простейшим способом разобраться с командой bitbake-layers create-layer является ее использование. Для получения справки о работе со сценарием введите команду

     $ bitbake-layers create-layer --help
     NOTE: Starting bitbake server...
     usage: bitbake-layers create-layer [-h] [--priority PRIORITY]
    [--example-recipe-name EXAMPLERECIPE]
    layerdir

     Create a basic layer

     positional arguments:
       layerdir  Layer directory to create

     optional arguments:
       -h, --helpshow this help message and exit
       --priority PRIORITY, -p PRIORITY
     Layer directory to create
       --example-recipe-name EXAMPLERECIPE, -e EXAMPLERECIPE
     Filename of the example recipe

3.1.9. Добавление уровня с помощью сценария bitbake-layers

Создав уровень, нужно добавить его в свой файл bblayers.conf. Это будет позволяет системе сборки OE узнать об этом уровне, чтобы искать в нем метаданные. Для добавления уровня служит команда bitbake-layers add-layer your_layer_name.

Ниже приведен пример добавления уровня meta-scottrif в файл конфигурации. После команды добавления уровня использована команда, показывающая уровни из вашего файла bblayers.conf.

$ bitbake-layers add-layer meta-scottrif
NOTE: Starting bitbake server...
Parsing recipes: 100% |##########################################################| Time: 0:00:49
Parsing of 1441 .bb files complete (0 cached, 1441 parsed). 2055 targets, 56 skipped, 0 masked, 0 errors.

$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer     path  priority
==========================================================================
meta      	/home/scottrif/poky/meta 5
meta-poky 	/home/scottrif/poky/meta-poky 5
meta-yocto-bsp	/home/scottrif/poky/meta-yocto-bsp 5
workspace 	/home/scottrif/poky/build/workspace 99
meta-scottrif	/home/scottrif/poky/build/meta-scottrif 6    

Добавление уровня в этот файлпозволяет системе сборки найти уровень в процессе сборки. Система сборки просматривает уровни от начала списка к концу.

3.2. Настройка образов

Образы можно настраивать с учетом реальных требований, как описано в этом параграфе.

3.2.1. Настройка с помощью local.conf

Одним из простейших способов настройки образа является добавление пакетов через файл local.conf. Поскольку область действия этого файла ограничена, метод обычно позволяет лишь добавлять пакеты и недостаточно гибок для создания своего настраиваемого образа. При добавлении пакетов с использованием локальных переменных нужно отдавать себе отчет в том, что эти изменения влияют на каждую сборку и, следовательно, на все создаваемые образы.

Для добавления пакета с использованием локального файла конфигурации служит переменная IMAGE_INSTALL с оператором _append.

     IMAGE_INSTALL_append = " strace"

Важно соблюдать показанный в примере синтаксис, в частности пробел перед именем добавляемого пакета, поскольку оператор _append пробелы (разделители) не добавляет. Кроме того, нужно использовать _append, а не оператор +=, если вы не хотите столкнуться с проблемой упорядочения. Показанный вариант безоговорочно добавляет значение в конец имеющегося списка, что позволяет предотвратить связанные с упорядочением проблемы в результате использования переменной в образах и файлах заданий с операторами вида ?=.

Как было отмечено, IMAGE_INSTALL_append влияет на все образы, но можно расширить синтаксис, задавая применение переменной лишь для конкретного образа в форме IMAGE_INSTALL_append_pn-core-image-minimal = » strace».

Можно добавлять пакеты похожим способом через переменную CORE_IMAGE_EXTRA_INSTALL, которая воздействует только на образы core-image-*.

3.2.2. Настройка с помощью IMAGE_FEATURES и EXTRA_IMAGE_FEATURES

Другим вариантом является использование переменных IMAGE_FEATURES и EXTRA_IMAGE_FEATURES. Эти переменные близки по назначению, лучше пользоваться IMAGE_FEATURES из задания и EXTRA_IMAGE_FEATURES из файла local.conf в каталоге сборки.

Разобраться с настройками поможет файл meta/classes/core-image.bbclass. Этот класс указывает доступные свойства IMAGE_FEATURES, большинство которых отображается на группы пакетов, а некоторые (например, debug-tweaks и read-only-rootfs) задают общие настройки конфигурации.

Содержимое IMAGE_FEATURES просматривается а затем свойства отображаются или настраиваются соответствующим образом. На основе этой информации система сборки автоматически добавляет нужные пакеты и конфигурации в переменную IMAGE_INSTALL. Фактически это включает дополнительные функции путем расширения классов или создания собственного класса для использования с файлами образов .bb.

Следует использовать переменную EXTRA_IMAGE_FEATURES из локального файла конфигурации. Использование отдельной области, откуда можно управлять свойствами через эту переменную поможет избежать переопределения свойств в задании для образа, которые указаны в переменной IMAGE_FEATURES. Значение переменной EXTRA_IMAGE_FEATURES добавляется к IMAGE_FEATURES в файле meta/conf/bitbake.conf.

Для иллюстрации этих возможностей рассмотрим пример выбора сервера SSH. YP включает два сервера SSH — Dropbear и OpenSSH. Первый является минимальным сервером SSH подходящим для сред с ограниченными ресурсами, а OpenSSH является широко распространенным стандартным сервером SSH. По умолчанию для образа core-image-sato настроено использование Dropbear, а образы core-image-full-cmdline и core-image-lsb включают OpenSSH. Образ core-image-minimal не поддерживает сервер SSH. Можно настроить свой образ и изменить принятые по умолчанию значения. Для этого следует изменить переменную IMAGE_FEATURES или EXTRA_IMAGE_FEATURES в файле local.conf, указав пакет ssh-server-dropbear или ssh-server-openssh. Полный список свойств образов, включенных в YP, приведен в разделе Images [3].

3.2.3. Настройка с помощью файлов .bb

Можно также настроить образ, создав свое задание, определяющее дополнительные программы для образа

     IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"

     inherit core-image    

Указание программ через пользовательское задание обеспечивает полный контроль содержимого образа. Важно указывать корректные имена пакетов в переменной IMAGE_INSTALL, используя нотацию OE, а не (например, glibc-dev, а не libc6-dev).

Другим вариантом создания своего образа служит копирование и изменение имеющегося образа. Например, можно создать образ на основе core-image-sato с добавлением пакета strace, скопировав файл meta/recipes-sato/images/core-image-sato.bb и добавив в конце копии строку IMAGE_INSTALL += «strace».

3.2.4. Настройка с помощью пользовательских групп пакетов

Для комплексных образов лучшим способом настройки является создание группы заданий, которая будет применяться при сборке образов. Примером такой группы служит meta/recipes-core/packagegroups/packagegroup-base.bb. В этом задании переменная PACKAGES указывает группы создаваемых пакетов. Оператор inherit packagegroup задает принятые по умолчанию значения и автоматически добавляет пакеты -dev, -dbg и -ptest для каждого пакета, указанного в PACKAGES. Пакеты с наследованием следует размещать в верхней части задания и обязательно до оператора PACKAGES. Для каждого пакета из PACKAGES можно использовать записи RDEPENDS и RRECOMMENDS для предоставления списков пакетов, которые следует включать в родительский пакет. Примеры этого имеются в задании packagegroup-base.bb.

Ниже приведен краткий пример, иллюстрирующий основные части.

     DESCRIPTION = "My Custom Package Groups"

     inherit packagegroup

     PACKAGES = "\
         packagegroup-custom-apps \
         packagegroup-custom-tools \
         "

     RDEPENDS_packagegroup-custom-apps = "\
         dropbear \
         portmap \
         psplash"

     RDEPENDS_packagegroup-custom-tools = "\
         oprofile \
         oprofileui-server \
         lttng-tools"

     RRECOMMENDS_packagegroup-custom-tools = "\
         kernel-module-oprofile"    

В этом примере создается две группы пакетов с указанием действительных и рекомендуемых зависимостей — packagegroup-custom-apps и packagegroup-custom-tools. Для сборки образа с использованием этой группы пакетов нужно добавить packagegroup-custom-apps и/или packagegroup-custom-tools в переменную IMAGE_INSTALL.

3.2.5. Настройка имени хоста для образа

По умолчанию настроенной имя хоста (/etc/hostname) в образе совпадает с именем машины. Например, для MACHINE = qemux86, настроенным именем хоста в файле /etc/hostname будет qemux86.

Можно изменить это имя, указав его в переменной hostname в задании base-files с помощью файла добавления или конфигурационного файла. Ниже приведен пример с файлом добавления.

     hostname="myhostname"

В файле конфигурации замена будет иметь вид hostname_pn-base-files = «myhostname».

Смена принятого по умолчанию значения hostname может быть полезна в нескольких случаях. Например, может потребоваться расширенное тестирования образа, где нужно будет отличать тестируемые варианты от типового. В таком случае можно сменить имя хоста, например, на testme. Если переменная не установлена, у образа не будет заданного по умолчанию в файловой системе имени, как показано ниже.

     hostname_pn-base-files = ""

Отсутствие заданного по умолчанию имени удобно в средах с динамическим назначением имен хостов.

3.3. Создание новых заданий

Задания (файлы .bb) являются важнейшими компонентами среды YP. Каждая программная компонента создается системой сборки OE на основе определяющего ее задания. В этом разделе описаны все аспекты работы с заданиями. Дополнительную информацию о работе с заданиями можно найти в разделе Required [3].

3.3.1. Обзор

На рисунке показан базовый процесс создания нового задания.


3.3.2. Нахождение или автоматическое создание базового задания

Всегда можно создать новое задание «с нуля», однако есть 3 варианта, ускоряющие подготовку новых заданий:

  • devtool addкоманда, помогающая создать задание и среду разработки;
  • recipetool create команда YP для автоматизированного создания заданий на основе файлов исходного кода;
  • имеющиеся задания можно скопировать и изменить в соответствии с задачами.

Синтаксис заданий описан в параграфе 3.3.23. Синтаксис заданий.

3.3.2.1. Создание с помощью devtool add

Команда devtool add использует такую же логику автоматического создания заданий, как описанная ниже команда recipetool create. Дополнительно devtool add организует окружение, упрощающее правку (patch) исходных кодов и внесение изменений в задания, которые часто требуются при добавлении заданий для сборки новой части кода. Полное описание команды devtool add приведено в разделе A Closer Look at devtool add [2].

3.3.2.2. Создание с помощью recipetool create

Команда recipetool create автоматизирует создание базового задания на основе набора файлов с исходным кодом. Когда можно извлечь или указать исходные файлы, команда будет создавать задание и автоматически настраивать все параметры сборки в нем. Например, приложение может создаваться с помощью autotools и подготовка базового задания с помощью recipetool приведет к включению в задание зависимостей, лицензионных требований и контрольных сумм.

Запуск команды выполняется из каталога сборки после выполнения сценария настройки окружения (oe-init-build-env). Для получения справки о работе с инструментом служит команда

     $ recipetool -h
     NOTE: Starting bitbake server...
     usage: recipetool [-d] [-q] [--color COLOR] [-h] <subcommand> ...

     OpenEmbedded recipe tool

     options:
       -d, --debug     Enable debug output
       -q, --quiet     Print only errors
       --color COLOR   Colorize output (where COLOR is auto, always, never)
       -h, --help      show this help message and exit

     subcommands:
       create          Create a new recipe
       newappend       Create a bbappend for the specified target in the specified
           layer
       setvar          Set a variable within a recipe
       appendfile      Create/update a bbappend to replace a target file
       appendsrcfiles  Create/update a bbappend to add or replace source files
       appendsrcfile   Create/update a bbappend to add or replace a source file
     Use recipetool <subcommand> --help to get help on a specific command

Команда recipetool create -o OUTFILE создает базовое задание с именем OUTFILE и корректно размещает его на уровне, содержащем исходные файлы.

Ниже приведен синтаксис для подготовки на базе кодов source задания, размещаемого на уровне исходного кода.

recipetool create -o OUTFILE source

Следующая команда создает задание с использованием кода, извлекаемого из source. Этот код помещается на свой уровень, указанный EXTERNALSRC.

recipetool create -o OUTFILE -x EXTERNALSRC source

Еще одна команда создает задание на основе source, указывая recipetool необходимость создания отладочной информации. Задание размещается в имеющемся уровне исходных кодов.

recipetool create -d -o OUTFILE source
3.3.2.3. Нахождение и использование похожего задания

Перед созданием нового задания зачастую полезно ознакомиться с имеющимися и выбрать среди них подходящее в качестве основы. Сообщества YP и OE поддерживают множество заданий, среди которых наверняка найдется подходящий образец. Список имеющихся заданий доступен по ссылке OpenEmbedded Layer Index.

Работа с имеющимся заданием и шаблоном служит логичным началом процесса. Ниже рассмотрены особенности обоих методов.

  • Поиск и изменение похожего задания подходит, когда вы хорошо знакомы с имеющимися заданиями, но мало полезен для новичков. Некоторый риск при использовании данного метода связан с возможным наличием в выбранном задании области, которая совсем не связана с вашими задачами и может потребоваться ее создание с нуля. Однако все такие риски связаны с недостаточным знакомством с имеющимися заданиями.
  • Использование шаблона задания. Если по какой-то причине вы не хотите использовать recipetool и не нашли подходящего в качестве образца задания, можно воспользоваться приведенной ниже структурой, включающей основные разделы нового задания.
         DESCRIPTION = ""
         HOMEPAGE = ""
         LICENSE = ""
         SECTION = ""
         DEPENDS = ""
         LIC_FILES_CHKSUM = ""
    
         SRC_URI = ""    

3.3.3. Сохранение и именование заданий

Базовое задание следует поместить на свой уровень и дать ему подходящее имя. Корректное размещение заданий позволит системе сборки OE находить их при использовании BitBake для обработки.

  • Сохранение заданий. Система сборки OE находит задания с помощью файла conf/layer.conf на вашем уровне и переменной BBFILES. Эта переменная задает путь поиска заданий для системы сборки, как показано ниже.
         BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
         ${LAYERDIR}/recipes-*/*/*.bbappend"

    Поэтому следует сохранять задания внутри своего уровня, чтобы их можно было найти. Информация о структуре уровней приведена в разделе 3.1. Уровни и их создание.

  • Именование заданий. При выборе имен для заданий используйте формат basename_version.bb.Используйте символы нижнего регистра и не включайте в имена зарезервированные суффиксы -native, -cross, -initial, -dev, пока это не обусловлено применением задания. Ниже приведено несколько примеров.
         cups_1.7.0.bb
         gawk_4.0.2.bb
         irssi_0.8.16-rc1.bb

3.3.4. Запуск сборки задания

Подготовка нового задания обычно происходит в несколько итераций, требующих использования BitBake для многократной обработки задания с целью нахождения и добавления информации в файл задания. Предположим, что вы воспользовались сценарием настройки среды сборки (oe-init-build-env) и текущим является сборочный каталог, а для обработки задания применяется BitBake. Для запуска достаточно указать базовое имя задания (basename).

$ bitbake basename

В процессе работы система сборки OE создает временный рабочий каталог для каждого задания (${WORKDIR}), в котором хранятся извлеченные файлы исходного кода, журналы работы (log), промежуточные файлы компиляции, файлы пакетов и т. п. Путь к временному рабочему каталогу каждого задания зависит от рабочего контекста. Проще всего узнать этот путь с помощью команды bitbake -e basename | grep ^WORKDIR=.

Предположим, например, что каталогом верхнего уровня для исходных кодов служит poky, сборочным каталогом — poky/build, а целевой системой является qemux86-poky-linux. Пусть задание называется foo_1.3.0.bb. В этом случае рабочим каталогом для сборки пакета будет poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0.

Внутри этого каталога можно найти такие поддкаталоги, как image, packages-split и temp. После завершения сборки можно рассмотреть их содержимое для оценки результатов сборки. Журналы сборки для каждого задания можно найти в каталоге temp этого задания (например, poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp). Файлы журналов будут названы log.taskname (например, log.do_configure, log.do_fetch, log.do_compile).

Дополнительная информация о процессе сборки приведена в разделе The Yocto Project Development Environment [1].

3.3.5. Извлечение кода

Первым делом задание должно указать способ извлечения исходных файлов. Выборка исходного кода определяется в основном переменной SRC_URI. Задание должно включать переменную SRC_URI, указывающую место размещения исходных кодов. Графическое представление мест размещения исходных кодов дано в разделе Sources [1].

Задача do_fetch использует префикс каждого элемента переменной SRC_URI для определения сборщика, применяемого для получения исходных кодов. Задача do_patch использует эту переменную после извлечения исходных кодов для применения правок (patch). Система сборки применяет FILESOVERRIDES для сканирования каталогов с локальными файлами, указанных в SRC_URI.

Переменная SRC_URI в задании должна указывать каждое уникальное место размещения исходного кода. Рекомендуется не задавать жестко пути в URL, указанных в SRC_URI, а пользоваться переменной ${PV}, которая сообщает сборщику версию, указанную именем файла задания. Такое указание версии упрощает обновления задания , сводя его к простому переименованию файла в соответствии с новой версией. Ниже приведен пример из задания meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb, содержащего исходные файлы из архива.

     SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"

Файлы, указанные в SRC_URI, имена которых имеют типовое расширение (например, .tar, .tar.gz, .tar.bz2, .zip), извлекаются автоматически задачей do_unpack. Другой пример указания файлов приведен в параграфе 3.3.21.2. Пакеты с автоматической настройкой.

Другим способом указания исходных файлов служит SCM. Для репозиториев Git нужно задать SRCREV и следует включить в PV номер выпуска с помощью SRCPV, как показано ниже для meta/recipes-kernel/blktrace/blktrace_git.bb

     SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385"

     PR = "r6"
     PV = "1.0.5+git${SRCPV}"

     SRC_URI = "git://git.kernel.dk/blktrace.git \
                file://ldflags.patch"    

Если SRC_URI содержит URL, указывающие отдельные файлы, извлеченные с удаленного сервера, который не является системой контроля версий, BitBake пытается проверить файлы по контрольным суммам из задания, чтобы убедиться в отсутствии изменений в файлах с момента подготовки задания. Применяются контрольные суммы SRC_URI[md5sum] и SRC_URI[sha256sum]. Если переменная SRC_URI включает несколько URL (кроме SCM URL), нужно обеспечить проверку md5 и sha256 для каждого URL. В таких случаях подставляется каждый URL как часть SRC_URI, а затем используется при проверке контрольных сумм, как показано ниже

     SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
    ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch"

     SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8"
     SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d"

     SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92"
     SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"    

Корректные значения md5 и sha256 могут быть доступны вместе с другими подписями (md5, sha1, sha256, GPG и т. п.) на странице загрузки исходных файлов. Поскольку система сборки OE поддерживает только sha256sum и md5sum, другие контрольные суммы придется проверять вручную.

Если при попытке сборки задания контрольные суммы SRC_URI не указаны или отличаются от указанных, система сборки будет выдавать ошибку для каждой пропущенной или неверной контрольной суммы. В сообщениях будет указываться реальная контрольная сумма файла. После обеспечения корректных контрольных сумм можно скопировать их в задание и запустить сборку снова.

Заключительный пример слегка взят из задания unicode/rxvt-unicode_9.20.bb. Оператор SRC_URI указывает множество файлов для задания — архивы, исправления, файлы рабочего стола и пиктограммы.

     SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
                file://xwc.patch \
                file://rxvt.desktop \
                file://rxvt.png"    

При указании локальных файлов с помощью file:// URI система сборки извлекает файлы с локальной машины. Пути задаются относительно переменной FILESPATH и поиск выполняется в каталогах в порядке ${BP}, ${BPN} и FILES. Каталоги предполагаются расположенными в каталоге, где размещается файл задания или добавления. Пример поиска приведен в параграфе 3.3.21.1. Пакет с одним файлом .c.

В первом примере был указан patch-файл. Такие файлы обычно имеют расширение .patch или .diff, но могут применять и суффиксы сжатых архивов, такие как diff.gz или patch.bz2. Система сборки будет автоматически применять исправления из таких файлов, как описано в параграфе 3.3.7. Применение исправлений для кода.

3.3.6. Распаковка кода

В процессе сборки задача do_unpack распаковывает исходные коды в каталог, указанный переменной ${S}. Если файлы исходных кодов загружались в виде архива, внутренняя структура которого соответствует соглашениям для каталога верхнего уровня ${BPN}-${PV}, установка S не требуется. Однако при указании в SRC_URI архива, не соблюдающего эти соглашения, или выборке файлов из SCM (скажем, Git или Subversion) задание должно указывать S. После извлечения файлов нужно убедиться в том, что каталог, указанный переменной ${S}, соответствует структуре исходных кодов.

3.3.7. Применение исправлений для кода

Иногда требуется после извлечения применить к нему исправления (patch). Все упомянутые в SRC_URI файлы .patch и .diff, а также архивы с такими файлами (например, .diff.gz) считаются исправлениями, которые задача do_patch применяет автоматически. Система сборки должна иметь возможность применять исправления с опцией -p1 (т. е. один уровень каталогов в пути удаляется). Если требуется удалять несколько уровней, их число указывается в опции striplevel для исправления в записи SRC_URI. Если исправление нужно применить в конкретном каталоге, не указанном в patch-файле, используется опция patchdir.

Как и всех локальные файлы, указанные в SRC_URI с помощью file://, patch-файлы следует размещать в каталоге с заданием, имя которого совпадает с базовым именем задания (BP и BPN) или FILES.

3.3.8. Лицензирование

В задании должны быть определены переменные LICENSE и LIC_FILES_CHKSUM.

LICENSE

Указывает лицензию для программ. Если лицензия не известна, следует найти нужную информацию в исходном коде программ. Обычно лицензия указывается в файле COPYING, LICENSE или README. Зачастую лицензия также указывается в начале файлов с исходным кодом. Если программа распространяется по лицензии GNU General Public License version 2, следует установить LICENSE = «GPLv2».

Имена лицензий в файле LICENSE не должны включать пробелы, поскольку пробелы служат разделителями имен. Для стандартных лицензий используются имена файлов из каталога meta/files/common-licenses/ или имена флагов SPDXLICENSEMAP в файле meta/conf/licenses.conf.

LIC_FILES_CHKSUM

Эту переменную система сборки OE применяет для контроля неизменности текста лицензии. При наличии изменений процесс сборки завершится ошибкой.

Нужно указывать все файлы лицензий, применимых к программе. В конце этапа настройки конфигурации процесс сборки проверяет контрольные суммы файлов с текстами лицензий и выдает ошибку при несоответствии. Дополнительная информация о установке переменной LIC_FILES_CHKSUM приведена в параграфе 3.32.1. Отслеживание изменений в лицензиях.

Для определения корректных контрольных сумм файлов лицензий можно указать эти файлы в переменной LIC_FILES_CHKSUM с произвольными строками md5 и запустить сборку программ. В сообщениях об ошибках будут указаны корректные контрольные суммы md5. Дополнительная информация о контрольных суммах приведена в параграфе 3.3.5. Извлечение кода.

Ниже приведен пример переменной для программы, имеющей файл COPYING.

     LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"

При попытке собрать программу система сборки выдаст сообщение об ошибке, содержащее корректную контрольную сумму, которую нужно подставить в показанную в примере строку до следующей сборки.

3.3.9. Зависимости

Большинство программных пакетов имеют короткий список пакетов, которые нужны им. Эти пакеты называют зависимостями и они делятся на две категории — зависимости при сборке и зависимости при работе. В задании зависимости при сборке указываются с помощью переменной DEPENDS, куда следует включать имена других заданий (есть нюансы). Важно задать зависимости при сборке в явном виде. Если этого не сделать, в результате параллельной работы BitBake могут возникать конфликты, когда зависимость будет видна в одной задаче (например, do_configure) и отсутствовать в другой (например, do_compile).

Другое соображение связано с тем, что сценарии настройки могут автоматически проверять дополнительные зависимости и включать при их обнаружении соответствующую функциональность. Это означает, для для получения детерминированных результатов и отсутствия конфликтов нужно явно указать эти зависимости или явно запретить упомянутые добавления конфигурационным сценариям. Если нужно сделать задание более полезным (например, при публикации уровня) вместо жесткого запрета функциональности можно использовать переменную PACKAGECONFIG, позволяющую легко включать или отключать функциональность и соответствующие зависимости другим людям.

Аналогичным способом указываются и зависимости при работе с помощью зависящих от пакета переменных RDEPENDS. Все зависящие от пакета переменные должны иметь имя пакета в качестве суффикса как переопределение. Поскольку имя основного пакета в задании совпадает с именем задания, которое можно узнать из переменной ${PN}, можно указывать зависимости для основного пакета в форме RDEPENDS_${PN}. Если пакет называется ${PN}-tools, переменная будет называться RDEPENDS_${PN}-tools и т. п..

Некоторые зависимости при работе задаются автоматически при упаковке. Такие зависимости включают все общие библиотеки (если пакет example включает libexample, а другой пакет mypackage — двоичные файлы, связанные с libexample, система сборки OE будет автоматически добавлять зависимость mypackage от example). Дополнительная информация о добавлении зависимостей приведена в разделе Automatically Added Runtime Dependencies [1].

3.3.10. Настройка конфигурации задания

Большинство программ включает те или иные средства настройки конфигурации перед сборкой. Обычно для этого применяется сценарий configure с определенными опциями или изменяется конфигурационный файл сборки. Начиная с выпуска YP 1.7, в части основных заданий двоичные сценарии настройки конфигурации были отключены по причине многочисленных ошибок с подстановками путей. Сейчас система сборки OE использует более надежный инструмент pkg-config. Список отключенных сценариев настройки приведен в разделе Binary Configuration Scripts Disabled [3].

Основной частью настройки конфигурации при сборке является проверка зависимостей и возможного включения свойств в результате этой проверки. Нужно задать все зависимости для сборки в переменной задания DEPENDS, указывая задания, требуемые зависимостями. Зависимости для сборки зачастую описаны в документации программ.

Ниже перечислены элементы настройки, применяемые в зависимости от способа сборки программ

Autotools

Если в исходных кодах имеется файл configure.ac, сборка основана на применении autotools и для настройки нужно изменять конфигурацию. В этом случае задание должно наследовать класс autotools и не будет включать задачу do_configure. Тем не менее внесение корректив возможно. Например, можно задать переменную EXTRA_OECONF или PACKAGECONFIG_CONFARGS для передачи параметров конфигурации задания.

Cmake

Если в исходном коде имеется файл CMakeLists.txt file, сборка выполняется с использованием Cmake. В этом случае может потребоваться внесение изменений в конфигурацию. При использовании Cmake задания должны наследовать класс cmake и не будут использовать задачу do_configure. Можно внести некоторые изменения с помощью переменной EXTRA_OECMAKE для передачи конфигурационных опций задания.

Прочее

Если исходные коды не включают файлов configure.ac и CMakeLists.txt, этого говорит о сборке программы с использованием методов, отличных от Autotools и CMake. В таких случаях обычно требуется обеспечить в задачу do_configure, если задание включает какие-либо настройки.

Если задание не использует Autotools или Cmake, настройка конфигурации может потребоваться и нужно понять, нужна ли она на самом деле. Может потребоваться редактирование файла Makefile или иного файла конфигурации, содержащего нужные для сборки опции. Иногда может потребоваться выполнение включенного в исходный код сценария настройки. В этом случае команда ./configure —help позволит увидеть доступные опции.

По завершении настройки конфигурации рекомендуется посмотреть файл log.do_configure, чтобы убедиться в установке нужных параметров и отсутствии дополнительных зависимостей при сборке, которые нужно добавить в DEPENDS. Например, если сценарий настройки нашел что-то, не упомянутое в DEPENDS, или не нашел нужного для обеспечения желаемой функциональности, нужно внести соответствующие добавления в DEPENDS. Просмотр журнала также может выявить элементы, которые были проверены и/или включены в конфигурацию, но не требуются, или не найдены DEPENDS, что может потребовать передачи дополнительных параметров сценарию настройки. Для просмотра полного списка параметров configure служит команда ./configure —help, вызванная из каталога ${S}.

3.3.11. Использование заголовочных файлов для интерфейса с устройствами

Если задание создает программу, которой нужно взаимодействовать с тем или иным устройством, или требуется API для пользовательского ядра, нужны соответствующие файлы заголовков. Ни при каких обстоятельствах недопустимо менять файл meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc, поскольку эти заголовочные файлы используются для сборки libc и не должны подвергаться рискам со стороны пользовательских или машинозависимых конфигураций. Настройка libc с измененными файлами заголовков будет влиять на все приложения, применяющие libc.

Корректным способом взаимодействия с устройством или пользовательским ядром является использование отдельного пакета, обеспечивающего дополнительные заголовки для драйвера или других уникальных интерфейсов. В этом случае данное приложение отвечает за создание зависимостей.

Предположим, что изменяется имеющийся заголовок, который добавляет управление вводом-выводом или поддержку сети. Если изменение используется небольшим числом программ, предоставление заголовку уникальной версии проще и оказывает меньшее влияние. А этом случае следует учитывать приведенные выше рекомендации.

Если по какой-то причине нужно изменить поведение libc и, следовательно, всех приложений в системе, нужно использовать файл .bbappend для изменения файла linux-kernel-headers.inc. Однако следует учесть, что изменения не должны быть машинозависимыми.

Рассмотрим вариант старого ядра, который требует применения старого libc ABI. Заголовки, установленные заданием, должны относиться к стандартному ядру, а не к пользовательскому. Для пользовательских заголовков ядра нужно получить их из переменной STAGING_KERNEL_DIR, указывающей каталог с заголовками, которые нужны для сборки внешних модулей. Задание должно включать do_configure[depends] += «virtual/kernel:do_shared_workdir».

3.3.12. Компиляция

В процессе сборки после извлечения, распаковки и настройки конфигурации исходного кода запускается задача do_compile. Если эта задача выполняется без ошибок, дополнительно ничего делать не нужно.

Однако при отказах в процессе компиляции приходится искать причины ошибок. При обнаружении неверных путей в конфигурационных файлах или невозможности найти библиотеки или файлы заголовков убедитесь в использовании надежного пакета pkg-config (параграф 3.3.10. Настройка конфигурации задания).

  • Отказы при параллельной сборке проявляются как чередующиеся ошибки или сообщения об отсутствии файлов или каталогов, которые должны быть созданы другой частью процесса сборки. Это может быть связано с некорректным порядком выполнения процесса сборки. Для решения проблемы следует обеспечить невыполненные зависимости в Makefile, создавшем Makefile сценарии или (обходной путь) отключить параллельную сборку, указав PARALLEL_MAKE = «» (см. раздел 3.30.12. Отладка конфликтов параллельной сборки).
  • Некорректное использование путей хоста может возникать при сборке заданий для целевой платформы или nativesdk. Ошибка возникает при использовании процессом компиляции некорректных заголовков, библиотек или иных файлов хост-системы при кросс-компиляции для целевой платформы. Для решения проблемы следует просмотреть файл log.do_compile, где нужно найти используемые пути хоста (/usr/include, /usr/lib и т. п.) и исправить соответствующие опции конфигурации или применить исправления.
  • Отказ при поиске нужных библиотек и заголовочных файлов. Если зависимости при сборке не выполняются по причине их отсутствия в DEPENDS или использования неверных путей поиска, процесс сборки завершается ошибкой. Система сборки в таких случаях указывает не найденные файлы. Для решения проблему нужно указать пропущенные зависимости или дополнительные параметры сценариев настройки конфигурации.Иногда нужно внести изменения в исходные коды для обеспечения корректных путей поиска. Если нужно указать пути поиска файлов из других заданий, размещенных в sysroot, следует использовать переменные системы сборки OE (например, STAGING_BINDIR, STAGING_INCDIR, STAGING_DATADIR и т. п.).

3.3.13. Инсталляция

Задача do_install в процессе работы копирует файлы сборки вместе с иерархией в места, отражающие их размещение на целевой платформе. Файлы копируются из каталогов ${S}, ${B} и ${WORKDIR} в каталог ${D} для создания структуры, которая должна появиться в целевой системе.

Сборка программ влияет на операции, требуемые для корректной установки. Ниже описаны действия, зависящие от способа сборки программ.

  • Autotools и Cmake. Если программы вашего задания собираются с помощью Autotools или CMake, система сборки OE знает, как их установить. Поэтому не требуется включать задачу do_install в задание, достаточно лишь убедиться в полноте сборки и отсутствии ошибок. Однако, если нужно установить дополнительные файлы, которые не учтены командой make install, следует использовать функцию do_install_append с командой install, как описано ниже.
  • Прочие (make install). В задании нужно определить функцию do_install, которая должна вызывать oe_runmake install и вероятно будет передавать ей целевой каталог. Способ передачи каталога зависит от файла Makefile (например, DESTDIR=${D}, PREFIX=${D}, INSTALLROOT=${D} и т. п.). Пример задания, использующего make install приведен в параграфе 3.3.21.3. Пакеты на основе Makefile.
  • Ручная установка. В задании нужно определить функцию do_install, которая должна использовать команду install -d для создания каталогов в ${D}. Когда каталоги созданы, функция может использовать команду install для установки программ в эти каталоги.Дополнительную информацию можно найти по ссылке.

Для сценариев, не использующих Autotools или CMake, нужно отслеживать инсталляцию, контролируя и исправляя возникающие ошибки. Нужно просматривать каталог ${D} (по умолчанию ${WORKDIR}/image) для проверки корректности установки всех файлов.

  • В процессе инсталляции может потребоваться изменение некоторых установленных файлов в соответствии с целевой платформой. Например, может потребоваться замена жестко заданных путей значениями подставляемых системой переменных (например, замена /usr/bin/ на ${bindir}). Если такие замены происходили в процессе do_install, нужно менять целевой файл после копирования, а не до него. Это гарантирует возможность повтора системой сборки задачи do_install при возникновении необходимости.
  • Задача oe_runmake, которая может запускаться напрямую или опосредованно через класса autotools и cmake, запускает команды make install параллельно. Иногда в файле Makefile могут отсутствовать зависимости между целями и будут возникать конфликты. При возникновении сбоев в процессе выполнения do_install можно отключить параллельную работу, задав PARALLEL_MAKEINST = «».

3.3.14. Включение системных служб

Для включения службы, которая будет запускаться при загрузке и работать в фоновом режиме, нужно указать в задании дополнительные определения. Если добавляется служба, а сценарий ее запуска или файл самого сервиса не установлен, нужно обеспечить соответствующую инсталляцию с использованием задачи do_install_append. Если задание уже включает эту функцию, следует добавить данные в конец строки, а не добавлять другую функцию.

При настройке инсталляции служб нужно выполнить операции, которые обычно делает команда make install. Иными словами, нужно убедиться, что при инсталляции данные упорядочиваются как в целевой системе.

Система сборки OE обеспечивает несколько вариантов запуска служб при загрузке.

  • SysVinit является менеджером системы и служб, который управляет инициализацией системой init для контроля базовых функций. Программа init является первой программой, запускаемой ядром Linux при загрузке системы. Затем эта программа управляет запуском, работой и отключением всех прочих программ.Для включения службы с помощью SysVinit задание должно наследовать класс update-rc.d, который помогает безопасно устанавливать пакеты на целевой платформе. В задании нужно установить переменные INITSCRIPT_PACKAGES, INITSCRIPT_NAME и INITSCRIPT_PARAMS.
  • systemd является демоном управления системой, предназначенным для замены SysVinit и обеспечения более эффективного управления службами (см. http://freedesktop.org/wiki/Software/systemd/). Для управления службами с помощью systemd задание должно наследовать класс systemd, информацию о котором можно найти в файле systemd.bbclass дерева исходных кодов.

3.3.15. Подготовка пакетов

Успешная подготовка пакетов включает автоматизированные процессы системы сборки OE и действия пользователя.

  • Разделение файлов. Задача do_package делит файлы, созданные заданием на логические компоненты. Даже программа из одного двоичного файла может включать отладочные символы, документацию и другие компоненты, которые следует разделять.
  • Запуск тестов QA. Класс insane добавляет в процесс генерации пакета этап создания тестов качества системой сборки OE. На этом этапе выполняется множество проверок, чтобы гарантировать отсутствие в выводе типичных проблем, возникающих при работе. Информация об этих проверках приведена в описании класса insane и разделе QA Error and Warning Messages [3].
  • Проверка пакетов вручную. После сборки программы нужно убедиться в корректности пакетов. Проверяется каталог ${WORKDIR}/packages-split на предмет наличия ожидаемых файлов. При обнаружении проблем следует проверить корректность установки PACKAGES, FILES, do_install(_append) и т. п..
  • Разделение приложения на несколько пакетов. См. параграф 3.3.21.4. Разделение программы на несколько пакетов.
  • инсталляция сценария пост-установки. См. параграф 3.3.19. Сценарии пост-установки.
  • Указание архитектуры пакета. В зависимости от того, что собирает задание и как оно настроено может быть важна маркировка пакетов как относящихся к конкретной машине или архитектуре. По умолчанию пакеты применимы к любой машине с архитектурой, указанной для цели. Когда задание создает машинозависимые пакеты (например, значение MACHINE передается сценарию configure или применяется patch-файл для определенной машины), нужно помечать пакеты, указывая PACKAGE_ARCH = «${MACHINE_ARCH}» в задании.Если задание создает пакеты, которые не привязаны к определенной машине или архитектуре (например, файлы сценариев или конфигурации), следует использовать класс allarch, добавляя в задание inherit allarch.Проверка корректности архитектуры пакета не является критичной для первых сборок задания. Однако она важна для обеспечения гарантий надлежащей перестройки задания при смене конфигурации. Особенно важно контролировать установку на платформе подходящих пакетов в случаях сборки для нескольких целей.

3.3.16. Совместное использование файлов заданиями

Заданиям зачастую нужны файлы из других заданий сборочного хоста. Например, приложение может быть связано с общей библиотекой и ему нужен доступ к самой библиотеке и файлам заголовков. Этот доступ осуществляется через файловую систему sysroot. Каждое задание имеет в рабочем каталоге две системы sysroot, одна из которых служит для целевых файлов (recipe-sysroot), другая для естественных файлов хоста сборки (recipe-sysroot-native).

Заданиям не следует заполнять sysroot напрямую (т. е. записывать туда файлы). Вместо этого файлы должны устанавливаться в стандартные места задачей do_install внутри каталога ${D}. Причина этого заключается в том, что практически все файлы sysroot указываются в манифестах для контроля последующего изменения или удаления заданий. Поэтому система sysroot способна избавляться от устаревших файлов.

Часть файлов, установленных задачей do_install, используется задачей do_populate_sysroot в соответствии с переменной SYSROOT_DIRS для автоматического заполнения sysroot. Список каталогов sysroot можно менять. Например, можно добавить каталог /opt в форме SYSROOT_DIRS += «/opt». Более подробное описание задачи do_populate_sysroot и связанных с ней функций приведено в описании класса staging.

3.3.17. Использование виртуальных провайдеров

Если до сборки известно, что одну функциональность представляет несколько разных заданий, можно выбрать виртуального провайдера (virtual/*) в качестве замены реального, который будет определен в процессе сборки. Базовым вариантом применения виртуальных провайдеров являются задания для сборки ядра. Предположим наличие трех таких заданий, у которых значения PN отображаются на kernel-big, kernel-mid и kernel-small. Кроме того, каждое из этих заданий своим способом использует оператор PROVIDES, указывая свою возможность предоставить элемент virtual/kernel. Одним из способов прохождения класса kernel является

PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }"

Любое задание, наследующее класс kernel, использует оператор PROVIDES, который указывает, что задание может обеспечить элемент virtual/kernel.

Когда нужно собрать образ и выбрать для него ядро, можно настроить сборку с нужным ядром с помощью переменной PREFERRED_PROVIDER. Рассмотрим в качестве примера файл x86-base.inc, задающий конфигурацию машины (MACHINE). Этот включаемый файл задает для всех машин x86 использование ядра linux-yocto. Это задается приведенными ниже строками.

     PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
     PREFERRED_VERSION_linux-yocto ??= "4.15%"    

При использовании виртуального провайдера не нужно жестко задавать имя задания в качестве зависимости при сборке. Можно использовать переменную DEPENDS для указания зависимости от virtual/kernel, например, DEPENDS = «virtual/kernel».

В процессе сборки система OE выберет нужное задание для зависимости virtual/kernel на основе переменной PREFERRED_PROVIDER. Для использования упомянутого выше компактного ядра можно указать PREFERRED_PROVIDER_virtual/kernel ??= «kernel-small».

Любое задание, где PROVIDES содержит элемент virtual/*, который не выбран с помощью PREFERRED_PROVIDER, собираться не будет. Предотвращение сборки таких заданий обычно желательно, поскольку цель этого механизма заключается в выборе одного из взаимоисключающих провайдеров. Примеры виртуальных провайдеров даны ниже.

  • virtual/kernel обеспечивает имя задания для ядра, используемого при сборке образа ядра.
  • virtual/bootloader обеспечивает имя загрузчика (bootloader), используемого при сборке образа ядра.
  • virtual/mesa обеспечивает gbm.pc.
  • virtual/egl обеспечивает egl.pc и возможно wayland-egl.pc.
  • virtual/libgl обеспечивает gl.pc (libGL).
  • virtual/libgles1 обеспечивает glesv1_cm.pc (libGLESv1_CM).
  • virtual/libgles2 обеспечивает glesv2.pc (libGLESv2).

3.3.18. Корректные версии предварительных выпусков

Иногда имя задания может приводить к проблемам с версиями при обновлении до финального выпуска задания. Рассмотрим, например, файл irssi_0.8.16-rc1.bb recipe из примеров параграфа 3.3.3. Сохранение и именование заданий. Это задание указывает предварительный выпуск (rc1), а в окончательном выпуске файл получает имя irssi_0.8.16.bb. Версия 0.8.16-rc1 сменилась на 0.8.16, что представляется уменьшением номера с точки зрения менеджера пакетов, поэтому полученные в результате пакеты не будут корректно обновляться.

Для корректного сравнения версий рекомендуется для PV в задании установить previous_version+current_version. Можно использовать дополнительную переменную, чтобы текущая версия была доступна везде. Например,

     REALPV = "0.8.16-rc1"
     PV = "0.8.15+${REALPV}"    

3.3.19. Сценарии пост-установки

Сценарии пост-установки работают сразу после инсталляции пакета не целевой платформе или при создании образа, когда пакет включен в образ. Для включения в пакет такого сценария нужно добавить функцию pkg_postinst_PACKAGENAME() в файл задания (.bb), заменив PACKAGENAME именем соответствующего пакета. Для применения сценария пост-установки к основному пакету задания (обычно это нужно), вместо PACKAGENAME указывается ${PN}.

Структура функции пост-установки показана ниже.

pkg_postinst_PACKAGENAME() { # Выполняемые команды } 

Сценарий, заданный в функции пост-установки, вызывается при создании корневой файловой системы. При успешном выполнении сценария пакет помечается как установленный. Если возникает отказ сценария, пакет помечается как нераспакованный и сценарий повторяется при следующей загрузке.

Всем пост-установочным сценариям RPM на целевой платформе следует возвращать код завершения 0. RPM не разрешает отличные от 0 коды возврата и менеджер пакетов RPM в таких случаях выдает отказ при установке на целевой платформе.

Иногда нужно отложить сценарий пост-установки до первой перезагрузки (например, сценарию может требоваться выполнение на самом устройстве). В таких случаях нужно явно указать отложенные до перезагрузки сценарии, для чего можно использовать функцию pkg_postinst_ontarget() или вызвать postinst-intercepts defer_to_first_boot из pkg_postinst(). Любой отказ сценария pkg_postinst() (включая exit 1) вызывает ошибку задачи do_rootfs.

При наличии заданий, использующих функцию pkg_postinst и требующих нестандартных естественных инструментов, которые имеют зависимости при создании корневой файловой системы, нужно указывать эти инструменты в переменной задания PACKAGE_WRITE_DEPS. Если переменная не используется, задание может отсутствовать и выполнение пост-установочного сценария будет отложено до перезагрузки, что нежелательно, а на файловых системах с доступом только для чтения — невозможно.

Существует эквивалентная поддержка сценариев pre-install, pre-uninstall и post-uninstall с помощью функций pkg_preinst, pkg_prerm и pkg_postrm, соответственно. Эти сценарии работают так же, как pkg_postinst за исключением того, что они запускаются в разные моменты. Кроме того, с учетом момента запуска эти сценарии не применимы во время создания образа, как pkg_postinst.

3.3.20. Тестирование

Финальным этапом задания является проверка корректности работы сборки. Для тестирования добавьте выходные пакеты в образ и проверьте их на целевой платформе. Информация о добавлении пакетов в образы приведена в разделе 3.2. Настройка образов.

3.3.21. Примеры

Для иллюстрирования процесса написания заданий в этом разделе приведено несколько примеров:

  • задания, использующие локальные файлы;
  • задания, использующие автоматически настраиваемые пакеты;
  • задания, использующие пакеты с Makefile;
  • расщепление приложения на несколько пакетов;
  • добавление двоичных файлов в образ.
3.3.21.1. Пакет с одним файлом .c

Сборка приложения из одного локального файл требует задания, где этот файл указан в переменной SRC_URI. Кроме того, нужно вручную создать задачи do_compile и do_install. Переменная S определяет каталог с исходным кодом, который задается в качестве WORKDIR в данном случае. BitBake использует этот каталог для сборки.

     SUMMARY = "Simple helloworld application"
     SECTION = "examples"
     LICENSE = "MIT"
     LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

     SRC_URI = "file://helloworld.c"

     S = "${WORKDIR}"

     do_compile() {
        ${CC} helloworld.c -o helloworld
     }

     do_install() {
        install -d ${D}${bindir}
        install -m 0755 helloworld ${D}${bindir}
     }

По умолчанию собираются пакеты helloworld, helloworld-dbg и helloworld-dev. Информация о настройке процесса упаковки приведена в параграфе 3.3.21.4. Разделение программы на несколько пакетов.

3.3.21.2. Пакеты с автоматической настройкой

Приложения, использующие инструменты автоматической настройки, такие как autoconf и automake, требуют от заданий указать архив исходных кодов в переменной SRC_URI и наследовать класс autotools, который содержит определения всех этапов сборки приложений с автоматической настройкой. Результат сборки автоматически собирается в пакет. Если приложение использует NLS для поддержки разных языков, создаются языковые пакеты (по одному на язык). Ниже приведен пример на основе задания hello_2.3.bb.

     SUMMARY = "GNU Helloworld application"
     SECTION = "examples"
     LICENSE = "GPLv2+"
     LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"

     SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"

     inherit autotools gettext 

Переменная LIC_FILES_CHKSUM служит для отслеживания изменений в лицензиях, как описано в разделе Tracking License Changes [1]. Задания для автоматически настраиваемых приложений можно создавать по аналогии с предыдущим параграфом.

3.3.21.3. Пакеты на основе Makefile

Приложения, использующие GNU, также требуют от заданий указать архив исходных кодов в переменной SRC_URI. Этап do_compile добавлять не нужно, поскольку BitBake по умолчанию запускает команду make для компиляции приложения. Если нужны дополнительные опции make, следует задать их в переменной EXTRA_OEMAKE или PACKAGECONFIG_CONFARGS. BitBake передает эти опции при вызове GNU make. Отметим, что задача do_install по-прежнему требуется, иначе BitBake будет запускать пустую задачу do_install.

Некоторые приложения могут требовать передачи компилятору дополнительных параметров (например, путь к дополнительным файлам заголовков). Это можно обеспечить, добавив параметры в переменную CFLAGS в форме CFLAGS_prepend = «-I ${S}/include «.

Ниже приведен пример приложения mtd-utils использующего Makefile.

SUMMARY = "Tools for managing memory technology devices"
SECTION = "base"
DEPENDS = "zlib lzo e2fsprogs util-linux"
HOMEPAGE = "http://www.linux-mtd.infradead.org/"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"

# Use the latest version at 26 Oct, 2013
SRCREV = "9f107132a6a073cce37434ca9cda6917dd8d866b"
SRC_URI = "git://git.infradead.org/mtd-utils.git \
    file://add-exclusion-to-mkfs-jffs2-git-2.patch \
"

PV = "1.5.1+git${SRCPV}"

S = "${WORKDIR}/git"

EXTRA_OEMAKE = "'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' 'BUILDDIR=${S}'"

do_install () {
 oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} INCLUDEDIR=${includedir}
}

PACKAGES =+ "mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-misc"

FILES_mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
FILES_mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
FILES_mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"
3.3.21.4. Разделение программы на несколько пакетов

Чтобы разделить приложение на несколько пакетов, можно использовать переменные PACKAGES и FILES. Ниже приведен пример разделения задания libxpm, которое по умолчанию создает один пакет с библиотекой и несколькими исполняемыми файлами. Можно разделить задание, выделив исполняемые файлы в отдельные пакеты.

     require xorg-lib-common.inc
     SUMMARY = "Xpm: X Pixmap extension library"
     LICENSE = "BSD"
     LIC_FILES_CHKSUM = "file://COPYING;md5=51f4270b012ecd4ab1a164f5f4ed6cf7"
     DEPENDS += "libxext libsm libxt"
     PE = "1"

     XORG_PN = "libXpm"

     PACKAGES =+ "sxpm cxpm"
     FILES_cxpm = "${bindir}/cxpm"
     FILES_sxpm = "${bindir}/sxpm"

В этом примере исполняемые файлы sxpm и cxpm вынесены в отдельные пакеты. Поскольку bindir помещается по умолчанию в основной пакет PN, дополнительные пакеты помещены в начало переменной PACKAGES. Это создает дополнительные переменные FILES_*, содержащие информацию о файлах и каталогах, включаемых в пакеты. Включенные предыдущими пакетами файлы и каталоги пропускаются последующими, поэтому указанные в переменных файлы не попадут в основной пакет PN.

3.3.21.5. Упаковка внешних двоичных пакетов

Иногда нужно добавить в образ собранные заранее двоичные файлы. Например, при наличии фирменного (proprietary) кода, созданного отдельным подразделением компании, эти программы могут оказаться нужны для образа, создаваемого в системе сборки OE. Поскольку имеются лишь двоичные файлы без исходных кодов, невозможно использовать типовые задания для сборки, которым нужно указать исходный код в SRC_URI и компилировать его.

Одним из вариантов является упаковка двоичных файлов и установка их в образ. В общем случае это не лучшее решение, поскольку может мешать воспроизведению сборки и создать в будущем проблемы совместимости с ABI. Однако иногда других вариантов просто нет. Простейшим способом является подготовка задания, использующего класс bin_package с указанием принятого по умолчанию размещения результатов сборки. В большинстве случаев класс bin_package «пропускает» этапы настройки и компиляции, а также настраивает извлечение пакетов из указанных мест. В частности, этот класс устанавливает noexec для задач do_configure и do_compile, задает FILES_${PN} = «/» для выборки файлов и настраивает задачу do_install для копирования файлов из ${S} в ${D}. Класс bin_package хорошо работает, когда извлеченные в ${S} файлы уже размещены в соответствии с их расположением на целевой платформе. Информация о переменных FILES, PN, S и D приведена в [3].

  • Использование DEPENDS является хорошей идеей для компонент, распространяемых в двоичной форме, и зачастую требуется для общих библиотек. Для библиотек указание зависимостей в DEPENDS обеспечивает доступность этих библиотек при подготовке sysroot, когда другие задания ссылаются на эти библиотеки.
  • Использование DEPENDS также позволяет задать автоматическое добавление зависимостей при работе программ (см. раздел Automatically Added Runtime Dependencies [1]).

Если нет возможности использовать класс bin_package, нужно обеспечить выполнение приведенных ниже операций.

  • Подготовить задание, где do_configure и do_compile не делают ничего. Обычно для этого достаточно просто не указывать задачи, поскольку принятые по умолчанию реализации нечего не делают, пока не найден файл Makefile в ${S}. Если каталог ${S} может включать файл Makefile или нужно наследовать класс, который заменит do_configure и do_compile настроенными вариантами, можно использовать флаг [noexec] для включения задач в no-ops.
         do_configure[noexec] = "1"
         do_compile[noexec] = "1"    

    В отличие от удаления задач, использование флага сохранит цепочку зависимостей из задач do_fetch, do_unpack и do_patch для задачи do_install.

  • Убедиться в корректной установке двоичных файлов задачей do_install.
  • Убедиться, что переменная FILES (обычно FILES_${PN}) указывает устанавливаемые файлы. Это зависит от места установки файлов с учетом принятого по умолчанию размещения.

3.3.22. Рекомендации по стилям заданий

При подготовке заданий разумно следовать сложившемуся стилю. На странице OpenEmbedded Styleguide даны рекомендации по предпочтительному стилю заданий. Реальные задания обычно слегка отклоняются от рекомендуемого стиля, однако стремление следовать стилю является хорошим тоном. Отсутствие пробелов вокруг операторов = при назначении или некорректный порядок компонент задания часто воспринимаются как дурной тон.

3.3.23. Синтаксис заданий

Для подготовки задания важно разобраться с их синтаксисом. Ниже приведен обзор основных элементов файла заданий BitBake, более полная документация содержится в разделе Syntax and Operators [6].

  • Назначение и изменение переменных. Назначение может быть статическим текстом или включать содержимое других переменных. Кроме того, поддерживаются операторы добавления в начало или в конец переменной.
         S = "${WORKDIR}/postfix-${PV}"
         CFLAGS += "-DNO_ASM"
         SRC_URI_append = " file://fixup.patch"
  • Функции задают последовательность выполняемых операций. Обычно функции применяются для переопределения принятой по умолчанию реализации функции задачи или ее дополнения (т. е. добавления в начало или конец имеющейся функции). Стандартные функции используют стиль командного процессора sh, но поддерживается также доступ к переменным и внутренним методам OE. Ниже приведен пример функции из задания sed.
         do_install () {
             autotools_do_install
             install -d ${D}${base_bindir}
             mv ${D}${bindir}/sed ${D}${base_bindir}/sed
             rmdir ${D}${bindir}/
         }

    Можно реализовать новые функции, которые вызываются между имеющимися задачами, если эти функции не заменяют и не дополняют принятых по умолчанию функций. Можно реализовать функции на языке Python.

  • Ключевые слова. Задания BitBake используют немного ключевых слов. Они служат для включения базовых функций (inherit), загрузки частей задания из других файлов (include и require), а также для экспорта переменных в среду (export).
         export POSTCONF = "${STAGING_BINDIR}/postconf"
         inherit autoconf
         require otherfile.inc
  • Комментарии (#). Все строки, начинающиеся с символа #, считаются комментариями и не обрабатываются.
         # Это комментарий

Далее представлены наиболее важные и распространенный части синтаксиса заданий. Дополнительная информация о синтаксисе приведена в разделе Syntax and Operators [6].

  • Продолжение строки (\). Символ \ служит для разделения длинной строки на несколько более коротких.
    VAR = "Это длинная \
    строка"

    Этот символ нельзя заменить другим.

  • Использование переменных (${VARNAME}). Синтаксис ${VARNAME} служит для доступа к содержимому переменных, как показано ниже
         SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"

    Важно понимать, что значение переменной, выраженное в такой форме, не подставляется автоматически сразу. Преобразование выражений происходит позже по запросу (обычно при выполнении ссылающейся на переменную функции). Это обеспечивает гарантию того, что значения больше подходят для контекста, в котором они реально применяются. В редких случаях, когда требуется сразу раскрыть выражение, можно использовать оператор := вместо = при назначении.

  • Назначения в кавычках value«). Присваиваемые значения следует указывать в двойных кавычках, например,
         VAR1 = "${OTHERVAR}"
         VAR2 = "Версия ${PV}"
  • Условное назначение (?=) используется для присваивания переменной значения исключительно в случае его отсутствия в данный момент. Для условного (мягкого) назначения используется оператор ?=). Обычно такие назначения применяются в файле local.conf для переменных, которым разрешено приходить извне. Например, VAR1 ?= «New value» назначит переменной VAR1 значение «New value», если в этот момент она не имеет значения. Иначе переменная VAR1 сохранит свое значение как в приведенном ниже примере.
    VAR1 = "Original value"
    VAR1 ?= "New value"
  • Добавление в конце (+=). Оператор += добавляет значение в конце имеющейся переменной, отделяя новое значение от имеющегося пробелом. Например, SRC_URI += «file://fix-makefile.patch».
  • Добавление в начале (=+). Оператор =+ позволяет добавить значение в начало имеющейся переменной с пробелом между добавленным и прежним значением. Например, VAR =+ «Starts».
  • Добавление в конце (_append). Оператор _append добавляет значение к имеющейся переменной без включения символа пробела. Оператор применяется после всех операторов += и =+, а также после назначений с помощью =. Чтобы добавленное значение не сливалось с имеющимся, следует явно указывать пробел в начале добавляемого значения, например, SRC_URI_append = » file://fix-makefile.patch».Оператор _append можно использовать в переопределениях, чтобы изменение относилось лишь к указанной цели или машине. Например, SRC_URI_append_sh4 = » file://fix-makefile.patch».
  • Добавление в начале (_prepend). Оператор _prepend добавляет значение к имеющейся переменной без включения символа пробела. Оператор применяется после всех операторов += и =+, а также после назначений с помощью =. Чтобы добавленное значение не сливалось с имеющимся, следует явно указывать пробел в начале добавляемого значения, например, CFLAGS_prepend = «-I${S}/myincludes «.Оператор _prepend можно использовать в переопределениях, чтобы изменение относилось лишь к указанной цели или машине. Например, CFLAGS_prepend_sh4 = «-I${S}/myincludes «.
  • Переопределение может служить для условной установки значения, обычно в зависимости от способа сборки задания. Например, для установки в переменной KBRANCH значения standard/base для любого целевого значения MACHINE, кроме qemuarm, где следует установить standard/arm-versatile-926ejs, можно задать
         KBRANCH = "standard/base"
         KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"

    Переопределения применяются также для разделения вариантов переменной. Например, при установке таких переменных как FILES и RDEPENDS, которая зависит от собираемых заданием пакетов, всегда следует применять переопределение, задающее имя пакета.

  • Вставка пробелов в начале строки. Для отступа в начале строки следует использовать пробелы, а не символы табуляции. Для функций оболочки ((shell) в настоящее время работают оба варианта, однако это просто правило YP по использованию табуляции в shell-функциях. В некоторых слоях (уровнях) может применяться иная трактовка отступов.
  • Комплексные операции Python. Для более сложной обработки (например, поиск и замена в переменной) можно использовать при назначении переменных код Python, указываемого с помощью синтаксиса ${@python_code}, например, SRC_URI = «ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar(‘PV’,1).replace(‘.’, »)}.tgz.
  • Синтаксис shell-функций. Эти функции создаются как сценарии командного процессора для описания последовательности выполняемых операций. Следует проверить работу сценария с базовым командным процессором sh и отсутствие потребности в использовании bash или иного процессора. Это относится и к применяемым системным утилитам (например, sed, grep, awk). При наличии сомнений следует проверить функцию с несколькими реализациями, включая BusyBox.

3.4. Добавление машины

Добавление новой машины в YP достаточно просто. В этом разделе описано, как добавить машины по аналогии с имеющимися в YP. Добавление полностью новой архитектуры может потребовать внесения изменений в gcc/glibc и информацию о сайте, но это выходит за рамки данного руководства. Полное описание процессов добавления новой машины приведено в разделе Creating a New BSP Layer Using the bitbake-layers Script [5].

3.4.1. Добавление конфигурационного файла машины

Для добавления машины нужно создать конфигурационный файл машины в каталоге conf/machine нужного уровня. Этот файл будет включать данные о добавляемом устройстве. Система сборки OE использует корневое имя конфигурационного файла машины для ссылок на нее. Например, при конфигурационном файле crownbay.conf система сборки будет называть машину crownbay.

Наиболее важными переменными в конфигурационном файле машины или включаемых в него файлах являются:

Могут также потребоваться переменные:

В качестве образца можно взять один из файлов .conf каталога meta-yocto-bsp/conf/machine/.

3.4.2. Добавление ядра для машины

Система сборки OE должна быть способна собрать ядро для машины, что требует создать специальное задания для ядра или расширить имеющееся. Примеры заданий для ядер можно найти в каталоге исходных кодов (meta/recipes-kernel/linux) и использовать в качестве образца.

При подготовке нового задания для ядра применяются обычные правила установки SRC_URI. Таким образом, нужно указать все требуемые исправления (patch) и установить в S местоположение исходного кода. Нужно создать задачу do_configure для настройки распакованного ядра с использованием файла defconfig. Это можно сделать с помощью команды make defconfig или путем копирования подходящего файла defconfig и запуска команды make oldconfig. При использовании наследуемого ядра и, возможно, некоторых файлов linux-*.inc большая часть остальных функций будет централизована и принятые по умолчанию настройки классов обычно будут работать хорошо.

При расширении имеющегося задания обычно следует добавить подходящий файл defconfig. Файл нужно добавлять в каталог, похожий на каталоги размещения файлов defconfig других машин в данном задании для ядра. Это можно сделать путем включения файла с SRC_URI и добавления машины в выражение COMPATIBLE_MACHINE, например, COMPATIBLE_MACHINE = ‘(qemux86|qemumips)’.

Дополнительная информация о файлах defconfig приведена в разделе Changing the Configuration [7].

3.4.3. Добавление файла аппаратной конфигурации

Файл аппаратной конфигурации обеспечивает информацию о целевой платформе, для которой будет собираться образ, а также сведения, которые система сборки не может получить из других источников, таких как ядро. Примерами данных, включаемых в этот файл, служат ориентация буфера кадров, наличие клавиатуры, ее расположение относительно экрана, а также экранное разрешение.

Система сборки в большинстве случаев подразумевает разумные значения, однако может потребоваться создание файла machconfig в каталоге meta/recipes-bsp/formfactor/files, содержащем данные для конкретных машин, таких как qemuarm и qemux86. Информацию о доступных и заданных по умолчанию значениях можно найти в файле meta/recipes-bsp/formfactor/files/config указанного каталога. Ниже приведен пример для машины qemuarm.

     HAVE_TOUCHSCREEN=1
     HAVE_KEYBOARD=1

     DISPLAY_CAN_ROTATE=0
     DISPLAY_ORIENTATION=0
     #DISPLAY_WIDTH_PIXELS=640
     #DISPLAY_HEIGHT_PIXELS=480
     #DISPLAY_BPP=16
     DISPLAY_DPI=150
     DISPLAY_SUBPIXEL_ORDER=vrgb    

3.5. Обновление заданий

С течением времени разработчики публикуют новые версии программ, собираемых заданиями для уровней. Рекомендуется поддерживать актуальность кода таких заданий. Есть несколько способов обновления заданий, но сначала разумно проверить текущее состояние. Сделать это можно с помощью команды devtool check-upgrade-status (см. раздел Checking on the Upgrade Status of a Recipe [3]).

Далее рассмотрены три варианта обновления заданий — автоматическое, полуавтоматическое и ручное.

3.5.1. Использование AUH

Утилита AUH9 работает с системой сборки OE для автоматической генерации обновлений на основе новых опубликованных версий кода. AUH позволяет создать службу автоматического обновления и может уведомлять о результатах по электронной почте. AUH может обновлять несколько заданий в один прием. Можно также протестировать результаты сборки и интеграфии, используя образы, сохраненные на диске, с возможность. Отправки результатов теста сопровождающим по электронной почте. Кроме того, AUH создает фиксации Git (commit) с сообщениями в дереве уровня для просмотра внесенных изменений.

В некоторых случаях не следует применять AUH для обновления, используя взамен команду devtool upgrade или обновление вручную.

  • AUH не может завершить последовательность обновлений, что обычно является результатом невозможности автоматического переноса пользовательских исправлений в новую версию. Проблему решает обновление вручную.
  • Требуется более полный контроль процесса обновления, например, при наличии специальных тестов.

Ниже перечислены этапы автоматического обновления с помощью AUH.

  1. Настройка хоста разработки для работы с YP в соответствии с разделом 2.2. Подготовка сборочного хоста.
  2. Настройка Git. Утилита AUH требует настройки конфигурации Git, поскольку этот пакет служит для сохранения изменений. Это требует указать пользователя Git и электронную почту. Для просмотра конфигурации служит команда git config —list. Если имя пользователя и электронная почта еще не заданы, следует ввести команды
    $ git config --global user.name some_name $ git config --global user.email username@domain.com
  3. Клонирование репозитория AUH. Для использования AUH нужно клонировать репозиторий на хост разработки, как показано ниже.
         $ git clone git://git.yoctoproject.org/auto-upgrade-helper
         Cloning into 'auto-upgrade-helper'...
         remote: Counting objects: 768, done.
         remote: Compressing objects: 100% (300/300), done.
         remote: Total 768 (delta 499), reused 703 (delta 434)
         Receiving objects: 100% (768/768), 191.47 KiB | 98.00 KiB/s, done.
         Resolving deltas: 100% (499/499), done.
         Checking connectivity... done.

    AUH сейчас является частью репозиториев OpenEmbedded-Core (OE-Core) и Poky.

  4. Создание выделенного каталога сборки. Сценарий oe-init-build-env создает свежий каталог сборки, который используется лишь для запуска утилиты AUH.
    $ cd ~/poky
         $ source oe-init-build-env your_AUH_build_directory

    Использование имеющегося каталога сборки и его конфигурации не рекомендуется, поскольку имеющиеся настройки могут помешать работе AUH.

  5. Создание локальной конфигурации. Нужно включить некоторые настройки в файл local.conf созданного AUH каталога сборки, как показано ниже.
    • Если нужно включить историю сборки (3.28.1. Управление историей сборки), нужно добавить в файл приведенные ниже строки.
           INHERIT =+ "buildhistory"
           BUILDHISTORY_COMMIT = "1"

      При такой конфигурации после успешного обновления появится файл diff в подкаталоге upgrade-helper/work/recipe/buildhistory-diff.txt каталога сборки.

    • Если нужно добавить тестирование с помощью класса testimage, следует добавить строку
           INHERIT += "testimage"

      Если у дистрибутиве по умолчанию отключено свойство ptest (как в Poky) нужно добавить строку

           DISTRO_FEATURES_append = " ptest"
  6. Необязательный запуск vncserver. При работе без графического интерфейса X11 нужно запустить vncserver.
         $ vncserver :1
         $ export DISPLAY=:1
  7. Создание и редактирование файла конфигурации AUH. Нужно иметь файл upgrade-helper/upgrade-helper.conf в каталоге сборки. Образец файла можно найти в репозитории AUH и воспользоваться им для создания своего файла. Например, если нужно сохранять историю сборки, следует включить ее в upgrade-helper.conf.Если используется принятый по умолчанию файл maintainers.inc из дистрибутива Poky, размещенный в meta-yocto, не установлено maintainers_whitelist или global_maintainer_override в файле upgrade-helper.conf и задана опция -e all в командной строке AUH, утилита автоматически будет отправлять почтовые сообщения всем сопровождающим. Следует избегать этого.

Далее приведены примеры использования утилиты AUH.

  • Обновление конкретного задания — upgrade-helper.py recipe_name. Например, для обновления xmodmap можно ввести команду upgrade-helper.py xmodmap.
  • Обновление конкретного задания до указанной версииupgrade-helper.py recipe_name -t version. Например, для обновления xmodmap до версии 1.2.3 служит команда upgrade-helper.py xmodmap -t 1.2.3.
  • Обновление всех заданий до последних версий без уведомления сопровождающих — upgrade-helper.py all.
  • Обновление всех заданий до последних версий с уведомлением сопровождающих upgrade-helper.py -e all.

После запуска утилиты AUH можно посмотреть результаты в каталоге сборки AUH ${BUILDDIR}/upgrade-helper/timestamp. Утилита AUH также создает фиксации обновления заданий после успешного обновления в дереве уровня.

Можно настроить регулярный запуск AUH из задания cron. Пример этого представлен в файле weeklyjob.sh.

3.5.2. Использование devtool upgrade

Другим методом обновления заданий является команда devtool upgrade, подробно описанная в разделе Use devtool upgrade to Create a Version of the Recipe that Supports a Newer Version of the Software [2]. Справку о параметрах можно получить по команде devtool upgrade -h. Если нужно лишь узнать версию находящегося в разработке задания без его реального обновления, следует применять команду devtool latest-version recipe_name.

Как было отмечено в описании AUH, команда devtool upgrade менее автоматизирована, нежели AUH. В частности, devtool upgrade работает лишь с одним заданием, которое указано в командной строке, не может выполнять тестирование сборки и интеграции, а также автоматически создавать фиксацию (commit) изменений в дереве исходных кодов. Несмотря на эти ограничения, devtool upgrade обновляет файл задания до новой версии и пытается совместить пользовательские правки с patch-файлами репозитория. AUH на деле использует devtool upgrade, будучи своего рода «оболочкой» для devtool upgrade.

Типичный пример использования предполагает применение Git для клонирования репозитория, который будет применяться для сборки. Поскольку задание было создано раньше, уровень уже имеется в вашей конфигурации. Если же уровня нет, его можно легко добавить с помощью сценария bitbake-layers. Предположим, например, использование задания nano.bb с уровня meta-oe в репозитории meta-openembedded, также клонирование уровня в каталог /home/scottrif/meta-openembedded. Приведенная ниже команда, запущенная из каталога сборки, добавит уровень в конфигурацию сборки (${BUILDDIR}/conf/bblayers.conf):

$ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
NOTE: Starting bitbake server...
Parsing recipes: 100% |##########################################| Time: 0:00:55
Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
Removing 12 recipes from the x86_64 sysroot: 100% |##############| Time: 0:00:00
Removing 1 recipes from the x86_64_i586 sysroot: 100% |##########| Time: 0:00:00
Removing 5 recipes from the i586 sysroot: 100% |#################| Time: 0:00:00
Removing 5 recipes from the qemux86 sysroot: 100% |##############| Time: 0:00:00    

Предположим, что задание nano.bb в репозитории разработки имеет версию 2.9.3, а в локальном — 2.7.4. Приведенная ниже команда, запущенная из каталога сборки, автоматически обновит задание (опция -V не обязательна и при ее отсутствии devtool upgrade выполнит обновление до последней версии).

$ devtool upgrade nano -V 2.9.3
NOTE: Starting bitbake server...
NOTE: Creating workspace layer in /home/scottrif/poky/build/workspace
Parsing recipes: 100% |##########################################| Time: 0:00:46
Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Extracting current version source...
NOTE: Resolving any missing task queue dependencies
...
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 74 tasks of which 72 didn't need to be rerun and all succeeded.
Adding changed files: 100% |#####################################| Time: 0:00:00
NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb    

В продолжение примера используем команду devtool build для сборки обновленного задания.

$ devtool build nano
NOTE: Starting bitbake server...
Loading cache: 100% |################################################################################################| Time: 0:00:01
Loaded 2040 entries from dependency cache.
Parsing recipes: 100% |##############################################################################################| Time: 0:00:00
Parsing of 1432 .bb files complete (1431 cached, 1 parsed). 2041 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
...
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.    

В рабочем процессе devtool upgrade имеется возможность развернуть и протестировать вновь собранные программы. Однако в нашем примере команда devtool finish очищает рабочее пространство при очистке исходных кодов. Обычно это означает использование Git для подготовки и представления изменений, внесенных при обновлении. Как только дерево будет очищено, можно очистить остальное с помощью приведенной ниже команды из каталога ${BUILDDIR}/workspace/sources/nano.

$ devtool finish nano meta-oe
NOTE: Starting bitbake server...
Loading cache: 100% |################################################################################################| Time: 0:00:00
Loaded 2040 entries from dependency cache.
Parsing recipes: 100% |##############################################################################################| Time: 0:00:01
Parsing of 1432 .bb files complete (1431 cached, 1 parsed). 2041 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch
NOTE: Updating recipe nano_2.9.3.bb
NOTE: Removing file /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb
NOTE: Moving recipe file to /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano
NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually    

Команда devtool finish очищает рабочее пространство и создает patch-файл на основе фиксаций (commit). Инструмент помещает все patch-файлы обратно в дерево исходного кода (каталог nano в данном случае).

3.5.3. Обновление заданий вручную

Если по какой-то причине обновление с помощью AUH или команды devtool upgrade не подходит, можно вручную отредактировать файлы задания для обновления версии. Обновление вручную множества заданий требует значительных усилий и времени, этапы процесса кратко описаны ниже.

  1. Смена версии. Следует переименовать задание с учетом версии (т. е. изменить PV в имени задания). Если версия не включена в имя измените значение, как это делается для PV в самом задании.
  2. Обновление SRCREV при необходимости. Если исходные коды задания получены с помощью Git или иной системы контроля версий, следует обновить SRCREV с указанием хеша фиксации для новой версии.
  3. Сборка программ. Соберите программу с помощью BitBake. Возможные отказы при сборке указаны ниже.
    • Операторы лицензирования для новой версии изменены. В этом случае следует просмотреть изменния в лицензировании и при необходимости обновить переменные LICENSE и LIC_FILES_CHKSUM. Изменения в лицензиях зачастую малозначимы, например, может измениться год в авторских правах (copyright).
    • Пользовательские изменения (patch) в старой версии могут не подойти для новой. В таких случаях нужно найти причину отказа. Исправления могут оказаться ненужными в новой версии, если проблема, вызвавшая их, была решена. Если правки нужны, но не работают, нужно изменить их для новой версии.
  1. Необязательная сборка для разной архитектуры. После сборки новой программы для одной архитектуры можно проверить другую, изменив переменную MACHINE. Это важно для публикуемых заданий.
  2. Проверка журнала обновлений и заметок к выпускам в репозитории. Просмотр упомянутого позволяет узнать о новых функциях и совместимости с прежними версиями. Это поможет при определении нужных действий.
  3. Необязательное создание и проверка загружаемого образа путем загрузки на реальном устройстве.
  4. Фиксация изменений в репозитории уровня. После успешной сборки и тестирования можно создать фиксацию (commit) для всех изменений на уровне, содержащем обновленное задание.

3.6. Поиск временных исходных кодов

Во время разработки может представиться полезным изменить временный исходный код используемый для сборки пакетов. Например, это может потребоваться при экспериментах для внесения правок (patch). После изначальной сборки пакеты можно итеративно настроить исходный код из каталога сборки, а затем форсировать повторную компиляцию и быстрое тестирование измененного кода. Когда решение будет найдено, можно сохранить внесенные изменения в форме правок (patch).

Во время сборки распакованный временный исходный код используется заданиями для сборки пакетов, доступный в сборочном каталоге, заданном переменной S. Ниже используется принятое по умолчанию значение S, указанное в файле meta/conf/bitbake.conf дерева исходных кодов, S = «${WORKDIR}/${BP}». Многие задания переопределяют S, например, задания, получающие исходный код с помощью Git, обычно устанавливают S = ${WORKDIR}/git.

BP представляет базовое имя задания, включающее имя и версию в форме BP = «${BPN}-${PV}». Путь к рабочему каталогу задания (WORKDIR) определяется как ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}.

Реальные каталоги зависят от нескольких переменных:

  • TMPDIRвыходной каталог верхнего уровня для сборки;
  • MULTIMACH_TARGET_SYSидентификатор целевой системы;
  • PN имя задания;
  • EXTENDPE эпоха (если PE не задана, что нормально для большинства заданий, значение EXTENDPE пусто);
  • PVверсия задания;
  • PRревизия (пересмотр) задания.

Предположим, например, каталог исходных кодов верхнего уровня poky, принятый по умолчанию каталог сборки poky/build и целевую систему qemux86-poky-linux. Кроме того, предположим, что задание названо foo_1.3.0.bb. В этом случае рабочим каталогом системы сборки будет poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0.

3.7. Использование Quilt

Quiltэто мощный инструмент для фиксации изменений исходного кода без наличия чистого дерева кода. В этом параграфе рассмотрен типовой процесс, который можно применять для изменения исходного кода, тестирования изменений и их сохранения в форме patch-файлов с помощью Quilt. В части сохранения изменений при очистке задания или включении rm_work процесс devtool, описанный в [2] является более надежным, чем использование Quilt.

Ниже приведены общие этапы работы с Quilt.

  1. Поиск исходного кода. Временный исходный код, используемый системой сборки OE, хранится в каталоге сборки. Поиск каталога с временным кодом для конкретного пакета рассмотрен в параграфе 3.6. Поиск временных исходных кодов.
  2. Смена рабочего каталога. Нужно перейти в каталог с временным исходным кодом, заданный переменной S.
  3. Создание правок (patch). Перед изменением исходного кода нужно создать patch-файл с помощью команды quilt new my_changes.patch.
  4. Уведомление Quilt и добавление файлов. После создания patch-файла нужно уведомить Quilt о файлах, которые планируется редактировать. Эти файлы могут быть добавлены к созданным правкам с помощью команды вида quilt add file1.c file2.c file3.c.
  5. Редактирование файлов. Отредактируйте указанные ранее файлы.
  6. Тестирование изменений. После редактирования исходного кода простейшим способом проверки внесенных изменений служит запуск задачи do_compile командой bitbake -c compile -f package. Опция -f или —force задает выполнение указанной в команде задачи. При возникновении проблем следует внести в исходный код соответствующие правки и повторить процедуру. Все изменения, внесенный во временные исходные коды, будут утеряны при запуске задачи do_clean или do_cleanall с помощью BitBake (команда bitbake -c clean package или bitbake -c cleanall package). Правки будут утеряны также при использовании функции rm_work, как описано в параграфе 3.21. Экономия дискового пространства при сборке.
  7. Создание patch-файла. После получения желаемых результатов правки нужно использовать Quilt для создания финального patch-файла со всеми внесенными изменениями. Для этого служит команда quilt refresh, после выполнения которой файл my_changes.patch будет включать все правки, внесенные в файлы file1.c, file2.c и file3.c. Файл правок будет размещен в каталоге patches/ дерева исходных кодов (S).
  8. Копирование patch-файла. Для простоты следует скопировать файл правок в каталог files, который можно создать в том же каталоге, где размещен файл задания (.bb) или добавления (.bbappend). Это позволит системе сборки OE найти файл правок. Затем patch-файл следует указать в переменной SRC_URI вашего задания, например, SRC_URI += «file://my_changes.patch».

3.8. Использование среды devshell

При отладке некоторых команд или редактировании пакетов может быть полезна оболочка devshell, при вызове которой запускаются все задачи для указанной цели, вплоть до do_patch. Затем открывается новая консоль с текущим каталогом ${S} (исходный код). В этой консоли сохраняются все переменные среды OE, относящиеся к сборке, и можно пользоваться такими командами, как configure и make. Команды выполняются как в системе сборки OE, поэтому могут быть полезны для отладки или подготовки программы к использованию в системе сборки OE. Например, для использования devshell с целью matchbox-desktop может служить команда bitbake matchbox-desktop -c devshell, которая откроет терминал в среде сборки OE. Тип командного процессора задает переменная OE_TERMINAL. Для терминала:

  • переменная PATH включает инструменты кросс-разработки;
  • переменные pkgconfig находят нужные файлы .pc;
  • команда configure находит файлы сайта YP и другие нужные файлы.

В этой среде можно вызывать команды configure или compile как при работе в системе сборки OE. Рабочим каталогом служит каталог исходных кодов (S).

Для запуска вручную из devshell нужной задачи служат сценарии run.* из каталога ${WORKDIR}/temp (например, run.do_configure.pid). Если сценария для задачи нет, что бывает в случае пропуска задачи в кэше sstate, можно создать задачу за пределами devshell с помощью команды bitbake -c task.

  • Выполнение сценариев run.* и выполнение задач в BitBake идентично, т. е. запуск сценария запускает задачу так же, как при использовании bitbake -c command.
  • Любой сценарий run.*, не имеющий расширения .pid, является символьной ссылкой на свежую версию файла.

Механизм devshell позволяет попасть в среду выполнения задач BitBake, поэтому все команды должны вызываться так же, как это делает BitBake. Это означает предоставление соответствующих опций кросс-компиляции и т. п.

По окончании работы с devshell следует использовать команду exit или просто закрыть терминальное окно.

  • При работе в devshell нужно указывать полное имя компилятора (например, arm-poky-linux-gnueabi-gcc), а не просто gcc. Это относится и к приложениям binutils, libtool и т. п. BitBake устанавливает переменные окружения, такие как CC, чтобы команда make находила нужные инструменты.
  • Среда devshell поддерживает пересылку X11 и другие подобные функции.

3.9. Использование среды разработки Python

Подобно использованию devshell, описанному выше, можно работать в интерактивной среде разработки Python. При отладке некоторых команд и редактировании пакетов devpyshell может служить полезным инструментом. При вызове devpyshell запускаются все задачи для указанной цели, вплоть до do_patch в новом терминальном окне. Важные объекты и код Python доступны как при работе с задачами BitBake (в частности, хранилище данных ‘d’). Ниже приведены некоторые полезные команды для работы с хранилищем данных и вызова функций.

     pydevshell> d.getVar("STAGING_DIR")
     '/media/build1/poky/build/tmp/sysroots'
     pydevshell> d.getVar("STAGING_DIR")
     '${TMPDIR}/sysroots'
     pydevshell> d.setVar("FOO", "bar")
     pydevshell> d.getVar("FOO")
     'bar'
     pydevshell> d.delVar("FOO")
     pydevshell> d.getVar("FOO")
     pydevshell> bb.build.exec_func("do_unpack", d)
     pydevshell>

Команды выполняются как в системе сборки OE, поэтому могут применяться для отладки и подготовки программ к сборке в системе OE. Ниже приведен пример использования devpyshell для цели matchbox-desktop.

     $ bitbake matchbox-desktop -c devpyshell

Эта команда открывает терминальное окно с интерактивным интерпретатором Python в среде сборки OE. Тип командного процессора задает переменная OE_TERMINAL. По завершении работы с devpyshell следует ввести команду exit, нажать клавиши Ctrl+d или просто закрыть терминальное окно.

3.10. Сборка

В этом разделе описаны различные процедуры сборки, включая простые варианты, целевые системы с несколькими конфигурациями, сборку образов и т. п.

3.10.1. Сборка простого образа

В среде разработки нужно собирать образ при каждом изменении поддерживаемого оборудования, добавлении или изменении системных библиотек, а также служб, с которыми связаны зависимости. Имеется несколько методов сборки образов в YP. В этом параграфе рассматриваются основные этапы сборки простого образа с использованием BitBake на сборочном хосте Linux.

  • Информация о работе с интерфейсом Toaster приведена в [8].
  • Сборка образов с использованием devtool описана в разделе Using devtool in Your SDK Workflow [2].
  • Пример быстрой сборки образа в системе OE приведен в [4].

Процесс сборки создает весь дистрибутив Linux из исходных кодов и помещает его в каталог tmp/deploy/images внутри сборочного каталога. Подробное описание процесса сборки с использованием BitBake дано в разделе Images [1].


На рисунке и в приведенном ниже списке приведен обзор процесса сборки.

  1. Организация хоста для поддержки разработки с использованием YP, как описано в главе Глава 2. Настройка YP.
  2. Инициализация среды сборки с помощью сценария oe-init-build-env по команде source oe-init-build-env [build_dir].При использовании сценария инициализации система сборки OE создает build в качестве принятого по умолчанию каталога сборки в текущем каталоге, из которого запущен сценарий. Аргумент build_dir позволяет задать иной каталог сборки. Общепринято использовать разные каталоги сборки для каждой цели. Например, ~/build/x86 для qemux86 и ~/build/arm для qemuarm.
  3. Проверка корректности файла conf/local.conf в каталоге с учетом реальных задач. Этот файл задает многие аспекты среды сборки, включая архитектуру машине в переменной MACHINE, формат пакетов для этой сборки (PACKAGE_CLASSES), и централизованный каталог загрузки архивов в переменной DL_DIR.
  4. Сборка образа с использованием команды bitbake target [6]. Параметр target указывает имя задания для сборки. Базовыми целями являются образы из каталогов meta/recipes-core/images, meta/recipes-sato/images и т. п. в каталоге исходных кодов. Параметр target может также указывать имя задания для определенного набора программ, такого как BusyBox. Более подробные сведения о поддерживаемых системой образах даны в разделе Images [3].Например, по команде bitbake core-image-minimal будет собран образ core-image-minimal.После сборки образа его зачастую нужно установить. Образы и ядра, создаваемые системой сборки OE помещаются в каталог tmp/deploy/images внутри каталога сборки. Информация о запуске собранных образов, таких как qemux86 и qemuarm приведена в [2], установка образов рассматривается в описаниях плат и машин.

3.10.2. Сборка образов для нескольких платформ с разными конфигурациями

Можно использовать одну команду bitbake для сборки нескольких образов или пакетов для разных целей, где каждому образу или пакету нужна своя конфигурация. Такое вариант сборки называют иногда multiconfigs. В этом параграфе описана организация среды для сборки разных конфигураций и учет зависимостей кросс-сборки для конфигураций.

3.10.2.1. Настройка и запуск сборки с несколькими конфигурациями

Для сборки нескольких конфигураций нужно задать конфигурацию для каждой цели, используя файл параллельной конфигурации в каталоге сборки, следуя требуемой иерархии файлов. Кроме того, нужно включить использование сборки нескольких конфигураций в файле local.conf.

  • Создание отдельных файлов конфигурации. Нужно создать конфигурационный файл для каждого собираемого задания. По меньшей мере каждый такой файл должен задавать машину и временный каталог, используемый BitBake для сборки. Опыт диктует создание не перекрывающихся временных каталогов для сборки, однако можно использовать общий временный каталог TMPDIR. Например, при сборке двух конфигураций для одной машины (MACHINE) qemux86 с дистрибутивами poky и poky-lsb целесообразно примянать общий каталог TMPDIR.Ниже показаны требуемые операторы в файле конфигурации qemux86 с временным каталогом tmpmultix86.
         MACHINE="qemux86"
         TMPDIR="${TOPDIR}/tmpmultix86"    

    Файлы конфигурации должны размещаться в определенном месте, а именно в подкаталоге multiconfig каталога conf. На рисунке показан пример с двумя конфигурационными файлами для x86 и arm в каталоге multiconfig.


    Использование такой иерархии обусловлено тем, что переменная BBPATH не создается, пока не будут проанализированы уровни. Поэтому использование заранее подготовленного файла конфигурации невозможно, если он не находится в текущем рабочем каталоге.

  • Добавление переменной BitBake для нескольких конфигураций в локальный файл конфигурации. Переменная BBMULTICONFIG в файле conf/local.conf задает каждый файл конфигурации. В приведенном выше примере эта переменная имеет вид BBMULTICONFIG = «x86 arm».
  • Запуск BitBake с помощью команды вида
    $ bitbake [multiconfig:multiconfigname:]target [[[multiconfig:multiconfigname:]target] ... ]

    Для приведенного выше примера команда будет иметь вид

         $ bitbake multiconfig:x86:core-image-minimal multiconfig:arm:core-image-sato

    В результате будет собран образ core-image-minimal, заданный файлом x86.conf, и образ core-image-sato, заданный arm.conf.

Поддержка сборки нескольких конфигураций в выпуске YP 2.7.1 (Warrior) не включает оптимизации общего состояния (sstate), поэтому при использовании одного объекта несколько раз создается несколько каталогов TMPDIR и сборка использует имеющийся кэш sstate или запускается заново.

3.10.2.2. Включение зависимостей при сборке нескольких конфигураций

Иногда могут возникать зависимости между целями (multiconfig) при сборке нескольких конфигураций. Предположим, например, что при сборке образа core-image-sato для x86 нужна корневая файловая система arm. Это может быть связано с тем, что задача do_image в core-image-sato зависит от выполнения задачи do_rootfs в core-image-minimal. Для включения зависимостей при сборке нескольких конфигураций их нужно объявить в задании как task_or_package[mcdepends] = «multiconfig:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend«.

Рассмотрим в качестве примера конфигурацию из предыдущего параграфа. В этом случае нужно в задание для образа core-image-sato добавить строку do_image[mcdepends] = «multiconfig:x86:arm:core-image-minimal:do_rootfs». В этом примере в качестве from_multiconfig служит x86, а в качестве to_multiconfig — arm. Задачей, от которой зависит do_image, является do_rootfs из задания core-image-minimal, связанного с arm.

После указания зависимости можно собрать образ x86 с помощью команды bitbake multiconfig:x86:core-image-sato. Команда выполняет все задачи, требуемые при создании образа core-image-sato для x86. В результате задания зависимости BitBake выполняет также задачу do_rootfs для arm.

Наличие задания, зависимого от корневой файловой системы другого задания может показаться бессмысленным. Рассмотрим это на примере оператора в задании core-image-sato.

     do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_image"

В этом случае BitBake нужно создать образ core-image-minimal для сборки arm, поскольку от него зависит сборка x86. В результате того, что x86 и arm включены во множественную конфигурацию и имеют раздельные конфигурационные файлы, BitBake помещает результаты сборки в соответствующие временные каталоги (TMPDIR).

3.10.3. Сборка образа initramfs

Образ первичного RAM-диска (initramfs) обеспечивает временную корневую файловую систему на раннем этапе инициализации (например, загрузка модулей, требуемых для нахождения и монтирования корневой системы).

Образ initramfs является «наследником» initrd и использует архив cpio на исходной файловой системе для загрузки в память при запуске Linux. Поскольку Linux использует содержимое архива в процессе инициализации, в образ initramfs нужно включать все драйверы и инструменты, нужные для монтирования окончательной корневой файловой системы.

Ниже перечислены этапы создания образа initramfs.

  1. Подготовка задания для initramfs. Можно воспользоваться заданием core-image-minimal-initramfs.bb из каталога meta/recipes-core в дереве исходных кодов как примером.
  2. Решение вопроса о встраивании образа initramfs в образ ядра. Если нужно объединить образ initramfs с образом ядра, следует задать INITRAMFS_IMAGE_BUNDLE = «1» в файле local.conf и установить переменную INITRAMFS_IMAGE в задании для сборки ядра. Рекомендуется объединять образы ядра и initramfs для предотвращения зацикливания зависимостей при включении в образ initramfs модулей ядра. Установка флага INITRAMFS_IMAGE_BUNDLE ведет к распаковке образа initramfs в каталог ${B}/usr/. Распакованный образ initramfs передается в Makefile ядра через переменную CONFIG_INITRAMFS_SOURCE, что позволяет встроить образ initramfs в ядро. Если образ initramfs не встраивается в образ ядра, это означает использование initrd. Создание initrd выполняется в основном через переменные INITRD_IMAGE, INITRD_LIVE и INITRD_IMAGE_LIVE (см. описание image-live.bbclass).
  3. Добавление элементов в initramfs через задания. При добавлении элементов initramfs следует использовать переменную PACKAGE_INSTALL, а не IMAGE_INSTALL, поскольку это обеспечивает более прямой контроль дополнений по сравнению с принятыми по умолчанию настройками классов image и core-image.
  4. Сборка образов ядра и initramfs. Ядро собирается с использованием BitBake. Поскольку задание для ядра зависит от initramfs, образ initramfs собирается и связывается с ядром, если установлена переменная INITRAMFS_IMAGE_BUNDLE, как указано выше.

3.10.4. Сборка миниатюрной системы

Компактные дистрибутивы могут обеспечивать ряд преимуществ, таких как меньшие потребности в памяти (снижение цены), повышение производительности за счет эффективного кэширования, снижение энергопотребления за счет уменьшения размера памяти, ускорение загрузки и снижение расходов на разработку. Примерами таких систем в реальном мире являются цифровые камеры, медицинское оборудование и т. п.

В этом параграфе приведена информация о способах сокращения размера дистрибутива по сравнению с poky-tiny, занимающим около 5 Мегабайт.

3.10.4.1. Обзор

Ниже представлены рассмотренные в соответствующих параграфах этапы снижения размера корневой файловой системы для обеспечения быстрой загрузки в сочетании с требуемой функциональностью без использования начального RAM-диска.

  • 3.10.4.2. Цели и принципы
  • 3.10.4.3. Влияние компонент на размер образа
  • 3.10.4.4. Минимизация корневой файловой системы
  • 3.10.4.5. Минимизация ядра
  • 3.10.4.6. Исключение требований к управлению пакетами
  • 3.10.4.7. Другие способы снижения размера
  • 3.10.4.8. Итерации процесса
3.10.4.2. Цели и принципы

Ниже приведен список вопросов, которые нужно решить при создании компактных дистрибутивов:

  • определение требуемого размера (например, ядро меньше 1 Мбайт и корневая файловая система не больше 3 Мбайт);
  • определение областей, занимающих большую часть пространства для концентрации усилий по сокращению;
  • отказ от внесения сложных изменений для достижения цели;
  • использование специфичных для устройства опций;
  • работа с отдельным уровнем для изоляции изменений (см. раздел 3.1. Уровни и их создание).
3.10.4.3. Влияние компонент на размер образа

Проще всего начать с создания своего дистрибутива. Можно воспользоваться в качестве примера имеющимся в YP дистрибутивом poky-tiny, для чего следует установить для переменной DISTRO в файле local.conf значение «poky-tiny», как описано в разделе 3.19. Создание своего дистрибутива.

Понимание концепций работы с памятью позволит уменьшить размер системы. Память включает статические, динамические и временные разделы. Статическая память — это разделы TEXT (код), DATA (инициализированные данные в коде) и BSS (неинициализированные данные). Динамическая память выделяется в процессе работы для стека, хэш-таблиц и т. п. Временная память включает области для распаковки ядра и функций __init__ и освобождается по завершении загрузки.

Для просмотра текущих размеров ядра и корневой файловой системы в каталоге scripts/tiny/ дерева исходных кодов есть два полезных сценария:

  • ksize.py определяет размер компонент собранного ядра;
  • dirsize.py определяет размер компонент корневой файловой системы.

Еще один сценарий и команда помогают организовать фрагменты конфигурации и увидеть зависимости файлов.

  • merge_config.sh помогает управлять конфигурационными файлами и фрагментами конфигурации ядра. Сценарий позволяет объединять фрагменты конфигурации, а также создавать переопределения и выдает предупреждения о пропущенных опциях. Это хорошо подходит для итеративной настройки конфигурации и создания конфигурационных файлов для разных машин без дублирования процессов.Сценарий является частью репозитория Linux Yocto (linux-yocto-3.14, linux-yocto-3.10, linux-yocto-3.8 и т. п.) и хранится в каталоге scripts/kconfig. Дополнительная информация о фрагментах конфигурации приведена в разделе Creating Configuration Fragments [7].
  • bitbake -u taskexp -g bitbake_target открывает Dependency Explorer для просмотра зависимостей. Понимание зависимостей позволяет принять обоснованные решения при исключении компонент ядра и корневой файловой системы.
3.10.4.4. Минимизация корневой файловой системы

Корневая файловая система содержит пакеты для загрузки, библиотеки и приложения. Для изменения размера можно поменять способ подготовки пакетов, а также саму файловую систему.

Сначала следует разобраться с размерами файловой системы и отдельных файлов с помощью сценария dirsize.py:

$ cd root-directory-of-image $ dirsize.py 100000 > dirsize-100k.log $ cat dirsize-100k.log

Параметр 100000 задает игнорирование файлов, размер которых меньше 100 кбайт. Сценарий возвращает размеры несжатых файлов, поэтому на файловых системах с компрессией нужно вводить коэффициент. После просмотра журнала dirsize-100k.log можно будет сосредоточиться на крупных файлах.

Следует учитывать взаимосвязи между файлами, чтобы не навредить функциональности. Можно посмотреть зависимости с помощью интерфейса Dependency Explorer пакета BitBake, как показано ниже.

$ cd image-directory $ bitbake -u taskexp -g image

Изучив зависимости можно понять, какие пакеты или файлы можно безбоязненно исключить. При выборе пакетов для удаления следует учитывать их функциональность. Например, может оказаться ненужным дисплей VGA или можно обойтись devtmpfs и mdev вместо udev. Изменения следует вносить в файл local.conf. Например, для исключения udev и glib можно указать VIRTUAL-RUNTIME_dev_manager = «».

Следует также учитывать тип корневой файловой системы и ее соответствие поставленным задачам. Например, можно рассмотреть системы cramfs, squashfs, ubifs, ext2 или initramfs. Следует учитывать, что файловой системе ext3 потребуется 1 Мбайт для журнала, который не будет нужен в файловой системе с доступом лишь для чтения.

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

3.10.4.5. Минимизация ядра

Ядро собирается с включением правил для зависимых от оборудования аспектов, включая разрешенные подсистемы, архитектуру, драйверы. При необходимости может изменяться исходный код ядра.

Сценарий ksize.py из каталога сборки верхнего уровня может подсказать, что следует изменить в ядре.

$ cd top-level-linux-build-directory $ ksize.py > ksize.log $ cat ksize.log

При просмотре журнала можно увидеть размер встроенных файлов .o для драйверов, сети, базовых функций, файловых систем, звука и т. п. Сценарий возвращает размеры несжатых компонент и для сжатых ядер следует вводить коэффициент. Следует выделить наиболее крупные области и оптимизировать их размеры. Для более подробного изучения структуры служит специальная опция -d.

     $ ksize.py -d > ksize.log

Просмотр журнала позволяет определить компоненты, которые можно исключить. Например, если в системе нет звуковых устройств, можно исключить драйверы для звука.

После определения исключаемых компонент нужно заново настроить конфигурацию ядра для учета изменений при следующей сборке. Это можно сделать с помощью команды menuconfig. Однако в этом случае могут возникнуть затруднения с учетом влияния отдельных исключений, а также с репликацией изменений на другие целевые устройства. Лучше начать с пустой конфигурации, введя команду allnoconfig, создать фрагменты конфигурации для отдельных изменений, а затем использовать сценарий merge_config.sh. Это упрощает итерации настройки конфигурации в цикле сборки.

При каждом изменении конфигурации следует выполнять сборку ядра для контроля размера и результатов изменений.

3.10.4.6. Исключение требований к управлению пакетами

Требования управления пакетами ведут к увеличению образа, поэтому исключение этих требований позволяет сделать образ более компактным. Это включает удаление менеджера пакетов с его зависимостями, а также всех данных управления пакетами.

Для исключения требований к управлению пакетами следует убедиться в отсутствии значения package-management в операторе IMAGE_FEATURES для образа. При удалении этого свойства из корневой файловой системы будет исключен менеджер пакетов и все его зависимости.

3.10.4.7. Другие способы снижения размера

В зависимости от конкретных задач могут быть и иные способы снижения размера. При поиске решений могут помочь указанные здесь инструменты в сочетании с экспериментами и итерациями.

  • glibc
    • удалите из DISTRO_FEATURES свойства glibc, которые представляются ненужными;
    • соберите дистрибутив;
    • при возникновении отказа по причине отсутствия символов в пакете определите возможность настройки пакета без этих символов;
    • повторите сборку и проверку работоспособности.
  • busybox. Процедуры похожи на описанные выше для glibc. Разница заключается в необходимости загрузки получившейся системы для проверки. Нужно обеспечить интеграцию фрагментов конфигурации в Busybox, поскольку BusyBox самостоятельно обрабатывает основные возможности, позволяя добавлять фрагменты конфигурации.
3.10.4.8. Итерации процесса

Если цель не достигнута с первой попытки, процесс следует повторить. Следует обращать внимание на компоненты, занимающие 90% корневой файловой системы и ядра. Удаляйте компоненты, которые не нужны при работе системы.

В зависимости от конкретной системы следует обращать внимание на Busybox, где обеспечиваются урезанные версии инструментов Unix в одном исполняемом файле.

3.10.5. Сборка образов для нескольких машин

Разработчикам зачастую приходится создавать образы разных машин, использующих одинаковую программную среду. В таких случаях заманчиво установить настройки и флаги оптимизации для каждой сборки специально под целевую платформу. Однако это может существенно увеличить время сборки и осложнить поддержку хранилища пакетов для всех машин. Например, выбор настроек, наиболее подходящих для процессора платформы, может включать тонкую оптимизацию GCC для определенной платформы, но без этого не будет достигнуто существенного роста производительности по сравнению с применением базовых настроек для всех платформ. Вместо этого можно выполнить настройки, которые заставят систему сборки OE многократно использовать программные компоненты на разных платформах, когда это имеет смысл.

Если скорость сборки и обслуживание хранилища пакетов важны, следует рассмотреть приведенные ниже рекомендации.

  • Общий каталог сборки. По возможности следует применять для сборок общий каталог TMPDIR. YP поддерживает переключение между значениями MACHINE в одном каталоге TMPDIR. Такая практика хорошо поддерживается и часто применяется разработчиками при сборке для нескольких машин. При использовании общего каталога TMPDIR система сборки OE может многократно применять имеющиеся естественные и кросс-задания для разных машин, что снижает время сборки. При изменении настроек DISTRO или важных параметров конфигурации (например, схема файловой системы) нужно начинать работу с чистого каталога TMPDIR. Общий каталог TMPDIR в таких случаях может работать, но это не гарантируется.
  • Включение подходящей архитектуры управления пакетами. По умолчанию система сборки OE включает 3 уровня управления пакетами — all, tune или package, machine. Задания обычно выбирают для своего вывода одну архитектуру (тип). В зависимости от цели создания пакетов заданием наличие соответствующей архитектуры управления пакетами может напрямую влиять на время сборки.Задание, создающее сценарии, может выбрать архитектуру all, поскольку оно не создает двоичных файлов. Для выбора этой архитектуры следует обеспечить наследование класса allarch, который в данном случае настраивает множество переменных так, что пакеты подходят для разной архитектуры.Если задание создает машинозависимые пакеты или одна из зависимостей при работе или сборке уже включает машину или архитектуру, что делает задание машинозависимым, следует выбирать тип machine через переменную MACHINE_ARCH в виде PACKAGE_ARCH = «${MACHINE_ARCH}». Если архитектура управления пакетами осознанно не включена через PACKAGE_ARCH, система сборки OE по умолчанию устанавливает PACKAGE_ARCH = «${TUNE_PKGARCH}».
  • Выбор базового файла настройки (по возможности). Некоторые настройки являются достаточно общими и могут применяться для разных платформ (например, armv5 устанавливает пакеты, которые в большинстве случаев могут работать на armv6 и armv7, а двоичные файлы i486 могут работать на i586 и последующих платформах). Однако следует понимать, что усовершенствования новых процессоров работать не будут.При выборе одной настройки для множества машин система сборки OE повторно использует собранные ранее программы, что сокращает время сборки. Даже при смене sysroot для машин программы не компилируются заново и в хранилище существует лишь один пакет.
  • Управление детализацией подготовки пакетов. Иногда бывает полезно внедрение иного уровня архитектуры пакетов в дополнение к 3 указанным ранее. В качестве примера рассмотрим, как NXP (ранее Freescale) позволяет повторно использовать двоичные пакеты на своем уровне meta-freescale. Класс fsl-dynamic-packagearch обеспечивает совместное использование пакетов GPU для плат i.MX53, поскольку на всех применяется AMD GPU. Для плат i.MX6 можно поступить аналогично, поскольку все они используют Vivante GPU. Этот класс проверяет хранилище данных BitBake на предмет наличия пакетов, предоставляющих такую субархитектуру или зависящих от нее. При наличии таких пакетов класс устанавливает значение PACKAGE_ARCH на основе значения MACHINE_SUBARCH. Если пакет не предоставляет такую субархитектуру и не зависит от нее, но соответствует значению специфичного для машины фильтра, устанавливается MACHINE_ARCH. Это снижает число собираемых пакетов и экономит время.
  • Использование инструментов отладки. Иногда возникают случаи повторной сборки программ без вашего ведома. Например, система сборки OE может не использовать общего состояния с другой машиной, которое вы предполагаете. Такие ситуации часто возникают в результате ссылок на машинозависимые переменные, такие как MACHINE, SERIAL_CONSOLES, XSERVER, MACHINE_FEATURES и т. п. в коде, который должен зависеть лишь от настройки или когда задание зависит (DEPENDS, RDEPENDS, RRECOMMENDS, RSUGGESTS и т. п.) от другого задания, уже определившего PACKAGE_ARCH как «${MACHINE_ARCH}». Для таких случаев есть инструменты, помогающие разобраться в ситуации.
    • sstate-diff-machines.sh в каталоге scripts репозитория исходных кодов. Информация о работе со сценарием приведена в комментариях.
    • Опция BitBake «-S printdiff» заставляет BitBake попытаться насти максимальное соответствие подписи (например, в кэше общего состояния) и запустить bitbake-diffsigs для определения штампов и приращений (delta), где два штампа разошлись.

3.10.6. Сборка программ из внешних источников

По умолчанию система сборки OE использует в процессе работы сборочный каталог. Процесс сборки включает извлечение файлов исходного кода, их распаковку и применение исправления (если они есть). В некоторых случаях может потребоваться собрать программы из источников, расположенных вне системы сборки OE. Например, проект может включать BSP, ядро для которого имеет весьма специальные настройки, и при этом нужно минимизировать работу команды разработчиков с системой сборки, чтобы они могли сосредоточиться на своем проекте. В этом случае специализированное ядро может размещаться на машине, где осуществляется разработка и в переменной SRC_URI задания для сборки будет указан внешний каталог, чтобы не копировать файлы.

Для сборки программы из внешнего источника нужно наследовать класс externalsrc и указать в переменной EXTERNALSRC местоположение исходного кода. Эти операторы помещаются в файл local.conf, как показано ниже.

INHERIT += "externalsrc"
     EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"

Можно также задать переменные в файле задания или файле дополнения. Например,

EXTERNALSRC = "path" EXTERNALSRC_BUILD = "path"

Чтобы эти установки сработали, нужно глобально или локально наследовать класс externalsrc.

По умолчанию класс externalsrc.bbclass собирает исходный код в каталоге, отличающемся от внешнего каталога источников, заданного в EXTERNALSRC. Если нужно собрать исходный код в том же каталоге, где он хранится или в неком ином названном каталоге, можно указать нужный каталог в переменной EXTERNALSRC_BUILD

EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"

3.10.7. Автономная репликация сборки

Иногда полезно сделать «моментальный снимок» разрабатываемого кода, использованного для сборки и затем применять этот снимок для репликации сборки в автономном режиме. Для этого нужно сначала подготовить и заполнить каталог файлами «снимка». После загрузки файлов их можно применять для репликации сборки в любой момент и с любой машины. Процедура подготовки описана ниже.

  1. Создание пустого каталога для загрузки (DL_DIR). Можно очистить имеющийся каталог или указать новое значение в переменной DL_DIR.
  2. Генерация архивов репозитория Git. В файле local.conf нужно указать строки:
    DL_DIR = "/home/your-download-dir/" BB_GENERATE_MIRROR_TARBALLS = "1"

    При выборке файлов на следующем этапе BitBake соберет файлы исходного кода и создаст архив в каталоге DL_DIR. Дополнительная информация приведена в описании BB_GENERATE_MIRROR_TARBALLS.

  3. Заполнение каталога загрузки без сборки с помощью BitBake:
    $ bitbake target --runonly=fetch

    После этого каталог загрузки (${DL_DIR}) будет содержать снимок исходного кода в виде архива.

  4. Необязательное удаление служебных данных Git или иных SCM. Можно удалить из каталога загрузки подкаталоги Git или других SCM, такие как ${DL_DIR}/git2/*, поскольку они присутствуют в архиве.

После заполнения каталога загрузки можно создать «свое зеркало» и собрать программу для своей целевой платформы, как описано ниже.

  1. Использование только локальных файлов. В файл local.conf следует добавить переменную SOURCE_MIRROR_URL, наследование класса own-mirrors и переменную BB_NO_NETWORK.
    SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/" INHERIT += "own-mirrors" BB_NO_NETWORK = "1"

    SOURCE_MIRROR_URL и класс own-mirror задают использование каталога загрузки в качестве «своего зеркала», а переменная BB_NO_NETWORK заставляет BitBake извлекать файлы из локального источника.

  2. Начало с «чистого листа» путем удаления каталога ${TMPDIR} или использования нового каталога сборки.
  3. Сборка цели с использованием BitBake
    $ bitbake target

    Сборка выполняется с использованием локального снимка исходных файлов. Автономная сборка не будет работать, если задание пытается найти свежую версию программ путем установки SRCREV = «${AUTOREV}», поскольку в этом случае система обращается в сеть, пытаясь найти последнюю версию программы в SCM. Задания, использующие AUTOREV, обычно являются пользовательскими или измененными, а задания из публичных репозиториев как правило не применяют AUTOREV.

    При наличии заданий с AUTOREV можно выполнить приведенные ниже рекомендации для автономной сборки.

    1. Использовать конфигурацию, созданную включением истории сборки (3.28.1. Управление историей сборки).
    2. Использовать команду buildhistory-collect-srcrevs для сбора сохраненных значений SRCREV из истории сборки (3.28.2.1. История сборки пакета).
    3. Поскольку имеются корректные выпуски исходного кода, можно изменить задания, установив в SRCREV нужные версии программ.

3.11. Ускорение сборки

Время сборки может быть продолжительным. По умолчанию система сборки применяет простые элементы управления для повышения эффективности сборки. Обычно принятые по умолчанию значения перечисленных ниже переменных обеспечивают наиболее эффективную сборку на системах с одним процессором (не ядром). Если на хосте имеется несколько CPU, можно попытаться изменить эти переменные для повышения скорости сборки.

  • BB_NUMBER_THREADS задает максимальное число потоков для выполнения задач BitBake.
  • BB_NUMBER_PARSE_THREADS задает число потоков, используемых BitBake при анализе заданий.
  • PARALLEL_MAKEдобавочные опции, передаваемые команде make в задаче do_compile для выполнения параллельной компиляции на локальном хосте сборки.
  • PARALLEL_MAKEINSTдобавочные опции, передаваемые команде make в задаче do_install для выполнения параллельной инсталляции на локальном хосте сборки.

Эти переменные управляют числом процессорных ядер, доступных системе сборки. Для однопроцессорных систем автоматическое масштабирование обеспечивает использование системой сборки возможностей параллельного выполнения операций. Ниже рассмотрены дополнительные факторы, способные влиять на скорость сборки.

  • Тип файловой системы на хосте сборки может влиять на скорость. Рекомендуется использовать файловые системы ext4, поскольку они обеспечивают более высокую производительность по сравнению с ext2 и ext3.
  • Запрет обновления времени доступа с помощью noatime. Опция монтирования noatime позволяет системе сборки не обновлять время доступа к файлам и каталогам.
  • Более продолжительный интервал фиксации. Использовании опции монтирования «commit=» позволяет задать интервал (в секундах) между записями дискового кэша. Смена принятого по умолчанию интервала в 5 секунд на более долгий повышает производительность сборки, но также увеличивает риск потери данных.
  • Выбор системы управления пакетами. Из числа доступных менеджеров самым быстрым является IPK. Кроме того, ускоряет сборку использование единственного менеджера вместо нескольких.
  • Использование файловой системы tmpfs для каталога TMPDIR может ускорить сборку, но преимущества ограничены, поскольку компилятор использует -pipe. Система сборки предпринимает несколько действий по предотвращению вызовов sync() для файловой системы, исходя из того, что при серьезном отказе содержимое каталога сборки легко создать заново.
  • Наследование класса rm_work позволяет ускорить сборку за счет снижения объема данных, сохраняемых в кэше и на диске. Это также ускоряет очистку TMPDIR. Разработчики файловых систем рекомендуют в качестве наиболее быстрого способа удаления большого числа файлов переформатирование файловой системы. Однако это требует соответствующей организации дисковых разделов.

В дополнение к перечисленным рекомендациям отметим несколько компромиссов, которые могут ускорить сборку.

  • Удаление ненужных элементов из DISTRO_FEATURES.
  • Исключение отладочных символов и других данных отладки путем запрета генерации пакетов*-dbg установкой INHIBIT_PACKAGE_DEBUG_SPLIT = «1».
  • Запрет создания статических библиотек для заданий, выведенных из autoconf или libtool, как показано ниже.
     STATICLIBCONF = "--disable-static"
     STATICLIBCONF_sqlite3-native = ""
     EXTRA_OECONF += "${STATICLIBCONF}"
    • Некоторым заданиям статические библиотеки нужны для корректной работы (например, pseudo-native требует sqlite3-native). Приведенные выше переопределения учитывают это.
    • Для подготовки некоторых пакетов нужны статические библиотеки и может потребоваться их сборка.

3.12. Работа с библиотеками

Библиотеки являются важной частью сборки и здесь даны некоторые рекомендации по работе с библиотеками.

3.12.1. Включение файлов статических библиотек

При создании библиотеки, предлагающей статическую компоновку можно управлять включением в собираемую библиотеку статических файлов (*.a). Переменные PACKAGES и FILES_* в файле meta/conf/bitbake.conf определяют включение в пакеты файлов, установленных задачей do_install. По молчанию PACKAGES включает ${PN}-staticdev, представляя все файлы статических библиотек. В нескольких прежних выпусках YP статические библиотеки указывались как ${PN}-dev. Ниже приведен фрагмент файла конфигурации BitBake для файлов статических библиотек.

PACKAGE_BEFORE_PN ?= ""
PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
PACKAGES_DYNAMIC = "^${PN}-locale-.*"
FILES = ""

FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
${base_prefix}/lib/udev/rules.d ${prefix}/lib/udev/rules.d \
${datadir}/${BPN} ${libdir}/${BPN}/* \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"

FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"

FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
${datadir}/gnome/help"
SECTION_${PN}-doc = "doc"

FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
${datadir}/aclocal ${base_libdir}/*.o \
${libdir}/${BPN}/*.la ${base_libdir}/*.la"
SECTION_${PN}-dev = "devel"
ALLOW_EMPTY_${PN}-dev = "1"
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"

FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"

3.12.2. Объединение разных версий библиотек в одном образе

Система сборки позволяет создавать библиотеки с оптимизацией под разные платформы и архитектуру, объединяя их в одном образе. Можно связать разные исполняемые файлы образа с разными библиотеками для конкретных вариантов применения. Это свойство называется Multilib. Примером может служить ситуация, когда большая часть системы собрана в 32-битовом режиме с 32-битовыми библиотеками, но есть некоторые 64-битовые приложения, которым нужны 64-битовые библиотеки. Хотя feature чаще всего используется для обслуживания различий между 32- и 64-битовыми приложениями, система сборки упрощает и другие варианты оптимизации. Можно собрать некоторые приложения для работы с одним набором библиотек, другие — с иным. Библиотеки могут различаться архитектурой, опциями компиляции и другими параметрами оптимизации. Несколько примеров представлено на уровне meta-skeleton:

  • conf/multilib-example.conf;
  • conf/multilib-example2.conf;
  • recipes-multilib/images/core-image-multilib-example.bb.
3.12.2.1. Подготовка к использованию Multilib

Применение Multilib обусловлено потребностями пользователей, поэтому нет готовой конфигурации на все случаи. Для включения Multilib нужно сначала обеспечить поддержку разных библиотек в задании, что уже реализовано во многих стандартных заданиях. Следует проверить значение переменной BBCLASSEXTEND в файле meta/conf/multilib.conf дерева источников. В конечном итоге поддержка будет включена во все задания и проверка станет ненужной.

Расширение Multilib в основном работает автоматически, преобразуя имя пакета ${PN} в ${MLPREFIX}${PN}, где MLPREFIX указывает конкретную библиотеку (например, «lib32-» or «lib64-«). Стандартные переменные, такие как DEPENDS, RDEPENDS, RPROVIDES, RRECOMMENDS, PACKAGES и PACKAGES_DYNAMIC преобразуются системой автоматически. Если задание преобразуется вручную, можно использовать переменную ${MLPREFIX} для корректного преобразования имен. Код автоматического преобразования включен в класс multilib.bbclass.

3.12.2.2. Использование Multilib

После настройки заданий нужно указть требуемую комбинацию библиотек в файле local.conf каталога сборки.

     MACHINE = "qemux86-64"
     require conf/multilib.conf
     MULTILIBS = "multilib:lib32"
     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
     IMAGE_INSTALL_append = " lib32-glib-2.0"

В приведенном примере включена дополнительная библиотека lib32. При объединении с вариантами lib32 в примере используется x86. Эту настройку можно посмотреть в файле meta/conf/machine/include/ia32/arch-ia32.inc. Пример включает lib32-glib-2.0 во все образы, что является одним из вариантов. Можно использовать обычную сборку образа для включения этой зависимости. Например, bitbake core-image-sato. Можно также собрать пакеты Multilib независимо с помощью команды вида bitbake lib32-glib-2.0.

3.12.2.3. Детали реализации

Имеются как общие, так и связанные с системой менеджером пакетов детали реализации. Рассмотрим сначала общие.

  • Типичное соглашения для кода расширения класса, используемого Multilib, предполагает, что все имена пакетов из PACKAGES, включающие ${PN}, начинаются с ${PN}. При указании ${PN} не в начале имени возникают проблемы.
  • Значение TARGET_VENDOR в Multilib расширено до «-vendormlmultilib» (например, -pokymllib32 для lib32 в Multilib с Poky). Причиной послужило то, что символы — в строке производителя в настоящее время противоречат config.sub в Autoconf, а использование иных разделителей проблематично.

Для системы управления пакетами RPM также существует ряд деталей, указанных ниже.

  • Определенная отдельная архитектура для пакетов Multilib, а также отдельный каталог развертывания tmp/deploy/rpm. Например, для lib32 в образе qemux86-64 будут представлены архитектуры «all», «qemux86_64», «lib32_qemux86_64» и «lib32_x86».
  • Переменная ${MLPREFIX} вырезается из ${PN} при подготовке пакетов RPM. Именование обычных и Multilib пакетов RPM в системе qemux86-64 будет иметь вид bash-4.1-r2.x86_64.rpm и bash-4.1.r2.lib32_x86.rpm.
  • Для образа Multilib менеджер RPM сначала устанавливает базовый образ, затем — библиотеки Multilib.
  • Система сборки использует RPM при совпадении имен файлов в нескольких пакетах Multilib.

Детали, связанные с системой управления IPK, перечислены ниже.

  • ${MLPREFIX} не удаляется из ${PN} при подготовке пакетов IPK. Именование обычных и Multilib пакетов IPK в системе qemux86-64 имеет вид bash_4.1-r2.x86_64.ipk и lib32-bash_4.1-rw_x86.ipk.
  • Каталог развертывания IPK не меняется при использовании ${MLPREFIX}, поскольку пакеты различаются значениями ${PN}.
  • IPK проверяет пригодность установки Multilib с использованием правил сравнения, переопределения и т. п.

3.12.3. Установка нескольких версий одной библиотеки

Может возникать потребность использовать одновременно несколько версий библиотеки в одной системе. Это почти всегда происходит при смене версии API, если имеется несколько программ, работающих с разными версиями библиотеки. Решением проблемы является параллельная установка нескольких версий в одной системе. Сделать это достаточно просто, если библиотеки корректно управляют версиями. Нужно просто отдельно указать библиотеки путем подготовки заданий с именами, где переменная PN включает версию библиотеки (например, старшую часть номера). В результате каждое задание будет загружать свою версию библиотеки. Например, показанные ниже примеры имен заданий для библиотеки clutter позволяют использовать две версии.

     clutter-1.6_1.6.20.bb
     clutter-1.8_1.8.4.bb

Если другие задания зависят от конкретной версии библиотеки, нужно указать соответствующую версию в переменной DEPENDS таких заданий. Например, для задания, зависящего от библиотеки clutter версии 1.8, следует указать DEPENDS = «clutter-1.8».

1Source Control Manager.

2Board Support Package — пакет поддержки плат.

3QuickEMUlator.

4Windows Subsystem for Linux — подсистема Windows для Linux.

5Опыт показывает, что YP достаточно эффективно работает на сборочном хосте с Linux Mageia 7.1.

6Опыт сборки образов для платформы HiFive Unleashed объем исходных файлов и результатов сборки около 80 Гбайт. Дополнительно отметим, что каталог сборки лучше размещать на быстром диск (SAS или SSD), поскольку это значительно ускоряет работу.

7Software Development Kit — комплект для разработки программ.

8CROssPlatformS — модель кросс-платформенной разработки с открытым исходным кодом.

9Auto Upgrade Helper — помощник для автоматического обновления.

Часть 2

Рубрика: Linux | Комментарии к записи Руководство по разработке проектов в Yocto Project отключены

Руководство разработчика Yocto Project BSP

PDF

Scott Rifenbark, <srifenbark@gmail.com>

Scotty’s Documentation Services, INC

Copyright © 2010-2019 Linux Foundation

Разрешается копирование, распространение и изменение документа на условиях лицензии Creative Commons Attribution-Share Alike 2.0 UK: England & Wales, опубликованной Creative Commons.

Этот документ основан на переводе Yocto Project Board Support Package (BSP) Developer’s Guide для выпуска 3.0. Свежие версии оригинальных документов можно найти на странице Yocto Project documentation. Размещенные там материалы более актуальны, нежели включенные в архивы пакета Yocto Project.

Глава 1. Руководство разработчика пакетов поддержки плат (BSP)

BSP1 представляет собой набор данных, определяющих поддержку конкретного устройства, группы устройств или аппаратной платформы. BSP включает информацию об аппаратных возможностях устройства и конфигурацию ядра с драйверами для поддержки аппаратных компонент, а также о программных компонентах, требуемых в дополнение к стандартным программам Linux для реализации полной функциональности платформы.

В этом руководстве приведены сведения об уровнях BSP, определена структура уровня BSP и рассмотрены вопросы настройки заданий для BSP, лицензировании и создании уровней BSP с помощью программы bitbake-layers.

1.1. Уровни BSP

Внутри уровня BSP используется определенная структура файлов. Для имен уровней BSP в составе YP обычно используется форма meta-bsp_root_name, где префикс meta- сопровождается именем машины или платформы bsp_root_name. Префикс meta- не является обязательным, но лучше использовать его, поскольку многие сценарии и инструменты YP предполагают его наличие.

Для понимания концепций уровня BSP рассмотрим BSP из состава выпусков YP, которые можно посмотреть на странице Yocto Project Source Repositories через web-интерфейс http://git.yoctoproject.org, где они размещены под заголовком Yocto Metadata Layers. Уровни, для которых не обеспечивается активная поддержка в YP, приведены в разделе Yocto Metadata Layer Archive. Каждый из этих репозиториев содержит уровень BSP, поддерживаемый в YP (например, meta-raspberrypi и meta-intel). Репозитории можно клонировать обычным способом на хост сборки, например, git clone git://git.yoctoproject.org/meta-raspberrypi. Кроме того, уровень meta-yocto-bsp включен в репозиторий poky и включает несколько BSP для Beaglebone, EdgeRouter, а также 32- и 64-битовой архитектуры IA.

Поток разработки BSP описан в разделе 1.4. Разработка BSP, а сведения о создании локального репозитория Git с исходными файлами приведены в разделе Locating Yocto Project Source Files [1].

Базовый каталог уровня (meta-bsp_root_name) является корнем этого уровня и должен быть добавлен в переменную BBLAYERS в файле conf/bblayers.conf каталога сборки, который создается после запуска сценария настройки среды OpenEmbedded (OE) oe-init-build-env. Добавление корневого каталога позволяет системе сборки OE распознавать уровень и собирать образ для него. Например,

     BBLAYERS ?= " \
       /usr/local/src/yocto/meta \
       /usr/local/src/yocto/meta-poky \
       /usr/local/src/yocto/meta-yocto-bsp \
       /usr/local/src/yocto/meta-mylayer \
       "

Порядок указания и приоритет BBFILE_PRIORITY для уровней в переменной BBLAYERS имеют значение. Например, при включении конфигурации машины в несколько уровней система сборки OE будет использовать последний найденный уровень с одинаковым приоритетом. Список уровней просматривается в BBLAYERS сверху вниз.

Некоторые BSP требуют или зависят от других уровней за пределами своего корня. В таких случаях нужно указать эти уровни в разделе Dependencies файла README в корневом каталоге BSP. Там же следует приводить все дополнительные инструкции по сборке для данного BSP.

Некоторые уровни служат хранилищем для других уровней BSP, такие уровни называют контейнерными. Примером контейнерного уровня может служить meta-openembedded в OE, включающий множество уровней meta-*. Подробное описание уровней дано в разделе Understanding and Creating Layers [1].

1.2. Подготовка хоста сборки для работы с уровнем BSP

В этом разделе описана подготовка хоста сборки для работы с BSP, по завершении которой можно создавать уровни в соответствии с разделом 1.8. Создание уровня BSP с помощью сценария bitbake-layers. Информация о структуре BSP дана в разделе 1.3. Пример структуры файлов.

  1. Организация среды сборки с использованием BitBake описана в разделе Preparing the Build Host [1] для машин Linux и CROPS.
  2. Клонирование репозитория poky. Для работы потребуется локальная копия YP Source Directory (локальный репозиторий poky). Клонирование репозитория и выбор нужной ветви описаны в разделах Cloning the poky Repository, Checking Out by Branch in Poky и Checking Out by Tag in Poky [1].
  3. Определение нужного уровня BSP. В состав YP входит множество BSP, поддерживаемых на отдельных уровнях и в составе некоторых уровней. Для получения информации об имеющихся BSP следует обратиться к списку машин для выпуска.
  4. Клонирование уровня meta-intel BSP (необязательно). Если устройство использует современные процессоры Intel, можно воспользоваться этим уровнем, описанным в файле README.

    1. Выбор местоположения. Обычно репозиторий meta-intel Git помещается в дерево источников (например, poky). $ cd /home/you/poky
    2. Клонирование уровня.

           $ git clone git://git.yoctoproject.org/meta-intel.git
           Cloning into 'meta-intel'...
           remote: Counting objects: 15585, done.
           remote: Compressing objects: 100% (5056/5056), done.
           remote: Total 15585 (delta 9123), reused 15329 (delta 8867)
           Receiving objects: 100% (15585/15585), 4.51 MiB | 3.19 MiB/s, done.
           Resolving deltas: 100% (9123/9123), done.
           Checking connectivity... done.
    3. Выбор нужной ветви, которая должна соответствовать используемой выпуском YP (например zeus).

           $ cd meta-intel
           $ git checkout -b zeus remotes/origin/zeus
           Branch zeus set up to track remote branch zeus from origin.
           Switched to a new branch 'zeus'

      Для просмотра доступных ветвей служит команда git branch -al (см. Checking Out By Branch in Poky [1]).

  5. Установка дополнительного уровня BSP (необязательно). Если устройство более точно подходит к имеющемуся BSP вне уровня meta-intel, можно клонировать этот уровень BSP. Процесс идентичен клонированию meta-intel и отличается лишь именем уровня. Например, для клонирования meta-raspberrypi

         $ git clone git://git.yoctoproject.org/meta-raspberrypi
         Cloning into 'meta-raspberrypi'...
         remote: Counting objects: 4743, done.
         remote: Compressing objects: 100% (2185/2185), done.
         remote: Total 4743 (delta 2447), reused 4496 (delta 2258)
         Receiving objects: 100% (4743/4743), 1.18 MiB | 0 bytes/s, done.
         Resolving deltas: 100% (2447/2447), done.
         Checking connectivity... done.
  6. Инициализация среды сборки. Из корня дерева кодов (poky) выполняется сценарий организации среды oe-init-build-env для установки параметров OE на сборочном хосте.

         $ source oe-init-build-env

    Сценарий, наряду с прочим, создает сборочный каталог внутри дерева исходных кодов и делает его текущим.

1.3. Пример структуры файлов

Единая структура каталога BSP позволяет пользователям легче разобраться с этим стандартом, а также упрощает стандартизацию программной поддержки оборудования. Описанная ниже структура включает элементы, относящиеся к системе сборки OE, но она может применяться и с другими системами, а при необходимости может быть преобразована в другой формат. Система сборки OE через стандартный механизм уровней может напрямую обращаться к описанному здесь формату. Уровень BSP содержит все аппаратные свойства в одном месте, используя стандартный формат, который будет полезен для всех применяющих платформу, независимо от системы сборки.

Спецификация BSP не включает систему сборки или иные инструменты, а сосредоточена лишь на аппаратных компонентах. Однако можно распространять свой уровень BSP вместе с системой сборки или иными инструментами. При этом важно понимать, что уровень BSP, система сборки и инструменты являются отдельными компонентами, которые могут группироваться по-разному. Следует понимать, что совместимость уровня BSP с проектом YP вносит определенные требования, перечисленные в параграфе 1.5.1. Требования к выпускаемым BSP.

Ниже представлен общий вид структуры каталогов уровня BSP, соответствующей стандарту. Однако в реальных BSP она может несколько отличаться.

meta-bsp_root_name/ meta-bsp_root_name/bsp_license_file meta-bsp_root_name/README meta-bsp_root_name/README.sources meta-bsp_root_name/binary/bootable_images meta-bsp_root_name/conf/layer.conf meta-bsp_root_name/conf/machine/*.conf meta-bsp_root_name/recipes-bsp/* meta-bsp_root_name/recipes-core/* meta-bsp_root_name/recipes-graphics/* meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend

Например уровень Raspberry Pi BSP из Source Respositories имеет структуру, показанную ниже.

     meta-raspberrypi/COPYING.MIT
     meta-raspberrypi/README.md
     meta-raspberrypi/classes
     meta-raspberrypi/classes/sdcard_image-rpi.bbclass
     meta-raspberrypi/conf/
     meta-raspberrypi/conf/layer.conf
     meta-raspberrypi/conf/machine/
     meta-raspberrypi/conf/machine/raspberrypi-cm.conf
     meta-raspberrypi/conf/machine/raspberrypi-cm3.conf
     meta-raspberrypi/conf/machine/raspberrypi.conf
     meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf
     meta-raspberrypi/conf/machine/raspberrypi0.conf
     meta-raspberrypi/conf/machine/raspberrypi2.conf
     meta-raspberrypi/conf/machine/raspberrypi3-64.conf
     meta-raspberrypi/conf/machine/raspberrypi3.conf
     meta-raspberrypi/conf/machine/include
     meta-raspberrypi/conf/machine/include/rpi-base.inc
     meta-raspberrypi/conf/machine/include/rpi-default-providers.inc
     meta-raspberrypi/conf/machine/include/rpi-default-settings.inc
     meta-raspberrypi/conf/machine/include/rpi-default-versions.inc
     meta-raspberrypi/conf/machine/include/tune-arm1176jzf-s.inc
     meta-raspberrypi/docs
     meta-raspberrypi/docs/Makefile
     meta-raspberrypi/docs/conf.py
     meta-raspberrypi/docs/contributing.md
     meta-raspberrypi/docs/extra-apps.md
     meta-raspberrypi/docs/extra-build-config.md
     meta-raspberrypi/docs/index.rst
     meta-raspberrypi/docs/layer-contents.md
     meta-raspberrypi/docs/readme.md
     meta-raspberrypi/files
     meta-raspberrypi/files/custom-licenses
     meta-raspberrypi/files/custom-licenses/Broadcom
     meta-raspberrypi/recipes-bsp
     meta-raspberrypi/recipes-bsp/bootfiles
     meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb
     meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb
     meta-raspberrypi/recipes-bsp/common
     meta-raspberrypi/recipes-bsp/common/firmware.inc
     meta-raspberrypi/recipes-bsp/formfactor
     meta-raspberrypi/recipes-bsp/formfactor/formfactor
     meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi
     meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi/machconfig
     meta-raspberrypi/recipes-bsp/formfactor/formfactor_0.0.bbappend
     meta-raspberrypi/recipes-bsp/rpi-u-boot-src
     meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files
     meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files/boot.cmd.in
     meta-raspberrypi/recipes-bsp/rpi-u-boot-src/rpi-u-boot-scr.bb
     meta-raspberrypi/recipes-bsp/u-boot
     meta-raspberrypi/recipes-bsp/u-boot/u-boot
     meta-raspberrypi/recipes-bsp/u-boot/u-boot/*.patch
     meta-raspberrypi/recipes-bsp/u-boot/u-boot_%.bbappend
     meta-raspberrypi/recipes-connectivity
     meta-raspberrypi/recipes-connectivity/bluez5
     meta-raspberrypi/recipes-connectivity/bluez5/bluez5
     meta-raspberrypi/recipes-connectivity/bluez5/bluez5/*.patch
     meta-raspberrypi/recipes-connectivity/bluez5/bluez5/BCM43430A1.hcd
     meta-raspberrypi/recipes-connectivity/bluez5/bluez5brcm43438.service
     meta-raspberrypi/recipes-connectivity/bluez5/bluez5_%.bbappend
     meta-raspberrypi/recipes-core
     meta-raspberrypi/recipes-core/images
     meta-raspberrypi/recipes-core/images/rpi-basic-image.bb
     meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb
     meta-raspberrypi/recipes-core/images/rpi-test-image.bb
     meta-raspberrypi/recipes-core/packagegroups
     meta-raspberrypi/recipes-core/packagegroups/packagegroup-rpi-test.bb
     meta-raspberrypi/recipes-core/psplash
     meta-raspberrypi/recipes-core/psplash/files
     meta-raspberrypi/recipes-core/psplash/files/psplash-raspberrypi-img.h
     meta-raspberrypi/recipes-core/psplash/psplash_git.bbappend
     meta-raspberrypi/recipes-core/udev
     meta-raspberrypi/recipes-core/udev/udev-rules-rpi
     meta-raspberrypi/recipes-core/udev/udev-rules-rpi/99-com.rules
     meta-raspberrypi/recipes-core/udev/udev-rules-rpi.bb
     meta-raspberrypi/recipes-devtools
     meta-raspberrypi/recipes-devtools/bcm2835
     meta-raspberrypi/recipes-devtools/bcm2835/bcm2835_1.52.bb
     meta-raspberrypi/recipes-devtools/pi-blaster
     meta-raspberrypi/recipes-devtools/pi-blaster/files
     meta-raspberrypi/recipes-devtools/pi-blaster/files/*.patch
     meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster_git.bb
     meta-raspberrypi/recipes-devtools/python
     meta-raspberrypi/recipes-devtools/python/python-rtimu
     meta-raspberrypi/recipes-devtools/python/python-rtimu/*.patch
     meta-raspberrypi/recipes-devtools/python/python-rtimu_git.bb
     meta-raspberrypi/recipes-devtools/python/python-sense-hat_2.2.0.bb
     meta-raspberrypi/recipes-devtools/python/rpi-gpio
     meta-raspberrypi/recipes-devtools/python/rpi-gpio/*.patch
     meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb
     meta-raspberrypi/recipes-devtools/python/rpio
     meta-raspberrypi/recipes-devtools/python/rpio/*.patch
     meta-raspberrypi/recipes-devtools/python/rpio_0.10.0.bb
     meta-raspberrypi/recipes-devtools/wiringPi
     meta-raspberrypi/recipes-devtools/wiringPi/files
     meta-raspberrypi/recipes-devtools/wiringPi/files/*.patch
     meta-raspberrypi/recipes-devtools/wiringPi/wiringpi_git.bb
     meta-raspberrypi/recipes-graphics
     meta-raspberrypi/recipes-graphics/eglinfo
     meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-fb_%.bbappend
     meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-x11_%.bbappend
     meta-raspberrypi/recipes-graphics/mesa
     meta-raspberrypi/recipes-graphics/mesa/mesa-gl_%.bbappend
     meta-raspberrypi/recipes-graphics/mesa/mesa_%.bbappend
     meta-raspberrypi/recipes-graphics/userland
     meta-raspberrypi/recipes-graphics/userland/userland
     meta-raspberrypi/recipes-graphics/userland/userland/*.patch
     meta-raspberrypi/recipes-graphics/userland/userland_git.bb
     meta-raspberrypi/recipes-graphics/vc-graphics
     meta-raspberrypi/recipes-graphics/vc-graphics/files
     meta-raspberrypi/recipes-graphics/vc-graphics/files/egl.pc
     meta-raspberrypi/recipes-graphics/vc-graphics/files/vchiq.sh
     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics-hardfp.bb
     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.bb
     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.inc
     meta-raspberrypi/recipes-graphics/wayland
     meta-raspberrypi/recipes-graphics/wayland/weston_%.bbappend
     meta-raspberrypi/recipes-graphics/xorg-xserver
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/98-pitft.conf
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/99-calibration.conf
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
     meta-raspberrypi/recipes-kernel
     meta-raspberrypi/recipes-kernel/linux-firmware
     meta-raspberrypi/recipes-kernel/linux-firmware/files
     meta-raspberrypi/recipes-kernel/linux-firmware/files/brcmfmac43430-sdio.bin
     meta-raspberrypi/recipes-kernel/linux-firmware/files/brcfmac43430-sdio.txt
     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
     meta-raspberrypi/recipes-kernel/linux
     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-dev.bb
     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc
     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.14.bb
     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb
     meta-raspberrypi/recipes-multimedia
     meta-raspberrypi/recipes-multimedia/gstreamer
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx/*.patch
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_%.bbappend
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12
     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12/*.patch
     meta-raspberrypi/recipes-multimedia/omxplayer
     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer
     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer/*.patch
     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb
     meta-raspberrypi/recipes-multimedia/x264
     meta-raspberrypi/recipes-multimedia/x264/x264_git.bbappend
     meta-raspberrypi/wic
     meta-raspberrypi/wic/sdimage-raspberrypi.wks

1.3.1. Файлы лицензий

Файлы лицензий на уровне BSP имеют форму meta-bsp_root_name/bsp_license_file. Эти необязательные файлы указывают лицензионные требования для BSP. Тип файлов может зависеть от лицензии. Например, в Raspberry Pi BSP все лицензионные требования даны в файле COPYING.MIT. Лицензии могут быть MIT, BSD, GPLv* и пр. Требованиям к лицензиям даны в разделе Maintaining Open Source License Compliance During Your Product’s Lifecycle [1].

1.3.2. Файл README

Файл meta-bsp_root_name/README содержит сведения о загрузке live-образов, которые могут включаться в каталог binary/, а также информацию, требуемую для сборки образа (по меньшей мере список зависимостей и данные сопровождающего BSP).

1.3.3. Файл README.sources

Файл meta-bsp_root_name/README.sources содержит информацию о местоположении исходных файлов BSP, использованных для сборки образов (при наличии), которые находятся в meta-bsp_root_name/binary. Эти образы распространяются с BSP. Информация в файле также помогает найти метаданные, использованные для генерации образов, распространяемых с BSP. Если каталог binary отсутствует или не содержит образов, файл README.sources не имеет смысла и обычно не включается.

1.3.4. Готовые двоичные файлы

Необязательная область meta-bsp_root_name/binary/bootable_images может включать собранные образы ядер и пользовательских файловых систем, распространяемых с BSP и подходящих для целевой системы. Этот каталог обычно содержит live-образы и образы с поддержкой графики (например, Sato), когда создается архив BSP для распространения через сайт YP. Эти ядра и образы можно применять для ускорения работы.

Тип двоичных файлов существенно зависит от аппаратной платформы. В файле README уровня BSP следует описывать использование этих образов с целевым оборудованием. Кроме того, в файле README.sources следует указывать местоположение исходного кода, использованного для сборки образов, а также сведения о метаданных.

1.3.5. Файл конфигурации уровня

Файл meta-bsp_root_name/conf/layer.conf описывает файловую структуру уровня и содержит информацию о ее использовании системой сборки. Обычно применяется стандартный шаблон файла, пример которого показан ниже с использованием bsp в качестве замены имени реального уровня BSP (bsp_root_name в шаблоне).

# We have a conf and classes directory, add to BBPATH
     BBPATH .= ":${LAYERDIR}"

     # We have a recipes directory, add to BBFILES
     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                 ${LAYERDIR}/recipes-*/*/*.bbappend"

     BBFILE_COLLECTIONS += "bsp" BBFILE_PATTERN_bsp = "^${LAYERDIR}/" BBFILE_PRIORITY_bsp = "6" LAYERDEPENDS_bsp = "intel"

Для иллюстрации подстановки строк ниже приведены операторы из файла conf/layer.conf для Raspberry Pi.

     # We have a conf and classes directory, append to BBPATH
     BBPATH .= ":${LAYERDIR}"

     # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
     BBFILES += "${LAYERDIR}/recipes*/*/*.bb \
                 ${LAYERDIR}/recipes*/*/*.bbappend"

     BBFILE_COLLECTIONS += "raspberrypi"
     BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/"
     BBFILE_PRIORITY_raspberrypi = "9"

     # Additional license directories.
     LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"
          ...

Этот файл просто указывает BitBake каталоги заданий и конфигурации. Файл нужен для распознавания BSP системой сборки OE.

1.3.6. Опции настройки оборудования

Файлы meta-bsp_root_name/conf/machine/*.conf содержат информацию о машине в понятном системе сборки формате. На каждом уровне BSP должен быть хотя бы один файл конфигурации машины. При поддержке нескольких машин может использоваться множество файлов. Имена файлов соответствуют значениям в переменной MACHINE.

Эти файлы определяют используемый пакет ядра (PREFERRED_PROVIDER в virtual/kernel), аппаратные драйверы для включения в разные типы образов, требуемые специальные программы и данные загрузчика, а также специальные требования к формату образов. Файлы могут также включать тонкую настройку оборудования, которая обычно применяется для определения архитектуры пакетов и специальных флагов оптимизации. Файлы тонкой настройки размещаются в каталоге meta/conf/machine/include дерева исходного кода. Например, многие файлы tune-* (tune-arm1136jf-s.inc, tun-1586-nlp.inc и т. п.) находятся в каталоге poky/meta/conf/machine/include.

Для использования включаемых файлов нужно просто указать их в файле конфигурации машины. Например, файл Raspberry Pi BSP raspberrypi3.conf содержит строку include conf/machine/include/rpi-base.inc.

1.3.7. Другие файлы BSP

Остальные файлы размещаются на уровне BSP в meta-bsp_root_name/recipes-bsp/*. Этот необязательный каталог содержит разные файлы заданий для BSP, среди которых наиболее важны файлы formfactor. Например, в Raspberry Pi BSP имеется файл formfactor_0.0.bbappend, который расширяет задание. Кроме того, имеются специфические для машины настройки, которые определяются файлом machconfig, например, для Raspberry Pi BSP machconfig имеет вид

     HAVE_TOUCHSCREEN=0
     HAVE_KEYBOARD=1

     DISPLAY_CAN_ROTATE=0
     DISPLAY_ORIENTATION=0
     DISPLAY_DPI=133

Если BSP не включает записи formfactor, используются параметры из принятого по умолчанию файла formfactor, используемого основным заданием meta/recipes-bsp/formfactor/formfactor_0.0.bb в дереве исходного кода.

1.3.8. Файлы поддержки дисплеев

Файлы поддержки дисплея находятся в meta-bsp_root_name/recipes-graphics/*. Этот необязательный каталог содержит задания для BSP, имеющих особые требования по поддержке графики (все файлы BSP для поддержки дисплеев).

1.3.9. Конфигурация ядра Linux

Файлы конфигурации ядра на уровне BSP включают

meta-bsp_root_name/recipes-kernel/linux/linux*.bbappend meta-bsp_root_name/recipes-kernel/linux/*.bb

Файлы дополнения (*.bbappend) меняют основное задание для ядра, используемое при сборке образа. Файлы *.bb содержат представленные разработчиком задания для ядра. Эта часть иерархии BSP может включать оба типа файлов, хотя на практике зачастую применяется лишь один.

Обычно для BSP применяется имеющееся в YP ядро из каталога исходных кодов meta/recipes-kernel/linux. Зависящие от машины изменения можно внести в файл добавления с похожим на задание именем, который размещается на уровне BSP для целевого устройства (например, в каталоге meta-bsp_root_name/recipes-kernel/linux). Предположим, что для сборки ядра служит задание linux-yocto_4.4.bb, т. е. оно указано в переменных PREFERRED_PROVIDER и PREFERRED_VERSION файла bsp_root_name.conf в форме

     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
     PREFERRED_VERSION_linux-yocto ?= "4.4%"

При использовании принятого по умолчанию предпочтительного провайдера переменная PREFERRED_PROVIDER не включается в файл bsp_root_name.conf. Файл linux-yocto_4.4.bbappend добавляет конкретные установки BSP в ядро, настраивая его для определенного устройства. Описание файлов дополнения приведено в разделе Creating the Append File [2].

Другим вариантом является организация своего задания для ядра в составе BSP. Примером может служить Raspberry Pi BSP, где в каталоге recipes-kernel/linux содержатся файлы трех заданий и включаемый файл.

     linux-raspberrypi-dev.bb
     linux-raspberrypi.inc
     linux-raspberrypi_4.14.bb
     linux-raspberrypi_4.9.bb

1.4. Разработка BSP

Здесь кратко рассмотрена процедура создания BSP на примере уровня meta-intel (см. также раздел 1.8. Создание уровня BSP с помощью сценария bitbake-layers). Процесс создания BSP показан на рисунке и кратко описан ниже.

  • Организация хоста для работы с YP в соответствии с разделом Preparing the Build Host [1].
  • Организация локального репозитория meta-intel для получения доступа к уровням, которые можно использовать при создании своего BSP (см. раздел 1.2. Подготовка хоста сборки для работы с уровнем BSP).
  • Создание своего уровня BSP с использованием сценария bitbake-layers. Уровни обеспечивают идеальное решение для изоляции и хранения работы с конкретным оборудованием. Уровень представляет собой просто хранилище (каталог) для заданий и файлов конфигурации BSP. Фактически BSP является просто одним из типов уровней. Проще всего создать совместимый с YP уровень BSP используя сценарий bitbake-layers (см. раздел 1.8. Создание уровня BSP с помощью сценария bitbake-layers).Другим примером использования уровней являются приложения. Предположим, что создается приложение, которое включает библиотеку или иную зависимость при компиляции и работе. В этом случае уровень будет содержать задания, где указаны все эти зависимости. Уровень по сути является изолированной областью, содержащей всю относящуюся к делу информацию, которую нужно знать системе сборки OE. Уровни более подробно описаны в разделе The Yocto Project Layer Model и Understanding and Creating Layers [1], а также в разделе 1.1. Уровни BSP.
    • В выпуске YP имеется 5 эталонных BSP на уровне poky/meta-yocto-bsp:
        • Texas Instruments Beaglebone (beaglebone-yocto);
        • Freescale MPC8315E-RDB (mpc8315e-rdb);
        • Ubiquiti Networks EdgeRouter Lite (edgerouter);
        • 2 платформы общего назначения IA (genericx86 и genericx86-64).
    • Три базовых Intel BSP имеются в выпуске YP на уровне meta-intel:
        • intel-core2-32, оптимизированный для семейства Core2, а также процессоров до Silvermont;
        • intel-corei7-64, оптимизированный для Nehalem и последующих процессоров Core и Xeon, а также Silvermont и поздних Atom, таких как Baytrail;
        • intel-quark, оптимизированный для плат Intel Galileo gen1 и gen2.

При создании уровня BSP следует соблюдать стандартную схему, описанную в разделе 1.3. Пример структуры файлов, обращая внимание на структуру заданий и файлов конфигурации. В качестве примеров можно использовать поддерживаемые BSP уровня meta-intel в дереве исходного кода.

  • Настройка конфигурации уровня BSP. В стандартной структуре BSP файлы, которые нужно редактировать, размещаются в каталоге conf и нескольких каталогах recipes-* уровня BSP. Изменения конфигурации включают размещение уровня в локальной системе и указывают используемое ядро. При запуске сценария bitbake-layers можно в интерактивном режиме задать многие настройки BSP (клавиатура, сенсорный экран и т. п.).
  • Изменение заданий нового уровня BSP, включая редактирование файлов *.bb, удаление ненужных заданий и добавления новых заданий и/или файлов дополнения (.bbappend) для поддержки оборудования.
  • Подготовка к сборке. После внесения изменений в уровень BSP остается организовать среду сборки с помощью сценария oe-init-build-env и убедиться в корректности содержимого файлов conf/local.conf и conf/bblayers.conf. Система сборки OE должна знать о новом уровне (см. раздел Enabling Your Layer [1]).
  • Сборка образа. Система сборки OE использует BitBake для создания образов заданного типа (см. руководство пользователя BitBake). Процесс сборки поддерживает разные типов образов, описанные в разделе Images [3].

1.5. Требования и рекомендации для выпуска BSP

Существует ряд требований к выпускаемым BSP в части их совместимости с YP, описанных в этом разделе.

1.5.1. Требования к выпускаемым BSP

Перед рассмотрением требований к BSP следует учесть некоторые аспекты.

  • Предполагается, что уровень BSP корректно сформирован и пригоден для добавления в YP. Рекомендации по созданию уровней приведены в разделе 1.1. Уровни BSP и Understanding and Creating Layers [1].
  • Применение требований не зависит от способа упаковки BSP. Пример требований к упаковке и распространению приведен на странице Third Party BSP Release Process.
  • Требования к BSP в том виде, как уровень представляется разработчику совершенно не зависят от формы выпускаемого BSP. Например, метаданные BSP могут содержаться в репозитории Git и иметь структуру каталогов, совершенно отличающуюся от официально выпущенного BSP.

  • Не требуется включать какие-то определенные пакеты или модификации в BSP сверх требований общего соответствия YP. Например, не задается требований использовать определенную версию ядра в BSP.

Ниже приведены требования к BSP для выпуска в составе YP.

  • Имя уровня должно соответствовать стандартам YP, как указано в разделе 1.1. Уровни BSP.
  • Структура файловой системы. По возможности следует использовать на уровне BSP имена каталогов, указанные в файле recipes.txt из каталога poky/meta в дереве источников или уровня openembedded-core (http://git.openembedded.org/openembedded-core/tree/meta). Следует размещать файлы заданий *.bb и дополнения *.bbappend в каталогах recipes-* по функциональным областям, указанным в файле recipes.txt. Если в этом файле нет подходящей категории для того или иного задания, можно создать свой каталог recipes-*. Внутри категорий recipes-* структура должна соответствовать репозиторию Git openembedded-core или дереву исходных кодов poky. Связанные файлы следует размещать в подходящем каталоге recipes-* в соответствии с функциями задания. Сами задания следует оформлять в соответствии с руководством OpenEmbedded Style.
  • Файл лицензий должен размещаться в каталоге meta-bsp_root_name. Лицензия охватывает метаданные BSP в целом и ее нужно указать, поскольку принятой по умолчанию лицензии не задано. Примером может служить файл COPYING.MIT для Raspberry Pi BSP уровня meta-raspberrypi.
  • Файл README должен размещаться в каталоге meta-bsp_root_name. Примером может служить файл README.md для Raspberry Pi BSP уровня meta-raspberrypi. Файл должен включать по меньшей мере перечисленное ниже.
    • Краткое описание оборудования для BSP.

    • Список всех зависимостей уровня BSP, который обычно включает другие уровни, требуемые для сборки BSP, однако может включать и другие зависимости.

    • Особые требования лицензирования, например, переменные, требуемые для EULA, или инструкции по сборке и распространению двоичных файлов, собранных с метаданными BSP.

    • Имя и контактные данные сопровождающего уровень BSP (человек, которому можно отправлять правки и вопросы), в соответствии с разделом Submitting a Change to the Yocto Project [1].
    • Инструкции по сборке BSP с использованием данного уровня.

    • Инструкции по загрузке образа, собранного из уровня BSP.

    • Инструкции по загрузке двоичных образов, если они имеются в каталоге.
    • Информация об известных ошибках при сборке или загрузке двоичных образов BSP.

  • Файл README.sources должен включаться в каталог meta-bsp_root_name при наличии в BSP двоичных образов (каталог binary). Файл указывает местоположение исходного кода для сборки двоичных файлов.
  • Файл конфигурации уровня conf/layer.conf в каталоге meta-bsp_root_name, указывающий уровень BSP для системы сборки.
  • Файлы конфигурации машины в каталоге conf/machine/bsp_root_name.conf внутри meta-bsp_root_name. Эти файлы определяют целевые машины, для которых предназначен уровень BSP. Если BSP поддерживает несколько вариантов машины, нужно описать каждый вариант в файле README уровня BSP. Не следует включать файлы конфигурации для разнотипных машин, лучше создавать для них свои уровни BSP.

Разработчик может по-своему структурировать рабочие репозитории файлов BSP и готовить их к выпуску, пользуясь своими сценариями или иными средства. Этот вопрос выходит за рамки документа.

1.5.2. Рекомендации для выпуска BSP

  • Загружаемые образы. Выпускаемые BSP могут включать загружаемые образы, что позволяет пользователям легко проверить BSP на своем оборудовании. В некоторых случаях включение загружаемых образов может оказаться неудобным и тогда можно сделать два варианта BSP, включая такие образы лишь в один из них. Это позволит избежать загрузки ненужных файлом теми пользователями, которым они не требуются.Если нужно распространять BSP с загружаемыми образами или собирать ядро и файловые системы, предназначенные для загрузки BSP с целью оценки, следует помещать образы и результаты сборки в каталог binary/ внутри meta-bsp_root_name. Если включенный в BSP двоичный образ собран с использованием программ, распространяемых по лицензии GPL или иной лицензии для открытого кода, нужно выполнить все требования лицензии в части распространения исходного кода программ.
  • Использование ядра Yocto Linux. Задания для ядра в BSP следует основывать на ядрах Yocto Linux, что позволит снизить издержки на сопровождение BSP. Ядра доступны в Source Repositories.

1.6. Настройка задания для BSP

При планировании задания для конкретного BSP следует учитывать приведенные ниже требования.

  • Для измененного задания следует создать файл дополнения *.bbappend, как описано в разделе Using .bbappend Files in Your Layer [1].
  • Структура каталогов уровня BSP, поддерживающего машину, должна быть устроена так, чтобы система сборки OE могла найти ее (см. пример ниже).

  • Файл дополнения следует поместить в каталог, соответствующий имени машины, в подходящем каталоге структуры уровня BSP (recipes-bsp, recipes-graphics, recipes-core и т. п.).
  • Относящиеся к BSP файлы следует размещать в подходящих каталогах внутри уровня BSP. Например, если уровень поддерживает несколько типов машины, нужно обеспечить иерархию каталогов, разделяющую файлы по машинам. Если поддерживается лишь одна машина, такая иерархия не нужна и все файлы могут размещаться в каталоге для машины.

Ниже приведен пример настройки задания путем добавления файла init-ifupdown_1.0.bb для машины xyz в уровне BSP, поддерживающем несколько разных машин.

  1. Следует включить в файл init-ifupdown_1.0.bbappend строку вида FILESEXTRAPATHS_prepend := «${THISDIR}/files:». Файл дополнения должен размещаться в каталоге meta-xyz/recipes-core/init-ifupdown.
  2. Создается файл конфигурации интерфейсов на уровне BSP и помещается в meta-xyz/recipes-core/init-ifupdown/files/xyz-machine-one/interfaces. Если уровень meta-xyz не включает множества машин, можно поместить файл конфигурации интерфейсов в каталог meta-xyz/recipes-core/init-ifupdown/files/interfaces. Переменная FILESEXTRAPATHS в файле дополнения расширяет путь поиска системы сборки для нахождения файлов, поэтому каталог files нужно разместить там же, где находится файл дополнения.

1.7. Вопросы лицензирования BSP

В некоторых случаях BSP содержит отдельно лицензируемую интеллектуальную собственность (IP), поэтому требуется принять условия коммерческого или иного использования, требующие явного лицензионного соглашения с конечным пользователем (EULA). Когда такое соглашение принято, система сборки OE сможет использовать соответствующие компоненты при создании образа BSP. Если BSP доступен в собранном виде, можно загрузить образ после согласия с лицензией или EULA.

Могут возникать ситуации, когда важные для работы системы компоненты могут не иметь свободных (или бесплатных) замен, а без этих компонент система не будет работать. И напротив, могут возникать ситуации, когда другие лицензируемые компоненты пригодные для использования или необязательные имеют бесплатную замену, которую можно применять вместо согласия на отдельно лицензируемые компоненты. Даже для важных в системе компонент могут быть свободные замены, которые не обеспечивают полной функциональности, но вполне пригодны.

В случаях, когда возможна замена свободными компонентами с сохранением функциональности, выбор DOWNLOADS на вкладке SOFTWARE сайта YP делает доступными “усеченные” BSP, свободные от ограничений IP. В таких случаях замену можно применять напрямую без дополнительного лицензирования. При наличии “усеченных” BSP они именуются иначе, нежели полные варианты BSP, и обычно предполагают соответствие требованиям системы. Если таких вариантов нет или они недостаточно функциональны, придется использовать “обремененную” версию.

В системе сборки OE имеется иной метод выполнения лицензионных требований с обременением, описанный ниже.

  1. Использование переменной LICENSE_FLAGS для заданий, имеющих пакеты с коммерческими и иными специальными лицензиями. Для каждого из таких заданий можно указать соответствующую строку лицензии в файле local.conf (переменная LICENSE_FLAGS_WHITELIST), что будет указывать согласие с лицензией. В результате система сборки может собирать соответствующее задание и включать компоненты в образ. Использование переменных описано в разделе Enabling Commercially Licensed Recipes [1]. Если заданий не указано в переменной LICENSE_FLAGS_WHITELIST, сборка будет остановлена с выводом списка заданий, которые включены в создание образа, но не указаны в LICENSE_FLAGS_WHITELIST. После указания таких заданий в переменной следует повторить сборку.
  2. Использование собранной версии BSP, доступной по ссылке DOWNLOADS вкладки SOFTWARE на сайте YP. Можно загрузить архивы BSP с фирменными компонентами после согласия с лицензионными требованиями каждого из пакетов в процессе загрузки. Такой способ получения BSP обеспечивает доступ к образу сразу после принятия лицензионного соглашения, представленного на сайте. При самостоятельной сборке образов с использованием заданий из таких BSP нужно будет создать соответствующую LICENSE_FLAGS_WHITELIST, соответствующую заданиями из BSP. Предварительно собранные образы включают ограничения по времени использования в ядре (10 дней), после чего система перезагружается. Это предотвращает дальнейшее распространение образа и для снятия ограничения образ потребуется собрать заново.

1.8. Создание уровня BSP с помощью сценария bitbake-layers

Сценарий bitbake-layers автоматизирует создание уровня BSP, который отличается от других уровней наличием файла конфигурации машины. Кроме того, такие уровни обычно имеют задание для ядра или файл дополнения к имеющемуся заданию. Операции создания уровня BSP перечислены ниже.

  • Создание обычного уровня с помощью команды bitbake-layers create-layer, как описано в разделе Creating a General Layer Using the bitbake-layers Script [1].
  • Создание файла конфигурации, который нужен на каждом уровне и указывает метсоположение заданий уровня, приоритет уровня и т. п. Примеры файлов layer.conf files представлены на странице YP Source Repositories. Для получения примеров можно выбрать уровень (скажем, meta-ti) и загрузить его конфигурационный файл.
  • Создание файла конфигурации машины в форме conf/machine/bsp_root_name.conf. Примером могут служить файлы из каталога meta-yocto-bsp/conf/machine, а также каталоги производителей meta-ti и meta-freescale.
  • Подготовка задания для ядра в форме recipes-kernel/linux с использованием файла добавления или созданием нового файла (например, yocto-linux_4.12.bb). Образцы можно найти в упомянутых выше уровнях, а рекомендации по подготовке заданий для ядра даны в разделе Modifying an Existing Recipe [2].

Далее уровень BSP рассматривается на примере эталонного YP BSP для Beaglebone с уровня meta-yocto-bsp.

1.8.1. Пример конфигурации уровня BSP

Каталог conf внутри уровня содержит файл layer.conf, пример которого представлен ниже.

     # We have a conf and classes directory, add to BBPATH
     BBPATH .= ":${LAYERDIR}"

     # We have recipes-* directories, add to BBFILES
     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                 ${LAYERDIR}/recipes-*/*/*.bbappend"

     BBFILE_COLLECTIONS += "yoctobsp"
     BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
     BBFILE_PRIORITY_yoctobsp = "5"
     LAYERVERSION_yoctobsp = "4"
     LAYERSERIES_COMPAT_yoctobsp = "zeus"

Дополнительные примеры конфигурационных файлов BSP можно найти в Source Repositories. Подробное описание процесса создания файла конфигурации приведено в п. 3 раздела Creating Your Own Layer [1].

1.8.2. Пример конфигурации машины BSP

Как отмечено выше, наличие файла конфигурации машины является отличительной чертой уровней BSP. Этот файл размещается в каталоге bsp_layer/conf/machine/. Например, файл конфигурации плат BeagleBone и BeagleBone Black хранится в каталоге poky/meta-yocto-bsp/conf/machine и называется beaglebone-yocto.conf:

   #@TYPE: Machine
   #@NAME: Beaglebone-yocto machine
   #@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard.org/black boards

   PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
   XSERVER ?= "xserver-xorg \
              xf86-video-modesetting \
              "

   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"

   EXTRA_IMAGEDEPENDS += "u-boot"

   DEFAULTTUNE ?= "cortexa8hf-neon"
   include conf/machine/include/tune-cortexa8.inc

   IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
   EXTRA_IMAGECMD_jffs2 = "-lnp "
   WKS_FILE ?= "beaglebone-yocto.wks"
   IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage"
   do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"

   SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
   SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

   PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
   PREFERRED_VERSION_linux-yocto ?= "5.0%"

   KERNEL_IMAGETYPE = "zImage"
   KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
   KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"

   SPL_BINARY = "MLO"
   UBOOT_SUFFIX = "img"
   UBOOT_MACHINE = "am335x_evm_defconfig"
   UBOOT_ENTRYPOINT = "0x80008000"
   UBOOT_LOADADDRESS = "0x80008000"

   MACHINE_FEATURES = "usbgadget usbhost vfat alsa"

   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"

Переменные определяют машинозависимые свойства, например, специальные пакеты для машины, настройки, тип собираемого ядра, конфигурация U-Boot.

Ниже приведены некоторые пояснения из примеров файла конфигурации эталонной машины BeagleBone, а более полную информацию можно найти в разделе Yocto Project Variables Glossary [3].

  • PREFERRED_PROVIDER_virtual/xserverзадание, обеспечивающее virtual/xserver при наличии нескольких провайдеров. В данном случае в качестве virtual/xserver служит задание xserver-xorg из poky/meta/recipes-graphics/xorg-xserver.
  • XSERVERпакеты, которые следует установить для поддержки X-сервера и драйверов для машины. В примере устанавливаются пакеты xserver-xorg и xf86-video-modesetting.
  • MACHINE_EXTRA_RRECOMMENDSсписок определяемых машиной пакетов, которые не важны для загрузки образа (т. е. Не будет возникать отказа при их отсутствии), однако нужных при работе. Имеется много переменных MACHINE, помогающих настроить конкретные компоненты оборудования.
  • EXTRA_IMAGEDEPENDSсписок заданий для сборки, которые не предоставляют пакетов, устанавливаемых в корневую файловую систему, но от которых зависит сборка образа. В данном случае для сборки требуется задание U-Boot.
  • DEFAULTTUNEнастройки для оптимизации производительности машины, CPU и приложений. Эти свойства, называемые настройками производительности, размещаются на уровне OpenEmbedded-Core (OE-Core), например, в poky/meta/conf/machine/include. В примере используется настройка cortexa8hf-neon. Оператор include в файле conf/machine/include/tune-cortexa8.inc обеспечивает дополнительны возможности настройки.
  • IMAGE_FSTYPES задает формат, применяемый системой сборки OE при создании корневой файловой системы. В примере поддерживаются 4 типа образов.
  • EXTRA_IMAGECMD задает опции команды создания образа. В примере «-lnp » задает создание образа JFFS2.
  • WKS_FILE указывает местоположение файла Wic kickstart, используемого системой сборки OE для создания образа с разделами (image.wic).
  • IMAGE_INSTALL задает пакеты, устанавливаемые в образ через класс image.
  • do_image_wic[depends] указывает задачи, создаваемые в процессе сборки. В примере задача зависит от инструментов, применяемых для создания sysroot в процессе сборки образа Wic.
  • SERIAL_CONSOLES включает последовательные консоли (TTY) для getty. В примере задана скорость 115200 и имя устройства ttyO0.
  • PREFERRED_PROVIDER_virtual/kernel указывает задание, обеспечивающее virtual/kernel при наличии нескольких провайдеров. В примере таким заданием служит linux-yocto из каталога recipes-kernel/linux.
  • PREFERRED_VERSION_linux-yocto указывает версию задания, используемого для сборки ядра (5.0).
  • KERNEL_IMAGETYPEтип ядра для устройства. В примере система сборки OE создает образ типа zImage.
  • KERNEL_DEVICETREE указывает имена создаваемых файлов дерева устройств ядра Linux (*.dtb). В примере включены все деревья разных устройств BeagleBone.
  • KERNEL_EXTRA_ARGS указывает дополнительные аргументы, которые система сборки OE передает при компиляции ядра. В примере это «LOADADDR=${UBOOT_ENTRYPOINT}».
  • SPL_BINARY определяет тип вторичного загрузчика программ (SPL2). В примере это MLO (Multimedia card Loader), поскольку плата BeagleBone требует SPL этого типа. Дополнительные сведения о применении переменных SPL приведены в файле u-boot.inc.
  • UBOOT_* — определяет различные конфигурации U-Boot, требуемые для загрузки образа U-Boot. В примере образ U-Boot нужен для загрузки устройства BeagleBone. Задан также ряд дополнительных переменных:
    • UBOOT_SUFFIX указывает созданное расширение U-Boot;
    • UBOOT_MACHINE указывает значение, передаваемое команде make при сборке образа U-Boot;
    • UBOOT_ENTRYPOINT задает точку входа в образ U-Boot;
    • UBOOT_LOADADDRESS задает адрес загрузки образа U-Boot.
  • MACHINE_FEATURES задает список поддерживаемых аппаратных свойств BeagleBone. В примере это «usbgadget usbhost vfat alsa».
  • IMAGE_BOOT_FILESуказывает файлы, устанавливаемые в коренной раздел устройства при подготовке образа с использованием Wic и плагина bootimg-partition source.

1.8.3. Пример задания для ядра в BSP

Задание для ядра, применяемое при сборке ядра для устройства BeagleBone, указано в конфигурации машины.

     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
     PREFERRED_VERSION_linux-yocto ?= "5.0%"

Каталог meta-yocto-bsp/recipes-kernel/linux на уровне содержит метаданные, используемые для сборки ядра. В данном случае файл дополнения (linux-yocto_5.0.bbappend) переопределяет имеющееся задание (linux-yocto_5.0.bb) из http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux. Содержимое файла приведено ниже.

     KBRANCH_genericx86  = "v5.0/standard/base"
     KBRANCH_genericx86-64  = "v5.0/standard/base"
     KBRANCH_edgerouter = "v5.0/standard/edgerouter"
     KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
     KBRANCH_mpc8315e-rdb = "v5.0/standard/fsl-mpc8315e-rdb"

     KMACHINE_genericx86 ?= "common-pc"
     KMACHINE_genericx86-64 ?= "common-pc-64"
     KMACHINE_beaglebone-yocto ?= "beaglebone"

     SRCREV_machine_genericx86    ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
     SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
     SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
     SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
     SRCREV_machine_mpc8315e-rdb ?= "8b62af7f252af10588276802c4c6d7c502e875be"

     COMPATIBLE_MACHINE_genericx86 = "genericx86"
     COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
     COMPATIBLE_MACHINE_edgerouter = "edgerouter"
     COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"

     LINUX_VERSION_genericx86 = "5.0.3"
     LINUX_VERSION_genericx86-64 = "5.0.3"
     LINUX_VERSION_edgerouter = "5.0.3"
     LINUX_VERSION_beaglebone-yocto = "5.0.3"
     LINUX_VERSION_mpc8315e-rdb = "5.0.3"

Этот файл дополнения работает для всех машин уровня meta-yocto-bsp. Соответствующие операторы добавляются в строку beaglebone-yocto и система сборки OE применяет эти операторы для переопределений в задании для ядра:

  • KBRANCH указывает ветвь ядра, которая была проверена, исправлена (patch) и настроена при сборке;
  • KMACHINE задает имя машины, известное ядру, которое может отличаться от имени в системе сборки OE;
  • SRCREV указывает выпуск исходного кода, использованный для сборки образа;
  • COMPATIBLE_MACHINE задает регулярное выражение, преобразуемое в имя одной или нескольких машин, совместимых с образом;
  • LINUX_VERSION указывает версию Linux из kernel.org, используемую системой OE для сборки образа ядра.

Литература

[1] Yocto Project Development Tasks Manual, https://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html.

[2] Yocto Project Linux Kernel Development Manual, https://www.yoctoproject.org/docs/3.0/kernel-dev/kernel-dev.html.

[3] Yocto Project Reference Manual, https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html.

[4] Yocto Project Overview and Concepts Manual, https://www.yoctoproject.org/docs/3.0/overview-manual/overview-manual.html.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Board Support Package — пакет поддержки платы.

2Secondary Program Loader.

Рубрика: Linux | Комментарии к записи Руководство разработчика Yocto Project BSP отключены

Справочник по Yocto Project (часть 4)

Часть 3


O

OBJCOPY

Сокращенная команда и аргументы для запуска objcopy.

OBJDUMP

Сокращенная команда и аргументы для запуска objdump.

OE_BINCONFIG_EXTRA_MANGLE

При наследовании класса binconfig указывает дополнительные аргументы для команды sed, которая меняет пути в сценариях конфигурации, установленные во время компиляции. Наследование этого класса ведет к изменению всех путей в сценариях конфигурации так, чтобы они указывали каталог sysroot, чтобы все сборки, использующие сценарий применяли корректные каталоги для кросс-компиляции. Детали применения класса приведены в файле meta/classes/binconfig.bbclass каталога исходных кодов, а базовая информация — в параграфе 6.7. binconfig.bbclass.

OE_IMPORTS

Внутренняя переменная, указывающая системе сборки OE модули Python, импортируемые для каждой функции Python, выполняемой системой. Не нужно устанавливать эту переменную.

OE_INIT_ENV_SCRIPT

Имя сценария настройки среды сборки для организации работы в расширяемом SDK (по умолчанию oe-init-build-env). Для пользовательских сценариев настройки следует указывать имя сценария в переменной.

OE_TERMINAL

Управляет вызовом интерактивных терминалов системой сборки OE на сборочном хосте (например, использование команды BitBake с опцией -c devshell). Работа с терминальными сессиями описана в разделе Using a Development Shell [2]. Переменная OE_TERMINAL может принимать значения auto, gnome, xfce, rxvt, screen, konsole, none.

OEROOT

Каталог, из которого запускается сценарий верхнего уровня для настройки окружения (oe-init-build-env). При запуске сценария переменная OEROOT преобразуется в имя каталога, где этот сценарий размещен.

OLDEST_KERNEL

Указывает минимальную версию ядра Linux, с которой будут работать собираемые двоичные файлы. Эта переменная передается в сборку встроенной библиотеки glibc. По умолчанию эта переменная принимает значение из файла meta/conf/bitbake.conf, которое можно переопределить ф файле конфигурации дистрибутива.

OVERRIDES

Список разделенных двоеточиями переопределений, которые будут применены. Переопределения в BitBake позволяют селективно изменять значения переменных при завершении анализа. Набор переопределений в переменной OVERRIDES представляет «состояние» в процессе сборки, которое включает собираемое задание, машину, для которой выполняется сборка и т. п.

Например, если строка an-override представлена как элемент списка в OVERRIDES, приведенное назначение FOO_an-override = «overridden» будет переопределять FOO значением overridden в конце анализа.

В разделе Conditional Syntax (Overrides) [4] механизм переопределения описан более подробно.

Принятое по умолчанию значение OVERRIDES включает значения переменных CLASSOVERRIDE, MACHINEOVERRIDES и DISTROOVERRIDES. Другим важным переопределением, включенным по умолчанию, является pn-${PN}. Это позволяет установить переменные для определенного задания в файлах .conf. Например, FOO_pn-myrecipe = «myrecipe-specific value».

Простым способом узнать используемые переопределения является поиск строки OVERRIDES в выводе команды bitbake -e (см. раздел Viewing Variable Values [2]).

P

P

Имя и версия задания в форме ${PN}-${PV}.

PACKAGE_ARCH

Архитектура собираемых пакетов. По умолчанию для этой переменной устанавливается значение TUNE_PKGARCH при сборке пакета для целевой платформы, BUILD_ARCH при сборке для сборочного хоста и ${SDK_ARCH}-${SDKPKGSUFFIX} при сборке для SDK (см. SDK_ARCH). Однако, если выходные пакеты задания связаны с конкретной целевой системой, а не с базовой архитектурой машины, следует устанавливать в задании для PACKAGE_ARCH значение переменной MACHINE_ARCH
в
форме

PACKAGE_ARCH = «${MACHINE_ARCH}»

PACKAGE_ARCHS

Задает список архитектур, совместимых с целевой машиной. Эта переменная устанавливается автоматически и обычно не следует менять ее вручную. Записи в списке разделяются пробелами и упорядочены по приоритету. По умолчанию переменная имеет значение ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}.

PACKAGE_BEFORE_PN

Включает легко добавляемые пакеты в PACKAGES перед ${PN} так, что эти пакеты могут указывать файлы, которые обычно включаются в принятые по умолчанию пакеты.

PACKAGE_CLASSES

Эта переменная, устанавливаемая в файле conf/local.conf каталога сборки, задает менеджер пакетов, который система сборки OE использует для упаковки. Можно указать в переменной один или несколько менеджеров, например, PACKAGE_CLASSES ?= «package_rpm package_deb package_ipk package_tar». Хотя класс package_tar и поддерживается, его функциональность ограничена, поскольку для него не поддерживаются зависимости между пакетами в машине установки. Поэтому применять данный класс не рекомендуется.

Система сборки использует только первый элемент из списка в качестве менеджера пакетов при создании образа или SDK. Однако пакеты будут создаваться с использованием и дугих указанных менеджеров. Например, для использования менеджера пакетов IPK в файле local.conf задается строка PACKAGE_CLASSES ?= «package_ipk».

Дополнительная информация о влиянии менеджера пакетов на производительность упаковки и сборки рассмотрена в параграфе 6.88. package.bbclass.

PACKAGE_DEBUG_SPLIT_STYLE

Определяет расщепление двоичных файлов и отладочной информации при создании пакетов *-dbg для отладчика GDB1. Переменная позволяет управлять местом размещения отладочной информации, которая может включать исходные файлы.

  • .debug задает размещение отладочных символов вместе с двоичными файлами в каталоге .debug на целевой платформе. Например, при установке двоичного файла в /bin соответствующие отладочные символы будут помещены в /bin/.debug. Исходные коды помещаются в /usr/src/debug.
  • debug-file-directory задает размещение отладочных символов /usr/lib/debug на целевой платформе и их разделение по пути установки двоичного файла. Например, при установке двоичного файла в /bin соответствующие отладочные символы помещаются в /usr/lib/debug/bin. Исходные коды помещаются в /usr/src/debug.
  • debug-without-srcпохоже на .debug, но файлы исходных кодов не устанавливаются.
  • debug-with-srcpkg похоже на .debug, но исходные файлы помещаются в отдельный пакет *-src pkg. Этот вариант применяется по умолчанию.

Отладка с использованием GDB описана в разделе Debugging With the GNU Project Debugger (GDB) Remotely [2].

PACKAGE_EXCLUDE_COMPLEMENTARY

Блокирует установку указанных пакетов при установке дополнений. Например, при использовании IMAGE_FEATURES для установки пакетов dev- можно отказаться от инсталляции всех пакетов, кроме определенного multilib. В переменной PACKAGE_EXCLUDE_COMPLEMENTARY можно указать регулярное выражение для отбора исключаемых из установки пакетов.

PACKAGE_EXCLUDE

Указывает пакеты, которые не следует устанавливать в образ. Например, PACKAGE_EXCLUDE = «package_name package_name package_name …». Эту переменную можно установить глобально в файле local.conf или присоединить к заданию для конкретного образа путем переопределения имени задания, как PACKAGE_EXCLUDE_pn-target_image = «package_name«.

При запросе отказа от установки пакета, от которого зависят другие пакеты (указаны в переменной RDEPENDS), система сборки OE будет давать критическую ошибку. Поскольку система сборки останавливает процесс, можно использовать переменную в итеративном процессе удаления из системы ненужных компонент.

Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.

См. также описания переменных BAD_RECOMMENDATIONS и NO_RECOMMENDATIONS.

PACKAGE_EXTRA_ARCHS

Задает список архитектур, совместимых с процессором устройства. Переменная полезна при сборке для нескольких разных устройств, использующих смешанные процессоры, например, XScale и ARM926-EJS.

PACKAGE_FEED_ARCHS

Опционально задает архитектуру, используемую как часть URI хранилищ пакетов при сборке. При наличии переменной ее значение добавляется к финальной части URI, созданных из переменных PACKAGE_FEED_URIS и PACKAGE_FEED_BASE_PATHS.

Можно использовать PACKAGE_FEEDS_ARCHS в качестве «белого списка» вариантов архитектуры пакетов. Если такой список не нужен (типичная ситуация), переменную можно опустить, что приведет к включению всех вариантов архитектуры для текущей машины из удаленного хранилища пакетов.

Рассмотрим пример, где PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_ARCHS заданы в файле local.conf, как показано ниже.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"  

С учетом этих определений идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_FEED_BASE_PATHS

Задает базовый путь, используемый при создании URI хранилищ пакетов, образуя среднюю часть URI, используемых системой сборки OE. Базовый путь включается между переменными PACKAGE_FEED_URIS и PACKAGE_FEED_ARCHS.

Рассмотрим пример, где PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS
и
PACKAGE_FEED_ARCHS определены в файле local.conf,
как
показано ниже.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"

В этом случае идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_FEED_URIS

Задает начальную часть URI хранилища пакета, используемого системой сборки OE. Полный идентификатор URI включает переменные PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS
и
PACKAGE_FEED_ARCHS.

В приведенном ниже примере переменные PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS
и
PACKAGE_FEED_ARCHS заданы в файле local.conf.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"

С учетом этих установок идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_GROUP

Переменная PACKAGE_GROUP была переименована в FEATURE_PACKAGES. Если вы продолжаете использовать PACKAGE_GROUP,
система
сборки
OE будет выдавать предупреждение.

PACKAGE_INSTALL

Окончательный список пакетов, передаваемый менеджеру пакетов для установки в образ. Этот список не обязательно совпадает с полным списком устанавливаемых пакетов. Эта переменная является внутренней для кода создания образа, поэтому в общем случае следует использовать IMAGE_INSTALL для указания устанавливаемых пакетов. Исключением является работа с образом core-image-minimal-initramfs. Для образов initramfs применяется переменная PACKAGE_INSTALL (см. Building an Initial RAM Filesystem (initramfs) Image [2]).

PACKAGE_INSTALL_ATTEMPTONLY

Задает список пакетов, которые система сборки OE пытается установить при создании образа. Если установка пакета не удается, система сборки не генерирует ошибки. Эту переменную пользователь обычно не задает.

PACKAGE_PREPROCESS_FUNCS

Задает список функций предварительной обработки каталога PKGD при разделении файлов по разным пакетам.

PACKAGE_WRITE_DEPS

Задает список зависимостей для сценарией предустановки и пост-установки инструментов native/cross. Если сценарий может выполняться во время создания rootfs, а не на целевой платформе, но зависит от естественного инструмента при работе, нужно указать этот инструмент в PACKAGE_WRITE_DEPS. Работа сценариев пост-установки описана в разделе Post-Installation Scripts [2].

PACKAGECONFIG

Эта переменная обеспечивает способ управления свойствами заданий на уровне отдельного задания. Блок PACKAGECONFIG определяется в заданиях при выборе свойств и аргументов для них. Ниже показана базовая структура блока.

     PACKAGECONFIG ??= "f1 f2 f3 ..."
     PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
     PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
     PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"

Сама переменная PACKAGECONFIG задает список разделенных пробелами свойств, которые нужно включить. Для каждого свойства можно задать поведение, указав до 5 упорядоченных аргументов, разделенных запятыми. Любой аргумент можно опустить, сохраняя запятые. Для аргументов применяется показанный ниже порядок.

  1. Дополнительные аргументы, которые следует добавить в список аргументов сценария настройки (EXTRA_OECONF или PACKAGECONFIG_CONFARGS), если свойство включено.
  2. Дополнительные аргументы для EXTRA_OECONF или PACKAGECONFIG_CONFARGS, если свойство выключено.
  3. Дополнительные зависимости при сборке (DEPENDS), если свойство включено.
  4. Дополнительные зависимости при работе (RDEPENDS), если свойство включено.
  5. Дополнительные рекомендации при работе (RRECOMMENDS), если свойство включено.

Рассмотрим блок PACKAGECONFIG из задания librsvg. В этом примере свойство croco имеет 3 аргумента, определяющих его поведение.

     PACKAGECONFIG ??= "croco"
     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"

Аргументы —with-croco и libcroco применяются лишь при включенном свойстве. В этом случае —with-croco добавляется к аргументам сценария настройки, а libcrocoв DEPENDS. Если свойство отключено (например, в файле .bbappend на другом уровне, к сценарию настройки добавляется аргумент —without-croco вместо —with-croco.

Показанная выше базовая структура PACKAGECONFIG одинакова для создания и изменения блока. При создании используется структура внутри задания. Для изменения имеющегося блока PACKAGECONFIG есть два способа.

  • Файл добавления. Создается файл .bbappend с именем задания на вашем уровне и в нем переопределяется значение PACKAGECONFIG. Можно полностью переопределить переменную PACKAGECONFIG = «f4 f5» или добавить значение в конце PACKAGECONFIG_append = » f4″
  • Файл конфигурации. Этот метод идентичен изменению блока через файл добавления, но редактируется файл local.conf или файл конфигурации дистрибутива. Можно переопределить переменную PACKAGECONFIG_pn-recipename = «f4 f5» или добавить значение в конце PACKAGECONFIG_append_pn-recipename = » f4″

PACKAGECONFIG_CONFARGS

Список разделенных пробелами опций настройки, создаваемый из переменной PACKAGECONFIG. Классы autotools и cmake используют PACKAGECONFIG_CONFARGS для передачи опций PACKAGECONFIG командам configure и cmake, соответственно. Если вы применяете PACKAGECONFIG,
но
не класс, обслуживающий задачу
do_configure, нужно соответствующим образом использовать PACKAGECONFIG_CONFARGS.

PACKAGEGROUP_DISABLE_COMPLEMENTARY

Для заданий, наследующих класс packagegroup, установка PACKAGEGROUP_DISABLE_COMPLEMENTARY = «1» указывает, что обычные дополнительные пакеты (-dev, -dbg
и
т. п.
) не следует автоматически создавать в задании packagegroup, как это принято по умолчанию.

PACKAGES

Список пакетов, создаваемых заданием. По умолчанию это ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}.

В процессе создания пакетов задача do_package просматривает переменную PACKAGES и использует переменную FILES для каждого пакета при назначении файлов пакета. Если файл соответствует переменной FILES для нескольких пакетов из PACKAGES, он будет назначаться первому (левому) пакеты в списке.

Пустые пакеты из списка (т. е. не соответствующие ни одному из шаблонов FILES_pkg,
установленных
задачей
do_install) не создаются, если это явно не задано переменной ALLOW_EMPTY.

PACKAGES_DYNAMIC

Заявление соответствия задания зависимостям при работе, найденным в других заданиях. Переменная на деле не задает зависимости, а лишь говорит о том, что их следует выполнять. Например, если жесткая зависимость при работе (RDEPENDS) для другого пакета выполнена во время сборки через переменную PACKAGES_DYNAMIC, но пакет с именем модуля на деле не создается, сборка другого пакета будет нарушена. Таким образом, при попытке включить этот пакет в образ возникнет отказ зависимостей при подготовке пакета во время задачи do_rootfs.

Обычно, если возможна такая ситуация и пакета, который не был создан, был бы действительным без выполнения зависимости, следует использовать RRECOMMENDS (мягкая зависимость при работе) вместо RDEPENDS.

Пример использования PACKAGES_DYNAMIC для разделения пакетов приведен в разделе Handling Optional Module Packaging [2].

PACKAGESPLITFUNCS

Задает список функций, применяемых для дополнительного разделения файлов по отдельным пакетам. Задания могут добавлять значения в начало этой переменной или функции populate_packages
для
дополнительного разделения пакета. Во
всех случаях функции следует устанавливать
PACKAGES, FILES, RDEPENDS и другие переменные управления пакетами соответствующим образом для желаемого разделения пакетов.

PARALLEL_MAKE

Опции, передаваемые команде make в процессе выполнения задачи do_compile для управления параллельной компиляцией на сборочном хосте. Эта переменная обычно имеет форму -j x, где x задает максимальное число параллельных потоков. Для эффективной работы PARALLEL_MAKE команда должна запускаться с ${EXTRA_OEMAKE}. Проще всего это обеспечить путем использования функции oe_runmake.

По умолчанию система сборки OE автоматически устанавливает в этой переменной число ядер сборочного хоста. Если при сборке в процессе выполнения задачи do_compile возникают проблемы с зависимостями, можно сбросить переменную PARALLEL_MAKE для задания (см. раздел Debugging Parallel Make Races [2]).

Для систем с одним процессором не следует переопределять эту переменную для использования параллельной сборки. Однако в больших системах с несколькими процессорами можно установить для переменной PARALLEL_MAKE значение -j 20. Вопросы ускорения сборки рассмотрены в разделе Speeding Up a Build [2].

PARALLEL_MAKEINST

Опции, передаваемые команде make
install
в задаче do_install для использования параллельной установки. По умолчанию переменная принимает значение PARALLEL_MAKE. Для учета PARALLEL_MAKEINST команда make должна вызываться с ${EXTRA_OEMAKE},
для
чего можно просто использовать функцию
oe_runmake.

Если при сборке программы возникают проблемы с зависимостями в задаче do_install,
можно
просто сбросить переменную
PARALLEL_MAKEINST в задании (см. раздел Debugging Parallel Make Races [2]).

PATCHRESOLVE

Задает действие при отказе наложения изменений (patch) и может принимать значение noop или user. Принятое по умолчанию значение noop просто останавливает сборку, когда система OE не может применить исправление. Установка значения user заставляет систему сборку запустить консоль (shell) с переходом в нужный каталог для исправления конфликта вручную. Переменная задана в файле local.conf.

PATCHTOOL

Задает утилиту для применения исправлений (patch) во время выполнения задачи do_patch
(patch, quilt или git). По умолчанию используется утилита quilt для всех заданий, кроме quilt-native, для которого применяется patch, поскольку инструмент quilt недоступен во время исправления quilt-native. Для использования определенной утилиты можно указать PATCHTOOL = «patch», PATCHTOOL = «quilt» или PATCHTOOL = «git».

PE

Эпоха для задания. По умолчанию эта переменная не устанавливается. Переменная служит для обеспечения возможности обновления в тех случаях, когда смена номера версии выполняется несовместимым с прежними версиями способом. PE служит принятым по умолчанию значением переменной PKGE.

PF

Задает имя задания или пакета с включением номера версии и выпуска (glibc-2.13-r20+svnr15508/ или bash-4.2-r1/) в форме ${PN}-${EXTENDPE}${PV}-${PR}.

PIXBUF_PACKAGES

При наследовании класса pixbufcache переменная указывает пакеты, содержащие загрузчики pixbuf, используемые gdk-pixbuf. По умолчанию класс pixbufcache предполагает загрузчики из основного пакета задания (${PN}), а эта переменная позволяет указать другие пакеты.

PKG

Имя результирующего пакета, создаваемого системой сборки OE. При использовании переменной PKG должно применяться переопределение имен пакетов. Например, при переименовании выходного пакета классом debian следует указывать PKG_packagename.

PKG_CONFIG_PATH

Путь к файлам pkg-config для текущего контекста сборки. Программа pkg-config читает переменную из окружения.

PKGD

Указывает целевой каталог для упаковываемых файлов, которые будут разделены на отдельные пакеты. По умолчанию используется значение ${WORKDIR}/package, которое не следует менять.

PKGDATA_DIR

Указывает общий каталог данных глобального состояния, генерируемый в процессе упаковки. В этом процессе задача do_packagedata упаковывает данные для каждого задания и помещает их в эту общую временную область. По умолчанию эта переменная имеет значение ${STAGING_DIR_HOST}/pkgdata, менять которое не следует. Примеры использования этих данных приведены в разделах Automatically Added Runtime Dependencies [1] и Viewing Package Information with oe-pkgdata-util [2]. Информация о каталоге глобальных состояний приведена в описании переменной STAGING_DIR_HOST.

PKGDEST

Указывает родительский каталог для упаковываемых файлов после разделения их по отдельным пакетам. По умолчанию это каталог ${WORKDIR}/packages-split, в котором система сборки создает каталог для каждого пакета из PACKAGES. Менять имя этого каталога не следует.

PKGDESTWORK

Указывает временную рабочую область, где задача do_package сохраняет метаданные пакета. По умолчанию переменная PKGDESTWORK имеет значение ${WORKDIR}/pkgdata, которое не следует менять. Задача do_packagedata task копирует метаданные из PKGDESTWORK в PKGDATA_DIR для глобальной доступности.

PKGE

Эпоха, для которой пакет(ы) собирается заданием. По умолчанию значением PKGE является значение PE.

PKGR

Выпуск (revision) пакета, собираемого заданием. По умолчанию значением PKGR является значение PR.

PKGV

Номер версии пакета (пакетов), собираемого заданием. По умолчанию PKGV принимает значение переменной PV.

PN

Назначение этой переменной может меняться в зависимости от контекста — имя задания или получаемого в результате пакета.

PN указывает имя задания в контексте файла, используемого системой сборки OE в качестве входного для создания пакета. Имя обычно извлекается из имени файла задания. Например для задания с именем expat_2.0.1.bb
по умолчанию значением PN
будет expat.

Переменная указывает имя пакета в контексте файла, созданного или произведенного системой сборки OE.

Когда это применимо, переменная PN включает специальный суффикс или префикс. Например, при использовании bash для сборки пакетов для естественной машины PN будет bash-native,
а при использовании bash
для сборки пакетов для цели и для Multilib значением PN будет bash и lib64-bash, соответственно.

PNBLACKLIST

Перечисляет задания, которые не нужно собирать в системе OE. Переменная работает вместе с классом blacklist,
наследуемым
глобально
. Переменная PNBLACKLIST задается в файле local.conf. Например, для предотвращения сборки myrecipe
служит
PNBLACKLIST[myrecipe] = «Not supported by our organization.».

POPULATE_SDK_POST_HOST_COMMAND

Задает список функций, однократно вызываемых системой сборки OE при создании хостовой части SDK. Функции разделяются точкой с запятой, например, POPULATE_SDK_POST_HOST_COMMAND += «function; … «.

Если нужно передать путь к SDK при вызове функции, можно применять переменную ${SDK_DIR}, указывающую каталог, который система сборки OE будет использовать для вывода SDK.

POPULATE_SDK_POST_TARGET_COMMAND

Задает список функций, однократно вызываемых системой сборки OE при создании целевой части SDK. Функции разделяются точкой с запятой, например, POPULATE_SDK_POST_TARGET_COMMAND += «function; … «.

Если нужно передать путь к SDK при вызове функции, можно применять переменную ${SDK_DIR}, указывающую каталог, который система сборки OE будет использовать для вывода SDK.

PR

Номер пересмотра (изменения) задания. По умолчанию используется значение r0, а последующие варианты имеют номера r1, r2 и т. д. При увеличении переменной PV значение PR обычно сбрасывается в r0.

Системе сборки OE не нужно знать PR для принятия решения о пересборке пакета, для этого служат входные контрольные суммы задания [1] вместе с механизмами stamp (5.2.20. build/tmp/stamps/) и кэширования общих состояний [1].

Переменная PR приобретает важное значение, когда менеджер пакетов динамически устанавливает программы в уже созданном образе. В таких случаях PR, которая по умолчанию имеет значение переменной PKGR, помогает менеджеру определить, какой пакет является более свежим, если имеется несколько пакетов с совпадающими номерами PV (PKGV). Наличие множества пакетов с одним PV обычно говорит о том, что пакеты имеют одну исходную версию, но различаются номерами вариантов (PR), которые могут включать изменения.

Значение
PR не требуется увеличивать при изменениях, не влияющих на содержимое или метаданные пакета.

Поскольку ручное управление PR громоздко и подвержено ошибкам, имеется автоматизированное решение (Working With a PR Service [2]).

PREFERRED_PROVIDER

Если один элемент обеспечивается несколькими заданиями, эта переменная позволяет указать предпочтительное задание, что обеспечивает выбор элемента (предпочтительного поставщика). В переменной всегда следует использовать суффикс в форме имени предоставляемого элемента и указывать предпочтительное задание (PN), например, PREFERRED_PROVIDER_virtual/kernel ?= «linux-yocto». Здесь элемент virtual/kernel предоставляется несколькими заданиями и переменная PREFERRED_PROVIDER указывает имя (PN), задания, предпочитаемого для обеспечения virtual/kernel.

Ниже приведены еще два примера.

     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
     PREFERRED_PROVIDER_virtual/libgl ?= "mesa"

Дополнительные сведения о работе с виртуальными провайдерами приведены в разделе Using Virtual Providers [2].

При использовании элемента virtual/* с переменной PREFERRED_PROVIDER
задание, которые включают этот элемент в PROVIDES,
но
не были выбраны переменной
PREFERRED_PROVIDER,
не
будут собираться
.

PREFERRED_VERSION

При наличии нескольких версий заданий эта переменная указывает предпочтительную версию. Переменная всегда указывается с PN
задания
и указанием предпочтительной версии
PV. Переменная поддерживает ограниченное использование символа %
в
качестве шаблона
. Этому шаблону может соответствовать любое число символов, что может быть полезно при указании версий с длинными номерами, которые могут изменяться. Ниже приведены два примера.

     PREFERRED_VERSION_python = "3.4.0"
     PREFERRED_VERSION_linux-yocto = "4.12%"

Символ % можно указывать лишь в конце строки.

Указанная версия сопоставляется со значением PV, которое не обязательно совпадает с версией в имени задания. Рассмотрим в качестве примера задания foo_1.2.bb и foo_git.bb, где foo_git.bb включает PV = «1.1+git${SRCPV}». В этом случае корректным способом выбора foo_git.bb будет указание PREFERRED_VERSION_foo = «1.1+git%». Если же указать PREFERRED_VERSION_foo = «git», это не будет работать.

Иногда переменная PREFERRED_VERSION может устанавливаться конфигурационными файлами так, что ее сложно изменить. В таких случаях можно использовать переменную OVERRIDES для машинозависимого переопределения, например, PREFERRED_VERSION_linux-yocto_qemux86 = «4.12%»

Хотя это и не рекомендуется, в крайнем случае можно воспользоваться переопределением forcevariable, которое является наиболее сильным из переопределений. Например, можно задать PREFERRED_VERSION_linux-yocto_forcevariable = «4.12%». Переопределение _forcevariable не получает особой обработки и действует лишь потому, что значение OVERRIDES по умолчанию включает forcevariable.

PREMIRRORS

Задает дополнительные пути для поиска исходных кодов системой сборки OE, которая сначала пытается найти коды в локальном каталоге загрузки. При отсутствии кодов в этом каталоге система просматривает репозитории, указанные переменной PREMIRRORS, затем «восходящий источник» и репозитории, указанные переменной MIRRORS.

Предположим, что используется дистрибутив (DISTRO) poky, для которого принятое по умолчанию значение PREMIRRORS указано в файле conf/distro/poky.conf репозитория meta-poky. Можно добавить нужные серверы в начало списка, указав их в файле local.conf в каталоге сборки, как показано ниже.

     PREMIRRORS_prepend = "\
     git://.*/.* http://www.yoctoproject.org/sources/ \n \
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"

Эти изменения заставят систему сборки перехватывать запросы Git, FTP, HTTP, HTTPS и направлять их на указанное зеркало http://. Можно использовать URL типа file:// для указания локальных или сетевых каталогов.

PRIORITY

Указывает уровень важности пакета. Переменная PRIORITY считается частью политики дистрибутива, поскольку важность любого задания зависит от целей дистрибутива. Поэтому PRIORITY обычно не указывается в заданиях. Переменная может принимать значения required (требуется), standard (стандартный уровень), extra (дополнение) и optional (не обязательно, используется по умолчанию).

PRIVATE_LIBS

Задает установленные в задании библиотеки, которые следует игнорировать распознавателю общих библиотек системы сборки OE. Переменная обычно применяется в тех случаях, когда создаваемые заданием программы имеют свои версии библиотек, обычно создаваемых другим заданием. В таких случаях следует исключить зависимость от пакета со своими библиотеками не связанных с ним пакетов, которые обычно зависят от стандартных версий библиотек. Библиотеки в этой переменной следует указывать именами файлов. Ниже приведен пример из задания Firefox в meta-browser.

     PRIVATE_LIBS = "libmozjs.so \
                     libxpcom.so \
                     libnspr4.so \
                     libxul.so \
                     libmozalloc.so \
                     libplc4.so \
                     libplds4.so"

Дополнительная информация представлена в разделе Automatically Added Runtime Dependencies [1].

PROVIDES

Список псевдонимов, под которыми может быть известно определенное задание. По умолчанию значение PN для задания неявно уже присутствует в списке PROVIDES. Если задание использует PROVIDES, дополнительные псевдонимы являются синонимами для задания и могут быть полезны для выполнения зависимостей других заданий в процессе сборки, указанных в DEPENDS.

В задании libav_0.8.11.bb указано PROVIDES += «libpostproc», в результате чего libav имеет псевдоним libpostproc.

Кроме дополнительных имен для заданий механизм PROVIDES применяется также для реализации виртуальных целей, которые являются именами, соответствующими некой определенной функциональности (например, ядро Linux). Задания, обеспечивающие соответствующую функциональность, указывают виртуальную цель в PROVIDES. Задания, зависящие от рассматриваемой функциональности, могут включать виртуальную цель в DEPENDS, оставляя выбор поставщика открытым. Обычно виртуальные цели имеют имена вида virtual/function (например, virtual/kernel). Символ дробной черты (/) просто является частью имени и не имеет синтаксического значения. Переменная PREFERRED_PROVIDER служит для выбора конкретного задания, обеспечивающего виртуальную цель.

Имеется соответствующий механизм для виртуальных зависимостей (пакетов) во время выполнения. Однако этот механизм не зависит от какой-либо особой функциональности обычного назначения переменных. Например, VIRTUAL-RUNTIME_dev_manager указывает пакет, который управляет каталогом /dev. Установка «предпочтительного поставщика» для зависимостей во время исполнения так же проста, как назначение в конфигурационном файле VIRTUAL-RUNTIME_dev_manager = «udev».

PRSERV_HOST

Хост и порт сетевой службы PR.
В
файле
conf/local.conf.sample.extended каталога исходных кодов переменная задана в виде PRSERV_HOST = «localhost:0». Эту переменную нужно устанавливать при необходимости автоматического запуска локальной службы PR. Можно указать также значения для удаленной службы PR.

PTEST_ENABLED

Управляет включением функциональности тестирования пакетов (ptest) при сборке задания. Переменную не следует задавать напрямую, поскольку управление тестированием пакетов при сборке задается добавлением (или удалением) ptest в переменную DISTRO_FEATURES.

PV

Номер версии задания. Обычно номер версии извлекается из имени файла задания. Например, для задания expat_2.0.1.bb
переменная
PV по умолчанию будет иметь значение 2.0.1. Значение PV обычно не переопределяется в задании, если сборка не является нестабильной (рабочей) из репозитория исходных кодов), например, Git или Subversion.

Значение
PV используется по умолчанию для переменной PKGV.

PYTHON_ABI

При использовании в заданиях, наследующих класс distutils3, setuptools3, distutils
или
setuptools, указывает интерфейс ABI, используемый для Python (по умолчанию «m»). Переменную не нужно задавать, это делает OE.

Система сборки OE применяет ABI для задания имен каталогов, используемых при установке заголовков и библиотек Python в (например .../python3.3m/...).

Задания, наследующие класс distutils, при кросс-сборке также используют эту переменную для поиска заголовков и библиотек версии Python, для которой предназначено расширение.

PYTHON_PN

При использовании в заданиях, наследующих класс distutils3, setuptools3, distutils
или
setuptools, указывает старшую версию Python для сборки. Для Python 2.x переменная PYTHON_PN будет иметь значение python2, для Python 3.x — python3. Если переменная не установлена, система сборки OE сделает это автоматически.

Переменная позволяет заданиям использовать общую инфраструктуру, в форме DEPENDS += «${PYTHON_PN}-native», где PYTHON_PN
указывает
версию зависимости
.

R

RANLIB

Сокращенная команда и аргументы для запуска ranlib.

RCONFLICTS

Список пакетов, конфликтующих с другими пакетами. Установка пакетов будет блокироваться до устранения конфликтов. Как и другие переменные управления пакетами, RCONFLICTS нужно всегда указывать с переопределением имени пакета, например, RCONFLICTS_${PN} = «another_conflicting_package_name«.

BitBake поддерживает указание зависимостей с учетом версии. Синтаксис зависит от формата пакетов, но BitBake скрывает эти различия. Базовый синтаксис указания версии имеет вид RCONFLICTS_${PN} = «package (operator version)». Оператором может служить =, <, >, <= или >=.

Например, для указания зависимости от версии 1.2 или выше для пакета foo
можно
задать
RCONFLICTS_${PN} = «foo (>= 1.2)».

RDEPENDS

Список зависимостей пакета во время выполнения. Эти зависимости указывают пакеты, которые должны быть установлены для корректной работы данного пакета. Например, приведенная ниже строка указывает зависимость работы пакета foo от наличия установленных пакетов bar и baz.

     RDEPENDS_foo = "bar baz"

Наиболее распространенные зависимости пакетов во время исполнения обнаруживаются и добавляются автоматически, поэтому в большинстве задания переменная RDEPENDS
не
нужна
. Зависимости более подробно рассмотрены в разделе Automatically Added Runtime Dependencies [1].

Практическое влияние приведенного выше примера RDEPENDS состоит в том, что пакеты bar и baz объявляются зависимостями в пакете foo,
когда
он будет записан одной из задач
do_package_write_*. Способ выполнения этого зависит от используемого формата пакета, который определяется переменной PACKAGE_CLASSES. Когда соответствующий менеджер устанавливает пакет, он знает, что нужно установить пакеты, от которых тот зависит.

Чтобы обеспечить сборку пакетов bar и baz,
предыдущий пример RDEPENDS также вызывает добавление зависимости задач. Это зависимость задачи do_build для задания (не путайте с do_compile) от задач do_package_write_* заданий сборки bar и baz.

Имена в переменной RDEPENDS должны указывать другие пакеты — это не могут быть имена заданий. Хотя имена пакетов и заданий могут совпадать, важно отметить, что в переменной RDEPENDS указываются именно пакеты. Подробный список пакетов, создаваемых заданием, можно узнать из переменной PACKAGES.

Поскольку переменная RDEPENDS применяется к собираемым пакетам, ее следует использовать с именем пакета в конце (помните, что одно задание может собирать несколько пакетов). Предположим, например, сборку пакета для разработки, который зависит от perl. В этом случае используется оператор RDEPENDS вида

     RDEPENDS_${PN}-dev += "perl"

В этом примере пакет для разработки зависит от пакета perl. Таким образом, RDEPENDS включает ${PN}-dev
как
часть переменной
. RDEPENDS_${PN}-dev включает ${PN} по умолчанию, что устанавливается в конфигурационном файле BitBake (meta/conf/bitbake.conf). Соблюдайте осторожность, чтобы случайно не удалить ${PN} при изменении RDEPENDS_${PN}-dev. Следует также применять оператор +=, а не просто =.

Имена пакетов в переменной RDEPENDS должны указывать в том виде, как они представлены в PACKAGES. Переменная PKG разрещает использовать для финального пакета другое имя (например, класс debian использует ее для переименования пакетов), но это окончательное имя пакета не может использоваться в RDEPENDS, поскольку эта переменная предполагает независимость от применяемого формата пакетов.

Программа BitBake, используемая системой сборки OE, поддерживает в зависимостях указание версий. Хотя синтаксис версии зависит от формата упаковки, BitBake скрывает эту зависимость. Базовый синтаксис указания версии имеет
вид
RDEPENDS_${PN} = «package (operator version)».

Оператором может служить =, <, >, <= или >=, версия указывается номером. Можно использовать переменную EXTENDPKGV для полного указания версии пакета. Например, для указания зависимости от версии 1.2 или выше для пакета foo
можно
задать
RDEPENDS_${PN} = «foo (>= 1.2)».

Информация о зависимостях во время сборки задается переменной DEPENDS.
Дополнительные
сведения о задачах и зависимостях
приведены в разделах
Tasks и Dependencies [4].

REQUIRED_DISTRO_FEATURES

При наследовании класса distro_features_check эта переменная указывает свойства дистрибутива, которые должны присутствовать в текущей конфигурации сборки задания. Если эта переменная указывает свойства, не указанные в DISTRO_FEATURES для текущей конфигурации, это будет вызывать ошибку и прекращение сборки.

RM_WORK_EXCLUDE

При включенном классе rm_work переменная задает список заданий, рабочие каталоги которых не следует удалять (см. параграф 6.114. rm_work.bbclass).

ROOT_HOME

Задает корневой каталог root. По умолчанию каталог указывается в конфигурационном файле BitBake как ROOT_HOME ??= «/home/root». Заданное по умолчанию значение вероятно будет использоваться, поскольку некоторые встраиваемые системы предпочитают создавать корневую файловую систему, доступную лишь для чтения, и хранить перезаписываемые данные в отдельном месте. Переменную можно переопределить на любом уровне или в файле local.conf. Поскольку для заданного по умолчанию значения используется «мягкое» назначение (??»), для переопределения можно указать любой из приведенных ниже вариантов.

     ROOT_HOME = "/root"
     ROOT_HOME ?= "/root"

ROOTFS

Указывает образ файловой системы для включения в корневую файловую системы. Переменная является необязательной и применяется с классом image-live.

ROOTFS_POSTINSTALL_COMMAND

Задает список функций для вызова после установки пакетов системой сборки OE. Функции разделяются символом точки с запятой (;), например ROOTFS_POSTINSTALL_COMMAND += «function; … «.

Если требуется передать путь к корневой файловой системе команде с функцией, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

ROOTFS_POSTPROCESS_COMMAND

Задает список функций для однократного вызова системой сборки OE при создании корневой файловой системы. Функции разделяются символом точки с запятой (;), например, ROOTFS_POSTPROCESS_COMMAND += «function; … «. Если нужно передать путь к корневой файловой системе команде с функцией, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

ROOTFS_POSTUNINSTALL_COMMAND

Задает список функций, вызываемых после удаления системой сборки OE ненужных приложений. Когда менеджер пакетов при работе системы (runtime) отключен в образе, удаляется несколько пакетов, включая base-passwd, shadow
и
update-alternatives. Функции разделяются символом точки с запятой (;), например, ROOTFS_POSTUNINSTALL_COMMAND += «function; … «.

Если требуется передать путь к корневой файловой системе команде с функцией, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

ROOTFS_PREPROCESS_COMMAND

Задает список функций, вызываемых перед созданием корневой файловой системы системой сборки OE. Функции разделяются точкой с запятой, например, ROOTFS_PREPROCESS_COMMAND += «function; … «.

Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

RPROVIDES

Список псевдонимов имен пакетов, которые полезны для выполнения зависимостей во время работы как при сборке, так и на целевой платформе (как указано переменной RDEPENDS). Реальное имя пакета неявно уже присутствует в списке RPROVIDES.

Как и другие переменных управления пакетами, RPROVIDES всегда нужно использовать в сочетании с переопределением имени пакета, например, RPROVIDES_${PN} = «widget-abi-2».

RRECOMMENDS

Список пакетов для расширения применимости собираемого пакета. Собираемый пакет не зависит от этого списка, а применяет их для расширения сферы использования. Для задания зависимостей при работе пакетов служит переменная RDEPENDS.

Менеджер пакетов будет автоматически устанавливать пакеты из списка RRECOMMENDS при установке собираемого пакета. Однако можно предотвратить установку пакетов из списка с помощью переменных BAD_RECOMMENDATIONS, NO_RECOMMENDATIONS и PACKAGE_EXCLUDE.

Пакеты, указанные в RRECOMMENDS не обязательно создавать в действительности, однако должно существовать задание для каждого из этих пакетов в переменной PACKAGES, PACKAGES_DYNAMIC или RPROVIDES, иначе возникнет ошибка. Если задание имеется, но пакет не создается, сборка продолжится без ошибки.

Поскольку переменная RRECOMMENDS применяется к собираемым пакетам, нужно прикреплять переопределение к переменной для указания конкретного пакета, применимость которого будет расширена. Предположим, например, сборку пакета разработки, которая расширяется для поддержки беспроводных сетей. С этом случае указывается

RRECOMMENDS_${PN}-dev += "wireless_package_name"

В этом примере имя пакета (${PN}-dev) должно представляться как в пространстве имен PACKAGES до какого-либо переименования выходного пакета классами, такими как debian.bbclass.

BitBake, использующий систему сборки OE, поддерживает указание нужной версии. Хотя синтаксис такого указания зависит от формата упаковки, BitBake скрывает эти различия от вас. Ниже показан базовый синтаксис задания версии в переменной RRECOMMENDS.

RRECOMMENDS_${PN} = "package (operator version)"

В качестве оператора можно использовать =, <, >, <=, >=.

Например, приведенная ниже строка рекомендует версии не ниже 1.2 для пакета foo.

     RRECOMMENDS_${PN} = "foo (>= 1.2)"

RREPLACES

Список пакетов, заменяемых данным пакетом. Менеджер пакетов применяет эту переменную для определения пакетов, которые следует установить взамен других в процессе обновления. Для одновременного удаления других пакетов нужно добавить их имена в переменную RCONFLICTS. Как и другие переменные управления пакетами, RREPLACES требуется применять вместе с переопределением имени пакета, например, RREPLACES_${PN} = «other_package_being_replaced«.

BitBake поддерживает указание версий при замене. Синтаксис зависит от формата пакетов, однако BitBake маскирует эти различия. Общий синтаксис указания версий имеет вид RREPLACES_${PN} = «package (operator version)». В качестве оператора можно использовать =, <, >, <=, >=.

Например, строка RREPLACES_${PN} = «foo (>= 1.2)» рекомендует версии не ниже 1.2 для пакета foo.


RSUGGESTS

Список дополнительных пакетов, которые можно предложить при установке менеджеру пакетов во время инсталляции данного пакета. Функциональность поддерживают не все менеджеры пакетов. Как и другие переменные управления пакетами, RSUGGESTS требуется применять вместе с переопределением имени пакета.

RSUGGESTS_${PN} = "useful_package another_package"

S

S

Место в каталоге сборки, где размещаются неупакованные исходные коды задания. По умолчанию это каталог ${WORKDIR}/${BPN}-${PV}, где ${BPN}базовое имя задания, а ${PV}версия задания. Если из архива исходных кодов файлы извлечены в каталог, имя которого отличается от ${BPN}-${PV}, или исходный код получен из SCM (например, Git или Subversion), нужно установит переменную S в задании так, чтобы система сборки OE знала, где искать неупакованные исходные файлы.

Предположим, например, что каталог верхнего уровня в дереве исходных кодов называется poky, а принятым по умолчанию каталогом сборки служит poky/build. В этом случае рабочим каталогом системы сборки, используемым для хранения распакованного задания для db, будет poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19

Распакованные исходные файлы размещаются в каталоге db-5.1.19.

В следующем примере предполагается репозиторий Git. По умолчанию такие репозитории клонируются в ${WORKDIR}/git задачей do_fetch. Поскольку этот путь отличается от принятого по умолчанию значения S, нужно указать его как место размещения исходных кодов

     SRC_URI = "git://path/to/repo.git"
     S = "${WORKDIR}/git"

SANITY_REQUIRED_UTILITIES

Задает список консольных утилит, которые следует проверять во время начального тестирования работоспособности при запуске BitBake. Если какая-либо из утилит не установлена на сборочном хосте, BitBake сразу прерывает работу с возвратом ошибки.

SANITY_TESTED_DISTROS

Список идентификаторов дистрибутивов, для которых система сборки была протестирована. Идентификатор состоит из идентификатора дистрибутива, за которым следует номер выпуска, указанный инструментом lsb_release или прочитанный из файла /etc/lsb-release. Элементы списка задаются по одному в строках, завершающихся символом перевода строки (\n). Если строка SANITY_TESTED_DISTROS не пуста, а текущее значение NATIVELSBSTRING не присутствует в списке, система сборки выдает предупреждение, указывающее, что текущий дистрибутив не был проверен как хост сборки.

SDK_ARCH

Целевая архитектура для SDK. Обычно эта переменная не устанавливается напрямую и взамен применяется SDKMACHINE.

SDK_DEPLOY

Созданный и используемый классом populate_sdk_base каталог, в котором разворачивается SDK. Класс populate_sdk_base определяет переменную как SDK_DEPLOY = «${TMPDIR}/deploy/sdk».

SDK_DIR

Родительский каталог, используемый системой сборки OE при выводе SDK. Класс populate_sdk_base определяет переменную как SDK_DIR = «${WORKDIR}/sdk». Этот каталог является временным как часть WORKDIR,
окончательный
вывод помещается в
SDK_DEPLOY.

SDK_EXT_TYPE

Управляет копированием элементов общего состояния в eSDK. При заданном по умолчанию значении full копируются все нужные элементы общего состояния, значение minimal оставляет элементы за пределами SDK.

При установке значения minimal нужно убедиться в установке переменной SSTATE_MIRRORS в конфигурации SDK для выборки требуемых элементов.

SDK_HOST_MANIFEST

Файл манифеста для хостовой части SDK, содержащий все установленные пакеты, которые делают хост частью SDK. Пакеты указываются по одному в строке в форме packagename packagearch version. Класс populate_sdk_base определяет файл манифеста как SDK_HOST_MANIFEST = «${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest». Расположение файла выводится из переменных SDK_DEPLOY и TOOLCHAIN_OUTPUTNAME.

SDK_INCLUDE_PKGDATA

Значение 1 задает включение packagedata для всех заданий цели world в расширяемом SDK. Это позволяет команде devtool search находить эти задания, а также позволяет команде devtool add более эффективно отображать зависимости.

Включение SDK_INCLUDE_PKGDATA существенно увеличивает время сборки, потому что требуется собирать все задания из world. Размер eSDK также возрастает.

SDK_INCLUDE_TOOLCHAIN

Значение 1 задает включение инструментария в расширяемый SDK. Это особенно полезно при установке в SDK_EXT_TYPE значения minimal для снижения размера SDK, когда есть также необходимость в инструментарии. Например, может быть нужно включение инструментария из IDE или другого набора без дополнительных действий по установке инструментов. По умолчанию переменная имеет значение 0, если для SDK_EXT_TYPE выбрано значение minimal, и 1 для SDK_EXT_TYPE = «full».

SDK_INHERIT_BLACKLIST

Список классов для глобального удаления из значения INHERIT в конфигурации расширяемых SDK. Принятое по умолчанию значение задает класс populate-sdk-ext в форме SDK_INHERIT_BLACKLIST ?= «buildhistory icecc». Некоторые классы обычно не применимы в контексте расширяемых SDK и из можно отключить этой переменной.

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_LOCAL_CONF_BLACKLIST

Список переменных, которые не разрешено передавать из системы сборки OE в конфигурацию расширяемых SDK. Обычно эти переменные связаны с машиной, на которой работает система сборки, и поэтому могут создавать проблемы в расширяемых SDK. По умолчанию переменная устанавливается классом populate-sdk-ext в форме

     CONF_VERSION
     BB_NUMBER_THREADS
     BB_NUMBER_PARSE_THREADS
     PARALLEL_MAKE
     PRSERV_HOST
     SSTATE_MIRRORS
     DL_DIR
     SSTATE_DIR
     TMPDIR
     BB_SERVER_TIMEOUT

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_LOCAL_CONF_WHITELIST

Список переменных, передаваемых из системы сборки OE в конфигурацию расширяемых SDK. По умолчанию пустой список устанавливается классом populate-sdk-ext. Этот список переопределяет переменные, заданные с помощью SDK_LOCAL_CONF_BLACKLIST,
а
также другие переменные, автоматически
включаемые в «черный список» символом
/ в начале значения, который обычно указывает путь и поэтому не пригоден для системы, где будет устанавливаться SDK.

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_NAME

Базовое имя для выходных файлов SDK, которое выводится из переменных DISTRO, TCLIBC, SDK_ARCH, IMAGE_BASENAME
и TUNE_PKGARCH,
как
показано ниже.

     SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"

SDK_OS

Задает операционную систему, для которой собирается SDK (по умолчанию значение BUILD_OS).

SDK_OUTPUT

Место, используемое системой сборки OE для вывода SDK. Класс populate_sdk_base определяет переменную, как показано ниже.

     SDK_DIR = "${WORKDIR}/sdk"
     SDK_OUTPUT = "${SDK_DIR}/image"
     SDK_DEPLOY = "${DEPLOY_DIR}/sdk"

Каталог SDK_OUTPUT служит временным каталогом, являясь частью WORKDIR через SDK_DIR. Финальный вывод записывается в SDK_DEPLOY.

SDK_PACKAGE_ARCHS

Задает список вариантов архитектуры, совместимых с машиной SDK. Переменная устанавливается автоматически и обычно ее не нужно редактировать. Элементы разделяются пробелами и указаны по приоритету. По умолчанию установлено значение «all any noarch ${SDK_ARCH}-${SDKPKGSUFFIX}».

SDK_POSTPROCESS_COMMAND

Задает список функций, однократно вызываемых системой сборки OE при создании SDK. Функции разделяются точкой с запятой, например, SDK_POSTPROCESS_COMMAND += «function; … «.

Если нужно передать путь к SDK при вызове функции, можно применять переменную ${SDK_DIR}, указывающую каталог, который система сборки OE будет использовать для вывода SDK.

SDK_PREFIX

Префикс двоичных файлов инструментария для заданий nativesdk
(по
умолчанию ${SDK_SYS}-)
. Система сборки OE использует значение SDK_PREFIX для установки TARGET_PREFIX при сборке заданий nativesdk.

SDK_RECRDEP_TASKS

Список задач общего состояния, добавленных в расширяемый SDK. По умолчанию добавляются задачи do_populate_lic, do_package_qa, do_populate_sysroot и do_deploy, несмотря на принятое по умолчанию значение «». Для добавления других задач нужно указать их в переменной (например, при создании задач, которые нужно включить в SDK_TARGETS).

SDK_SYS

Указывает систему, для которой будет собираться SDK, включая архитектуру и ОС. Система сборки OE автоматически устанавливает эту переменную на основе SDK_ARCH, SDK_VENDOR
и
SDK_OS.

SDK_TARGET_MANIFEST

Файл манифеста для целевой части SDK, где указаны все установленные пакеты, составляющие целевую часть SDK. Пакеты указываются по одному в строке в форме packagename packagearch version.
Класс
populate_sdk_base задает файл как SDK_TARGET_MANIFEST = «${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest». Местоположение выводится из переменных SDK_DEPLOY и TOOLCHAIN_OUTPUTNAME.

SDK_TARGETS

Список целей для установки из общего состояния как части установки стандартного или расширяемого SDK. По умолчанию установлено значение «${PN}» (образ, из которого собран SDK). Переменная является внутренней и обычно не меняется.

SDK_TITLE

Заголовок, выводимый при запуске установщика SDK. По умолчанию этот заголовок основан на значении переменной DISTRO_NAME или DISTRO и задается классом populate_sdk_base в форме SDK_TITLE ??= «${@d.getVar(‘DISTRO_NAME’) or d.getVar(‘DISTRO’)} SDK». Для дистрибутива poky переменная SDK_TITLE имеет значение Poky (Yocto Project Reference Distro). Способы смены принятого по умолчанию значения описаны в разделе Changing the Extensible SDK Installer Title [7].

SDK_UPDATE_URL

Необязательный идентификатор URL сервера обновления для расширяемого SDK. Если переменная установлена, ее значение используется в качестве принятого по умолчанию сервера обновления командой devtool
sdk-update
.

SDK_VENDOR

Задает имя производителя SDK.

SDK_VERSION

Задает версию SDK. Конфигурационные файлы дистрибутивов (например, /meta-poky/conf/distro/poky.conf) задают переменную в виде SDK_VERSION = «${@d.getVar(‘DISTRO_VERSION’).replace(‘snapshot-${DATE}’,’snapshot’)}».

SDKEXTPATH

Принятый по умолчанию каталог для установки расширяемого SDK. По умолчанию эта переменная базируется на переменной DISTRO и задается классом populate_sdk_base как SDKEXTPATH ??= «~/${@d.getVar(‘DISTRO’)}_sdk». Для дистрибутива poky переменная имеет значение poky_sdk.

Смена принятого по умолчанию каталога описана в разделе Changing the Default SDK Installation Directory [7].

SDKIMAGE_FEATURES

Эквивалент IMAGE_FEATURES для SDK, созданных из образа по команде bitbake -c populate_sdk imagename.

SDKMACHINE

Машина, для которой собирается SDK. Иными словами, SDK собирается так, чтобы работать на целевой платформе, заданной значением SDKMACHINE, указывающим
нужный файл .conf из
conf/machine-sdk/.

Можно использовать i686 и x86_64 в качестве значения этой переменной. Используемое по умолчанию значение i686 задается в файле local.conf сборочного каталоге.

     SDKMACHINE ?= "i686"

Не следует устанавливать переменную SDKMACHINE в конфигурационном файле дистрибутива, поскольку такая установка не будет работать.

SDKPATH

Указывает путь, предлагаемый пользователю для инсталляции SDK, созданного системой сборки OE. Путь представляется как принятое по умолчанию место для установки SDK при работе сценария инсталляции SDK. Предлагаемый путь можно переопределить при работе сценария.

SDKTARGETSYSROOT

Полный путь к каталогу sysroot, используемый для кросс-компиляции в SDK, как при инсталляции в принятый по умолчанию SDKPATH.

SECTION

Секция, в которой следует разделить пакеты по категориям. Переменную могут использовать менеджеры пакетов.

SELECTED_OPTIMIZATION

Задает флаги оптимизации, передаваемые компилятору C при сборке для цели. Флаги передаются в принятом по умолчанию значении TARGET_CFLAGS. Переменная SELECTED_OPTIMIZATION принимает значение FULL_OPTIMIZATION, если на задано DEBUG_BUILD = «1». В последнем случае используется значение DEBUG_OPTIMIZATION.

SERIAL_CONSOLE

Указывает последовательную консоль (TTY) для использования getty. В значении следует указать скорость, затем устройство TTY через пробел. Указать можно лишь один порт, например, SERIAL_CONSOLE = «115200 ttyS0». Переменная SERIAL_CONSOLE отменена и взамен следует использовать SERIAL_CONSOLES.

SERIAL_CONSOLES

Указывает последовательные консоли (TTY) для использования getty. В значении следует указать скорость, затем устройство TTY через точку с запятой. Порты разделяются пробелами, например, SERIAL_CONSOLES = «115200;ttyS0 115200;ttyS1».

SERIAL_CONSOLES_CHECK

Задает последовательные консоли, которые должны быть указаны в SERIAL_CONSOLES, для сравнения с /proc/console перед включением и использованием getty. Переменная поддерживает псевдонимы в формате <device>:<alias>. Если устройство указано как sclp_line0 в /dev/ и ttyS0 задана в /proc/console, нужно указать SERIAL_CONSOLES_CHECK = «slcp_line0:ttyS0». Переменная поддерживается только с SysVinit (не systemd).

SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS

Список зависимостей задания, которые не должны учитываться при определении подписей задач из одного задания, когда они зависят от задач из другого задания. Например, SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += «intone->mplayer2», где intone зависит от mplayer2. Можно применять специальный маркер * слава от зависимости, которому будут соответствовать все задания, кроме указанного справа, например, SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += «*->quilt-native». Здесь все задания, кроме quilt-native игнорируют подписи задач из quilt-native при определении своих подписей. Использование этой переменной является одним из способов удаления зависимостей, влияющих на подписи задач и требующих повторной сборки при изменении заданий. При добавлении в этот список неподходящего задания при работе программ могут возникать ошибки, если интерфейс задания будет изменен после сборки другого задания.

SIGGEN_EXCLUDERECIPES_ABISAFE

Список заданий, которые стабильны и никогда не меняются. ABI для заданий из этого списка представляется выводом задач, работающих для сборки задания. Использование этой переменной является одним из способов удаления зависимостей, влияющих на подписи задач и требующих повторной сборки при изменении заданий. При добавлении в этот список неподходящего задания при работе программ могут возникать ошибки, если интерфейс задания будет изменен после сборки другого задания.

SITEINFO_BITS

Задает разрядность CPU в целевой системе (32 или 64).

SITEINFO_ENDIANNESS

Задает порядок байтов на целевой системе и может принимать значение le (little-endian) или be (big-endian).

SKIP_FILEDEPS

Включает удаление всех файлов из раздела Provides пакета RPM. Удаление этих файлов требуется для пакетов, включающих заранее собранные исполняемые файлы и библиотеки, такие как libstdc++ и glibc. Чтобы включить удаление, нужно в файле сборочного каталога conf/local.conf задать SKIP_FILEDEPS = «1».

SOC_FAMILY

Группирует машины на основе семейства SOC2 и обычно задается в общем файле .inc,
включаемом
в конфигурационные файлы всех машин
. Нужно включить файл conf/machine/include/soc-family.inc,
чтобы
эта переменная появилась в
MACHINEOVERRIDES.

SOLIBS

Задает суффикс для общих библиотек на целевой платформе. Принятый по умолчанию суффикс .so для систем Linux определен в файле meta/conf/bitbake.conf. Эта переменная используется в принятых по умолчанию значениях FILES_${PN}.

SOLIBSDEV

Задает суффикс для символьной ссылки на общую библиотеку разработки для целевой платформы. Принятый по умолчанию суффикс .so для систем Linux определен в файле meta/conf/bitbake.conf. Эта переменная используется в принятых по умолчанию значениях FILES_${PN}-dev.

SOURCE_MIRROR_FETCH

При выборке файлов для создания зеркала исходных кодов установка SOURCE_MIRROR_FETCH = «1» в файле local.conf обеспечивает выбор исходных кодов всех заданий независимо от совместимости с конфигурацией. Задание считается не совместимым с настроенной в данный момент машиной, когда любая (или обе) из переменных COMPATIBLE_MACHINE и COMPATIBLE_HOST
задают
совместимость с машиной, отличной от
выбранной и хоста
. Не следует задавать переменную SOURCE_MIRROR_FETCH без наличия зеркала исходных кодов (т. е. при обычной сборке).

SOURCE_MIRROR_URL

Задает свою переменную PREMIRRORS,
в
соответствии с которой начинается
выборка исходных кодов до обращения к
SRC_URI. Для использования этой переменной требуется глобальное наследование класса own-mirrors и предоставление URL для зеркал. Ниже показан базовый синтаксис.

INHERIT += "own-mirrors"
     SOURCE_MIRROR_URL = "http://example.com/my_source_mirror"

В переменной SOURCE_MIRROR_URL
можно
задать лишь один идентификатор URL
.

SPDXLICENSEMAP

Отображает общепринятые имена лицензий на идентификаторы SPDX из meta/files/common-licenses/. Подробное описание отображений приведено в файле meta/conf/licenses.conf. См. также описание переменной LICENSE.

SPECIAL_PKGSUFFIX

Список префиксов для PN,
используемых
системой сборки
OE при создании вариантов заданий или пакетов. Список задает префиксы, вырезаемые при некоторых обстоятельствах (например, создание переменной BPN).

SPL_BINARY

Тип файла для загрузчика SPL3, используемого некоторыми устройствами (например, плата BeagleBone) для загрузки. В таких случаях можно объявить тип двоичного файла SPL в файле u-boot.inc, используемом в задании U-Boot. Тип файла SPL по началу имеет значение null, заданное в файле u-boot.inc,
как
показано ниже.

     # Some versions of u-boot build an SPL (Second Program Loader) image that
     # should be packaged along with the u-boot binary as well as placed in the
     # deploy directory.  For those versions they can set the following variables
     # to allow packaging the SPL.
     SPL_BINARY ?= ""
     SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
     SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
     SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"

Переменная SPL_BINARY помогает формировать переменные SPL_*,
используемые
системой сборки
OE.

Пример конфигурации BeagleBone приведен в разделе Creating a new BSP Layer Using the bitbake-layers Script [6].

SRC_URI

Список исходных файлов (локальных или удаленных). Эта переменная говорит системе сборки OE, что и как нужно извлекать для сборки. Например, если заданию или файлу дополнения нужно лишь загрузить архив из Internet, это задание или файл дополнения использует одну запись SRC_URI. Если же нужно, например, извлечь архив, применить два исправления и включить пользовательский файл, задание или файл дополнения будут включать 4 экземпляра этой переменной.

Ниже приведен список поддерживаемых протоколов URI. Эти протоколы сильно зависят от конкретных субмодулей BitBake Fetcher. В зависимости от применяемого сборщика используются разные параметры URL. Подробное описание работы со сборщиками приведено в разделе Fetchers [4].

  • file:// извлекает файлы, которые обычно поставляются с метаданными с локальной машины (например, patch-файлы). Путь задается относительно значения переменной FILESPATH. Таким образом, система сборки просматривает по порядку перечисленные ниже каталоги, которые предполагаются подкаталогами места размещения файла задания (.bb) или дополнения (.bbappend):
    • ${BPN} базовое имя задания без специальных суффиксов и номера версии;
    • ${BP} ${BPN}-${PV}базовое имя задания и версия, но без специального суффикса (имя пакета);
    • files — файлы в каталоге files,
      который
      размещен вместе с файлом задания или
      дополнения
      .

    Если вы хотите, чтобы система сборки забрала файлы, указанные оператором SRC_URI в вашем файле дополнения, нужно расширить переменную FILESPATH,
    используя
    значение
    FILESEXTRAPATHS из вашего файла дополнения.

  • bzr:// извлекает файлы из репозитория управления версиями Bazaar.
  • git:// извлекает файлы из репозитория управления версиями Git.
  • osc:// извлекает файлы из репозитория управления версиями OSC (OpenSUSE Build service).
  • repo:// извлекает файлы из репозитория repo (Git).
  • ccrc:// извлекает файлы из репозитория ClearCase.
  • http:// извлекает файлы из Internet по протоколу http.
  • https:// извлекает файлы из Internet по протоколу https.
  • ftp:// извлекает файлы из Internet по протоколу ftp.
  • cvs:// извлекает файлы из репозитория управления версиями CVS.
  • hg:// извлекает файлы из репозитория управления версиями (hg).
  • p4:// извлекает файлы из репозитория управления версиями Perforce (p4).
  • ssh:// извлекает файлы из защищенной среды (secure shell).
  • svn:// извлекает файлы из репозитория управления версиями Subversion (svn).

Имеются стандартные и специфические для заданий SRC_URI. Ниже перечислены стандартные.

  • apply нужно ли применять исправления (по умолчанию apply — нужно).
  • striplevel уровень разрешения (striplevel) при наложении исправлений (по умолчанию 1).
  • patchdir каталог, в котором следует применять исправления (по умолчанию ${S}).

Ниже приведены варианты для заданий по сборке кода из системы контроля версий.

  • mindate применять исправление лишь в случаях, когда SRCDATE не меньше mindate.
  • maxdate применять исправление лишь в случаях, когда SRCDATE не больше maxdate.
  • minrev применять исправление лишь в случаях, когда SRCREV не меньше minrev.
  • maxrev применять исправление лишь в случаях, когда SRCREV не больше maxrev.
  • rev применять исправление лишь в случаях, когда SRCREV = rev.
  • notrev применять исправление лишь в случаях, когда SRCREV отличается от rev.

Имеется также ряд дополнительных опций, перечисленных ниже.

  • unpack управляет распаковкой файла, если он является архивом (по умолчанию архивы распаковываются).
  • destsuffix помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании сборщика Git.
  • subdir помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании локального сборщика (file://).
  • localdir помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании сборщика CVS.
  • subpath ограничивать извлечение конкретным путем в дереве при использовании сборщика Git.
  • name задает имя, применяемое для привязки к контрольным суммам SRC_URI при указании в SRC_URI нескольких файлов.
  • downloadfilename задает имя, используемое при записи загружаемого файла.

SRC_URI_OVERRIDES_PACKAGE_ARCH

По умолчанию система сборки OE автоматически обнаруживает наличие в SRC_URI машинозависимых файлов и в этом случае меняет значение PACKAGE_ARCH. Установка для переменной значения 0 отключает это.

SRCDATE

Дата исходного кода, применяемого для сборки пакета. Эта переменная применяется только для кодов, извлеченных из SCM.

SRCPV

Возвращает строку версии текущего пакета, используемую при определении значения переменной PV. Переменная SRCPV определена в конфигурационном файле meta/conf/bitbake.conf дерева исходных кодов, как SRCPV = «${@bb.fetch2.get_srcrev(d)}».

Задания, которым нужно определить PV, делают это с помощью SRCPV. Например, задание (ofono_git.bb) в каталоге meta/recipes-connectivity дерева исходных кодов задает PV в виде PV = «0.12-git${SRCPV}».

SRCREV

Выпуск исходных кодов, используемых для сборки пакета. Эта переменная применима лишь к исходным кодам Subversion, Git, Mercurial и Bazaar. Если нужно собрать фиксированную версию без запросов к удаленному репозиторию всякий раз, когда BitBake анализирует задание, следует указать в переменной SRCREV полный идентификатор версии, а не просто тег. Информация об ограничениях при наследовании последней версии программы из SRCREV приведена в описании переменной AUTOREV и разделе Automatically Incrementing a Binary Package Revision Number [2].

SSTATE_DIR

Каталог для кэша общих состояний.

SSTATE_MIRROR_ALLOW_NETWORK

Установка значения 1 разрешает выборку из «зеркал», указанных в переменной SSTATE_MIRRORS, даже в случаях, когда выборка из сети отключена установкой BB_NO_NETWORK = «1». применение переменной SSTATE_MIRROR_ALLOW_NETWORK полезно с тех случаях, когда нужно указать в SSTATE_MIRRORS внутренний сервер для общего кэше состояний, но требуется запретить другие выборки из сети.

SSTATE_MIRRORS

Настраивает систему сборки OE на поиск других зеркал с подготовленными объектами данных кэша перед сборкой. Эта переменная работает как сборщики MIRRORS и PREMIRRORS,
указывая
расположение кэша для поиска общих
объектов состояния
(sstate).

Можно указать каталог файловой системы или идентификатор URL, такой как HTTP или FTP. Заданное место должно содержать результаты кэширования общего состояния (sstate-cache) из предшествующей сборки. В качестве sstate-cache могут служить результаты сборки на другой машине.

При указании на данные sstate на другой машине, использующей другую версию GCC для естественной сборки, нужно указать в SSTATE_MIRROR регулярное выражение для отображения локального пути поиска в путь на сервере. В путях нужно учитывать значение NATIVELSBSTRING,
установленное
классом
uninative. Например, отображение локального пути поиска universal-4.9 на серверный путь server_url_sstate_path
имеет
вид
SSTATE_MIRRORS ?= file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n.

Если зеркало использует такую же структуру, как SSTATE_DIR, нужно добавить PATH в конце, как показано в примере ниже. Система сборки подставит корректный путь поиска в структуре каталогов.

SSTATE_MIRRORS ?= "\
     file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ file://.* file:///some-local-dir/sstate/PATH"

SSTATE_SCAN_FILES

Управляет списком файлов, сканируемых системой сборки OE для жестко заданных путей установки. Переменная содержит список разделенных пробелами имен файлов (не путей) с возможностью использования стандартных символов-шаблонов. При сборке система OE создает объект общего состояния (sstate) на первом этапе подготовки sysroot. Объект сканируется на предмет жестко заданных путей для исходных мест установки. Список файлов, для которых сканируются пути, определяет переменная SSTATE_SCAN_FILES. Обычно задания добавляют файлы для сканирования в переменную SSTATE_SCAN_FILES, а не в переменную, задающую полный набор. Принятый по умолчанию список файлов задает класс sstate. Детали процесса даны в описании класса staging.

STAGING_BASE_LIBDIR_NATIVE

Задает путь к каталогу /lib в sysroot для сборочного хоста.

STAGING_BASELIBDIR

Задает путь к каталогу /lib в sysroot для целевой платформы текущего задания (STAGING_DIR_HOST).

STAGING_BINDIR

Задает путь к каталогу /usr/bin внутри sysroot целевой системы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_BINDIR_CROSS

Задает путь к каталогу с двоичными сценариями настройки, содержащими конфигурационные данные для других программ, которым нужны библиотеки или включаемые файлы программы, связанной со сценарием. Этот стиль настройки конфигурации сборки в значительной степени заменен pkg-config, поэтому при поддержке pkg-config соответствующей библиотекой рекомендуется использовать pkg-config вместо сценария настройки.

STAGING_BINDIR_NATIVE

Задает путь к каталогу /usr/bin в каталоге sysroot для хоста сборки.

STAGING_DATADIR

Задает путь к каталогу /usr/share в sysroot для целевой платформы текущего задания (STAGING_DIR_HOST).

STAGING_DATADIR_NATIVE

Задает путь к каталогу /usr/share в каталоге sysroot для хоста сборки.

STAGING_DIR

Помогает создавать для заданий каталоги sysroot, используемые при подготовке пакетов. Информация о подготовке sysroot для заданий приведена в параграфе 7.1.22. do_populate_sysroot, разделах Sharing Files Between Recipes [2] и Configuration, Compilation, and Staging [1], а также в описании переменной SYSROOT_DIRS. Заданиям не следует писать напрямую в каталог STAGING_DIR, поскольку система сборки OE поддерживает каталог автоматически. Задания должны устанавливаться в ${D} задачей do_install в задании, а система сборки OE будет помещать часть файлов в sysroot.

STAGING_DIR_HOST

Указывает путь к каталогу sysroot для системы, на которой выполняется сборка компонент (системы, где размещаются компоненты). Для большинства заданий sysroot — это один из каталогов, куда задача do_populate_sysroot копирует файлы. Исключениями являются задания -native, где задача do_populate_sysroot использует каталог STAGING_DIR_NATIVE. В зависимости от типа задания и цели сборки STAGING_DIR_HOST может принимать одно из двух значений:

  • ${STAGING_DIR}/${MACHINE} для заданий, собираемых для целевой машины;
  • при сборке заданий для сборочного хоста значение пусто, если используются каталоги сборочного хоста.

Задания -native не устанавливаются в естественные пути хоста, такие как /usr, а помещаются в STAGING_DIR_NATIVE. При сборке таких заданий стандартные переменные окружения (такие как CPPFLAGS и CFLAGS) устанавливаются так, что поиск библиотек и заголовочных файлов выполняется по путям хоста и STAGING_DIR_NATIVE с использованием, например опции GCC -isystem. Таким образом, делается акцент на то, что переменные STAGING_DIR* должны рассматриваться как входные такими задачами, как do_configure, do_compile и do_install. Наличие реальной корневой системы, соответствующей STAGING_DIR_HOST, имеет концептуальный смысл для заданий -native, поскольку они используют двоичные и заголовочные файлы хоста.

STAGING_DIR_NATIVE

Задает путь к каталогу sysroot, используемому при сборке компонент, работающих на самом сборочном хосте.

STAGING_DIR_TARGET

Задает путь к sysroot в системе, для которой генерируется код. Для компонент, не создающих код (их большинство), переменная STAGING_DIR_TARGET совпадает с STAGING_DIR_HOST. Некоторые задания создают код для использования в целевой системе, но эти двоичные файлы в свою очередь генерируют код для другой отличающейся системы (например, задания cross-canadian). В терминологии GNU первичная система называется хостом (HOST), а вторичная — целью (TARGET). Таким образом, двоичные файлы хоста создают двоичные файлы для целевой платформы (TARGET). Переменная STAGING_DIR_HOST указывает каталог sysroot, используемый хост-системой, а STAGING_DIR_TARGET указывает sysroot для TARGET.

STAGING_ETCDIR_NATIVE

Задает путь к каталогу /etc в sysroot сборочного хоста.

STAGING_EXECPREFIXDIR

Задает путь к каталогу /usr в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_INCDIR

Задает путь к каталогу /usr/include в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_INCDIR_NATIVE

Задает путь к каталогу /usr/include в sysroot сборочного хоста.

STAGING_KERNEL_BUILDDIR

Указывает каталог, содержащий элементы сборки (artifact) ядра. Задания, собирающие программы, которым нужен доступ к таким элементам (например, systemtap-uprobes) могут просматривать STAGING_KERNEL_BUILDDIR для поиска нужных элементов после сборки ядра.

STAGING_KERNEL_DIR

Каталог с заголовками ядра, которые нужны для сборки внешних модулей.

STAGING_LIBDIR

Задает путь к каталогу /usr/lib в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_LIBDIR_NATIVE

Задает путь к каталогу /usr/lib в sysroot сборочного хоста.

STAMP

Задает базовый путь для создания штампов задания. Фактический путь к штампам определяется путем преобразования этой строки и добавления в нее дополнительной информации. В настоящее время переменная задается файлом meta/conf/bitbake.conf в виде STAMP = «${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}». Дополнительная информация об использовании штампов для решения вопроса о повторном запуске задач приведена в разделе Stamp Files and the Rerunning of Tasks [1].

STAMPS_DIR

Задает каталог, в который система сборки OE помещает штампы сборки (по умолчанию ${TMPDIR}/stamps).

STRIP

Сокращенное имя и аргументы для команды strip, используемой для исключения символов из файлов.

SUMMARY

Короткое (до 72 символов) описание двоичного пакета для системы установки (например, opkg, rpm
или
dpkg). По умолчанию значение SUMMARY служит значением переменной DESCRIPTION,
если
она не указана в задании
.

SVNDIR

Каталог, в котором выбираются и сохраняются файлы системы Subversion.

SYSLINUX_DEFAULT_CONSOLE

Задает консоль, используемую по умолчанию при загрузке ядра. Для использования другой консоли следует установить нужное значение в файле конфигурации задания. Например, SYSLINUX_DEFAULT_CONSOLE = «console=ttyX», где X указывает номер нужной консоли. Класс syslinux исходно устанавливает для переменной пустое значение, но затем проверяет его.

SYSLINUX_OPTS

Задает опции, добавляемые в файл syslinux. Переменная устанавливается в задании, опции разделяются точкой с запятой (;). Класс syslinux использует эту переменную для создания набора опций.

SYSLINUX_SERIAL

Задает дополнительный последовательный порт или отключает порт при пустом значении переменной в задании. Принятое по умолчанию значение переменной задает класс syslinux в виде SYSLINUX_SERIAL ?= «0 115200». Этот класс проверяет и при необходимости использует переменную.

SYSLINUX_SPLASH

Указывает файл .LSS,
используемый
в качестве фона загрузочного меню
VGA. Переменная устанавливается в задании. Класс syslinux проверяет переменную и при наличии файла система сборки OE устанавливает заставку.

SYSLINUX_SERIAL_TTY

Задает дополнительную консоль (console=tty…) для загрузки ядра. По умолчанию для этой переменной класс syslinux устанавливает SYSLINUX_SERIAL_TTY ?= «console=ttyS0,115200», проверяя и используя затем эту переменную.

SYSROOT_DESTDIR

Указывает временный каталог внутри рабочего каталога (по умолчанию ${WORKDIR}/sysroot-destdir), где собираются файлы, помещаемые в sysroot, в процессе выполнения задачи do_populate_sysroot.

SYSROOT_DIRS

Каталоги, помещаемые в sysroot задачей do_populate_sysroot. Принятые по умолчанию каталоги приведены ниже.

     SYSROOT_DIRS = " \
         ${includedir} \
         ${libdir} \
         ${base_libdir} \
         ${nonarch_base_libdir} \
         ${datadir} \
     "

SYSROOT_DIRS_BLACKLIST

Каталоги, не помещаемые в sysroot задачей do_populate_sysroot. Переменная может служить для исключения некоторых каталогов, указанных в SYSROOT_DIRS. По умолчанию исключаются приведенные ниже каталоги.

     SYSROOT_DIRS_BLACKLIST = " \
         ${mandir} \
         ${docdir} \
         ${infodir} \
         ${datadir}/locale \
         ${datadir}/applications \
         ${datadir}/fonts \
         ${datadir}/pixmaps \
     " 

SYSROOT_DIRS_NATIVE

Каталоги, помещаемые в sysroot задачей do_populate_sysroot
для заданий
-native, в дополнение к каталогам из SYSROOT_DIRS. Включаемые по умолчанию дополнительные каталоги приведены ниже.

     SYSROOT_DIRS_NATIVE = " \
         ${bindir} \
         ${sbindir} \
         ${base_bindir} \
         ${base_sbindir} \
         ${libexecdir} \
         ${sysconfdir} \
         ${localstatedir} \
     "

Программы, собирающие задания -native,
запускаются
напрямую из
sysroot (STAGING_DIR_NATIVE), поэтому нужно подготовить дополнительные каталоги с исполняемыми файлами и файлами поддержки.

SYSROOT_PREPROCESS_FUNCS

Список функций, выполняемых после размещения файлов в sysroot, которые обычно служат для дополнительной обработки размещенных файлов или размещения дополнительных файлов.

SYSTEMD_AUTO_ENABLE

При наследовании класса systemd эта переменная определяет, нужно ли автоматически запускать службу, указанную в SYSTEMD_SERVICE. Ао умолчанию службы запускаются при загрузке автоматически, что задается классом systemd в форме SYSTEMD_AUTO_ENABLE ??= «enable». Эту настройку можно изменить, указав disable.

SYSTEMD_BOOT_CFG

При установке EFI_PROVIDER = «systemd-boot» эта переменная задает конфигурационный файл, который следует использовать. По умолчанию класс systemd-boot устанавливает SYSTEMD_BOOT_CFG ?= «${S}/loader.conf». Информация о Systemd-boot доступна по ссылке Systemd-boot.

SYSTEMD_BOOT_ENTRIES

При EFI_PROVIDER = «systemd-boot» переменная задает список файлов (*.conf) для установки, содержащих по одной загрузочной записи в строке. По умолчанию класс systemd-boot задает SYSTEMD_BOOT_ENTRIES ?= «» (см. документацию Systemd-boot).

SYSTEMD_BOOT_TIMEOUT

При установке EFI_PROVIDER = «systemd-boot» задает время ожидания меню загрузки в секундах. По умолчанию класс systemd-boot устанавливает SYSTEMD_BOOT_TIMEOUT ?= «10» (см. документацию Systemd-boot).

SYSTEMD_PACKAGES

При наследовании класса systemd указывает файлы блоков systemd, когда они не найдены в основном задании пакета. По умолчанию переменная устанавливается так, что файлы блоков systemd предполагаются в основном задании пакета, — SYSTEMD_PACKAGES ?= «${PN}». Если это не так, в переменной SYSTEMD_PACKAGES нужно указать список пакетов, в которых система сборки будет искать файлы блоков systemd.

SYSTEMD_SERVICE

При наследовании класса systemd задает имя службы systemd для пакета. При указании этого файла в задании нужно использовать переопределение имени пакета, к которому применяется значение, в форме SYSTEMD_SERVICE_${PN} = «connman.service».

SYSVINIT_ENABLED_GETTYS

При использовании SysVinit задает список разделенных пробелами виртуальных терминалов, которые должны запускать getty (разрешая login), если USE_VT отлична от 0. По умолчанию принято SYSVINIT_ENABLED_GETTYS = «1» (getty запускается лишь на первом виртуальном терминале).

T

T

Указывает каталог, где BitBake размещает временные файлы (в основном log-файлы задач и сценариев при сборке конкретных заданий). Для этой переменной обычно устанавливается значение T = «${WORKDIR}/temp»

Переменная WORKDIR указывает каталог, в который BitBake распаковывает и собирает задание. По умолчанию эта переменная задается в файле bitbake.conf.

Переменную T не следует путать с переменной TMPDIR, которая указывает корень дерева, куда BitBake размещает вывод всего процесса сборки.

TARGET_ARCH

Архитектура целевой платформы. Система сборки OE поддерживает множество архитектур, включая arm, i586, x86_64, powerpc, powerpc64, mips, mipsel. Дополнительная информация о вариантах архитектуры приведена в описании переменной TUNE_ARCH.

TARGET_AS_ARCH

Задает зависимые от архитектуры флаги ассемблера для целевой системы и по умолчанию инициализируется значением TUNE_ASARGS в конфигурационном файле BitBake (meta/conf/bitbake.conf) как TARGET_AS_ARCH = «${TUNE_ASARGS}»

TARGET_CC_ARCH

Задает зависимые от архитектуры флаги компилятора C для целевой системы и по умолчанию инициализируется значением TUNE_CCARGS. Это общий подход для добавления LDFLAGS в TARGET_CC_ARCH в заданиях, собирающих программы для целевой системы, которые иначе не учитывали бы экспортируемую переменную LDFLAGS.

TARGET_CC_KERNEL_ARCH

Это специальный флаг компилятора ядра для настройки CPU или ABI. Флаг применяется редко и лишь в случаях, где значение TUNE_CCARGS не совместимо с компиляцией ядра. Переменная позволяет ядру (и связанным с ним модулям) использовать другую конфигурацию. Примером может служить файл meta/conf/machine/include/arm/feature-arm-thumb.inc в дереве исходных кодов.

TARGET_CFLAGS

Задает флаги для передачи компилятору C c при сборке для целевой системы. При сборке в контексте целевой системы CFLAGS по умолчанию получает значение этой переменной. Сценарий настройки окружения SDK устанавливает для переменной CFLAGS в среде значение TARGET_CFLAGS, чтобы при сборке исполняемых файлов с использованием SDK также применялись эти флаги.

TARGET_CPPFLAGS

Задает флаги для передачи препроцессору C (т. е. компиляторам C и C++) при сборке для целевой системы. При сборке в контексте целевой системы CPPFLAGS по умолчанию получает значение этой переменной. Сценарий настройки окружения SDK устанавливает для переменной CPPFLAGS в среде значение TARGET_CPPFLAGS, чтобы при сборке исполняемых файлов с использованием SDK
также применялись эти флаги.

TARGET_CXXFLAGS

Задает флаги для передачи компилятору C++ при сборке для целевой системы. При сборке в контексте целевой системы CXXFLAGS по умолчанию получает значение этой переменной. Сценарий настройки окружения SDK устанавливает для переменной CXXFLAGS в среде значение TARGET_CXXFLAGS, чтобы при сборке исполняемых файлов с использованием SDK также применялись эти флаги.

TARGET_FPU

Задает метод обработки кода FPU. Для платформ без FPU, к которым относится большинство ARM CPU, эта переменная должна иметь значение «soft». В противном случае применяется эмуляция ядра, что снижает производительность.

TARGET_LD_ARCH

Задает зависимые от архитектуры флаги компоновщика для целевой системы и по умолчанию инициализируется значением TUNE_LDARGS в конфигурационном файле BitBake (meta/conf/bitbake.conf) как TARGET_LD_ARCH = «${TUNE_LDARGS}».

TARGET_LDFLAGS

Задает флаги для передачи компоновщику при сборке для целевой платформы. При сборке в контексте целевой системы переменная LDFLAGS по умолчанию получает значение этой переменной. Сценарий настройки окружения SDK устанавливает для переменной LDFLAGS в среде значение TARGET_LDFLAGS, чтобы при сборке исполняемых файлов с использованием SDK также применялись эти флаги.

TARGET_OS

Задает операционную систему целевой платформы. Переменная получает значение linux для систем на основе glibc (библиотека GNU C) и linux-musl для систем с библиотекой musl. Для платформ ARM/EABI возможны значения linux-gnueabi и linux-musleabi.

TARGET_PREFIX

Задает префикс для двоичных файлов инструментария целевой платформы. В зависимости от типа задания и цели сборки переменная TARGET_PREFIX может устанавливаться по разному.

  • Для заданий, собирающих целевую машину применяется «${TARGET_SYS}-«.
  • Для естественных заданий устанавливается значение BUILD_PREFIX.
  • Для заданий nativesdk устанавливается значение SDK_PREFIX.

TARGET_SYS

Задает систему (включая архитектуру и ОС), для которой выполняется сборка в контексте текущего задания. Система сборки OE автоматически устанавливает эту переменную на основе TARGET_ARCH, TARGET_VENDOR, и TARGET_OS. Менять переменную самостоятельно не требуется.

Для естественного задания для 32-битовой машины x86 с Linux переменная будет иметь значение i686-linux, для платформы little-endian MIPS с Linux — mipsel-linux.

TARGET_VENDOR

Задает имя производителя целевой платформы.

TCLIBC

Задает вариант стандартной библиотеки GNU C (libc) для использования при сборке. Переменная заменила POKYLIBC, которая больше не поддерживается. Возможны варианты glibc, musl, newlib или baremetal.

TCLIBCAPPEND

Задает суффикс, добавляемый к значению TMPDIR и указывающий вариант libc для сборки. При сборке нескольких вариантов в одном сборочном каталоге этот механизм обеспечивает предотвращение конфликтов. В файле defaultsetup.conf задано принятое по умолчанию значение TCLIBCAPPEND = «-${TCLIBC}». Однако такие дистрибутивы, как poky, обычно поддерживают один вариант libc и устанавливают TCLIBCAPPEND = «» в своем файле конфигурации.

TCMODE

Задает селектор набора инструментов, управляя характеристиками создаваемых приложений и образов путем указания системе сборки OE применяемого профиля набора инструментов. По умолчанию система сборки OE применяет свой инструментарий и переменная имеет значение default.

Если для TCMODE установлено другое значение, нужно обеспечить совместимость указанного инструментария с принятым по умолчанию. Использование слишком старых или новых компонент может вызвать проблемы при сборке. Совместимость разных компонент описывается в замечанию к выпускам YP (Release Notes), доступным на странице Downloads по ссылкам RELEASE INFORMATION для соответствующих выпусков.

Переменная TCMODE похожа на TCLIBC, которая контролирует вариант стандартной библиотеки GNU C (libc), используемый при сборке (glibc или musl).

При использовании дополнительных уровней можно задать внешний инструментарий. Примером может служить Sourcery G++ Toolchain, поддержка которого задана в отдельном уровне Mentor Graphics® meta-sourcery, доступном по ссылке http://github.com/MentorEmbedded/meta-sourcery/. Файл README для этого уровня описывает использование Sourcery G++ Toolchain в качестве внешнего инструментария. Вам нужно добавить уровень в свой файл bblayers.conf перед мета-уровнем и установить переменную EXTERNAL_TOOLCHAIN в файле local.conf, указав место размещения инструментов.

Используемые в упомянутом примере принципы применимы к любому внешнему инструментарию. Можно использовать уровень meta-sourcery в качестве шаблона для добавления своего уровня внешних инструментов.

TEST_EXPORT_DIR

Место, используемое системой сборки OE для экспорта тестов при установке TEST_EXPORT_ONLY = «1» (по умолчанию ${TMPDIR}/testimage/${PN}).

TEST_EXPORT_ONLY

Задает лишь экспорт тестов. Установка значение 1 приведет к тому, что тесты будут экспортированы, но не будут запускаться в системе сборки.

TEST_LOG_DIR

Указывает место хранения журналов загрузки и SSH для машин QEMU (по умолчанию ${WORKDIR}/testimage). Фактические результаты теста сохраняются в журнале задачи log.do_testimage в каталоге ${WORKDIR}/temp/.

TEST_POWERCONTROL_CMD

При автоматизированном тестировании оборудования задает команду, применяемую для управления питанием на тестируемой целевой машине. Обычно эта команда указывает сценарий, который выполняет нужные действия (например, взаимодействует с управляемым через web сетевым удлинителем). Указанная команда должна ожидать в качестве последнего аргумента значение «off», «on» или «cycle» для включения, выключения или цикла (выключение с последующим включением).

TEST_POWERCONTROL_EXTRA_ARGS

При автоматизированном тестировании оборудования задает дополнительные аргументы, передаваемые команде, указанной в TEST_POWERCONTROL_CMD. Установка переменной необязательна. Она может служить, например, для разделения зависимых и независимых от машины частей команды.

TEST_QEMUBOOT_TIMEOUT

Время в секундах с начала загрузки, по истечение которого начнется автоматизированное тестирование образа. Используемый по умолчанию тайм-аут 500 секунд позволяет процессу загрузки дойти до приглашения на вход в систему (login). Можно указать иное время ожидания в файле local.conf. Дополнительные сведения о тестировании образов приведены в разделе Performing Automated Runtime Testing [2].

TEST_SERIALCONTROL_CMD

При автоматизированном тестировании оборудования задает команду, применяемую для подключения последовательной консоли на тестируемой платформе. Команда просто должна подключиться к консоли и перенаправить в это соединение стандартный-ввод-вывод, как это делает обычная терминальная программа. Например, для использования терминала Picocom с устройством /dev/ttyUSB0 на скорости 115200 бит/с можно указать TEST_SERIALCONTROL_CMD = «picocom /dev/ttyUSB0 -b 115200».

TEST_SERIALCONTROL_EXTRA_ARGS

При автоматизированном тестировании оборудования задает дополнительные аргументы, передаваемые команде, указанной в TEST_SERIALCONTROL_CMD. Установка переменной необязательна. Она может служить, например, для разделения зависимых и независимых от машины частей команды.

TEST_SERVER_IP

IP-адрес сборочной машины, который обычно определяется автоматически и при отказе детектирования нужно установить его вручную. Переменная применяют лишь немногими тестами, такими как dnf, которым нужно загружать пакеты из WORKDIR/oe-rootfs-repo.

TEST_TARGET

Указывает целевой контроллер для выполнения тестов образа (по умолчанию TEST_TARGET = «QemuTarget»). Целевым контроллером служит класс, определяющий развертывание образа на целевой платформе и запуск платформы. Уровень может расширять контроллеры путем добавления модулей в свой каталог /lib/oeqa/controllers и наследования абстрактного класса BaseTarget, который не может служить значением TEST_TARGET.

Поддерживаемые TEST_TARGET
значения
описаны ниже.

  • «QemuTarget»загрузка образа QEMU и запуск тестов (см. раздел Enabling Runtime Tests on QEMU).
  • «SimpleRemoteTarget»запуск тестов на целевой платформе, которая уже работает. Оборудование может находиться в сети или эмулироваться в QEMU. Требуется установка переменной TEST_TARGET_IP. Этот параметр определен в файле meta/lib/oeqa/controllers/simpleremote.py.

Сведения о запуске тестов на оборудовании приведены в разделе Enabling Runtime Tests on Hardware [2].

TEST_TARGET_IP

IP-адрес тестируемого оборудования. TEST_TARGET_IP не работает при установке TEST_TARGET = «qemu».

Вместе с адресом IP можно указать порт, например, TEST_TARGET_IP = «192.168.1.4:2201». Указание порта полезно при работе SSH через нестандартный порт, например, при размещении тестируемого устройства за межсетевым экраном или транслятором адресов и портов.

TEST_SUITES

Упорядоченный список тестов (модулей) для запуска применительно к образу с целью автоматического тестирования при работе. Система сборки OE обеспечивает базовый набор тестов для проверки образов. В настоящее время эти тесты работают только в QEMU. Тесты включают ping, ssh, df и др. Можно расширить список тестов, добавляя их в переменную TEST_SUITES в виде TEST_SUITES_append = » mytest«. Можно также указать TEST_SUITES_append = » auto» для применения всех доступных тестов.

Использование этой опции заставляет систему сборки автоматически запускать применимые к образу тесты. Порядок тестов имеет значение и зависящие от других тестов проверки должны выполняться после проверки от которой они зависят. Например, при добавлении в список тестов test_A и test_B,
где
test_B зависит от test_A
следует
указывать
TEST_SUITES = » test_A test_B».

Дополнительные сведения о тестировании образов приведены в разделе Performing Automated Runtime Testing [2].

TESTIMAGE_AUTO

Управляет запуском серии автоматизированных тестов для образов после успешной сборки. TESTIMAGE_AUTO = «1» вызывает автоматическую загрузку созданного образа в QEMU. Использование переменной также добавляет зависимости, поэтому сначала автоматически собираются все SDK, для которых запрошено тестирование.

Тесты написаны на Python с использованием модуля unittest и основная часть тестов запускает команды на целевой системе по протоколу ssh. Можно установить для переменной значение 1 в файле local.conf каталога сборки, чтобы система сборки OE автоматически выполнила тесты после сборки образа. Дополнительные сведения о включении, запуске и создании тестов приведены в разделе Performing Automated Runtime Testing [2] и параграфе 6.132. testimage*.bbclass.

THISDIR

Каталог, в котором в данный момент выполняется разбор BitBake. Не меняйте эту переменную.

TIME

Время начала сборки в формате HMS (например, 140159 для 14 часов, одной минуты и 59 секунд).

TMPDIR

Эта переменная указывает базовый каталог, используемый системой сборки OE для всего вывода результатов и промежуточных файлов (кроме общего кэша состояний). По умолчанию переменная TMPDIR указывает каталог tmp в каталоге сборки. Если нужно разместить временный каталог в другом месте, можно убрать знак комментария и отредактировать показанную ниже строку файла conf/local.conf в дереве исходных кодов.

     #TMPDIR = "${TOPDIR}/tmp"

Примером такого использования служит указание в переменной TMPDIR локального диска, который не использует NFS, при размещении каталога сборки на NFS.

Файловая система, указанная TMPDIR, должна поддерживать стандартную семантику (например, различать регистр символов в именах, поддерживать блокировки POSIX и сохраняющиеся значения inode). С учетом имеющихся в NFS проблем и наличия ошибок в некоторых реализациях, NFS не соответствует этим требованиям, поэтому TMPDIR не может указывать NFS.

TOOLCHAIN_HOST_TASK

Эта переменная указывает пакеты, которые система сборки OE использует при создании SDK со средой кросс-компиляции. Эти пакеты являются частью инструментария, работающего на SDKMACHINE, и обычно каждый пакет должен иметь префикс nativesdk-. Рассмотрим в качестве примера команду сборки SDK

$ bitbake -c populate_sdk imagename

В этом случае в переменной указан принятый по умолчанию список пакетов, но его можно расширить (см. раздел Adding Individual Packages to the Standard SDK [7]). Базовые сведения о кросс-разработке в среде YP приведены в разделе Cross-Development Toolchain Generation [1], а организация среды разработки описана в [7].

TOOLCHAIN_OUTPUTNAME

Задает имя, используемое для вывода инструментария. Класс populate_sdk_base устанавливает TOOLCHAIN_OUTPUTNAME ?= «${SDK_NAME}-toolchain-${SDK_VERSION}«. Дополнительная информация приведена в описаниях переменных SDK_NAME и SDK_VERSION.

TOOLCHAIN_TARGET_TASK

Перечисляет пакеты, используемые системой сборки OE при создании целевой части SDK (т. е. части, собираемой для целевой платформы), включающей библиотеки и файлы заголовков. Дополнительная информация о добавлении пакетов в SDK приведена в разделе Adding Individual Packages to the Standard SDK [7]. Базовые сведения об инструментах кросс-разработки в среде YP можно найти в разделе Cross-Development Toolchain Generation [1], организация среды кросс-разработки описана в [7].

TOPDIR

Верхний уровень каталога сборки. BitBake автоматически инициализирует переменную при установке рабочей среды с помощью oe-init-build-env (параграф 5.1.9.1 oe-init-build-env).

TRANSLATED_TARGET_ARCH

Очищенный (sanitized) вариант TARGET_ARCH. Переменная применяется в тех случаях, где архитектура должна указываться в значениях, не поддерживающих символы подчеркивания (например, в именах пакетов). Эти символы в TARGET_ARCH заменяются символами дефиса. Не меняйте эту переменную.

TUNE_ARCH

Каноническая архитектура GNU (arm, armeb, mips, mips64 и т. п.), которую BitBake использует для настройки конфигурации. Определения TUNE_ARCH зависят от конкретной архитектуры и могут быть статическими или динамическими. Детали для конкретного семейства CPU можно найти в файле README для архитектуры. Например, файл meta/conf/machine/include/mips/README в дереве исходных кодов содержит информацию для TUNE_ARCH в архитектуре mips.

TUNE_ARCH тесно связана с переменной TARGET_ARCH, задающей архитектуру целевой машины. Конфигурационный файл BitBake (meta/conf/bitbake.conf) устанавливает переменную в форме TARGET_ARCH = «${TUNE_ARCH}».

Список поддерживаемых архитектур включает arm, i586, x86_64, powerpc, powerpc64, mips, mipsel и др.

TUNE_ASARGS

Задает зависящие от архитектуры флаги ассемблера для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_ASARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Например, файл meta/conf/machine/include/x86/arch-x86.inc определяет флаги для архитектуры x86 в форме TUNE_ASARGS += «${@bb.utils.contains(«TUNE_FEATURES», «mx32″, «-x32», «», d)}». Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_CCARGS

Задает зависящие от архитектуры флаги компилятора C для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_CCARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_LDARGS

Задает зависящие от архитектуры флаги компоновщика для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_LDARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Например, файл meta/conf/machine/include/x86/arch-x86.inc определяет флаги для архитектуры x86 в форме TUNE_LDARGS += «${@bb.utils.contains(«TUNE_FEATURES», «mx32», «-m elf32_x86_64», «», d)}». Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_FEATURES

Свойства, применяемые для «настройки» компилятора с целью оптимизации для конкретного процессора. Свойства определяются в файлах настройки и позволяют динамически создавать аргументы (TUNE_*ARGS) на основе свойств. Система сборки OE проверяет свойства на предмет их поддержки и отсутствия конфликтов.

Конфигурационный файл BitBake (meta/conf/bitbake.conf) задает TUNE_FEATURES ??= «${TUNE_FEATURES_tune-${DEFAULTTUNE}}». Дополнительная информация приведена в описании переменной DEFAULTTUNE.

TUNE_PKGARCH

Архитектура пакета, воспринимаемая системой подготовки пакетов для выбора архитектуры, ABI и настройки выходных пакетов. Конкретная настройка задается переопределением _tune в форме TUNE_PKGARCH_tune-tune = «tune«. Эти зависящие от настройки варианты архитектуры определяются во включаемых файлах для машин. Например, файл meta/conf/machine/include/tune-core2.inc указывает архитектуру в виде TUNE_PKGARCH_tune-core2-32 = «core2-32».

TUNEABI

Базовый интерфейс ABI, применяемый конкретной настройкой для данного уровня инструментов (по умолчанию разрешены все настройки). Провайдеры, использующие готовые библиотеки могут применять переменные TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNEABI_OVERRIDE

При установленной переменной система сборки игнорирует TUNEABI_WHITELIST.
Провайдеры, использующие готовые библиотеки могут применять переменные
TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNEABI_WHITELIST

Список разрешенных значений TUNEABI (по умолчанию разрешены все настройки). Провайдеры, использующие готовые библиотеки могут применять переменные TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNECONFLICTS[feature]

Задает функции тестирования CPU или ABI, конфликтующие со свойством. Известные конфликты указываются во включаемых файлах машин внутри дерева исходных кодов. Примером может служить файл meta/conf/machine/include/mips/arch-mips.inc,
в
котором указан конфликт
o32 и n64 с n32 в виде TUNECONFLICTS[n32] = «o32 n64».

TUNEVALID[feature]

Задает действительную функцию настройки CPU или ABI, сохраняемую как флаг. Действительные функции указаны во включаемых файлах машин (например, meta/conf/machine/include/arm/arch-arm.inc) в дереве исходных кодов. Ниже приведен пример из такого файла.

     TUNEVALID[bigendian] = "Enable big-endian mode."

U

UBOOT_CONFIG

Настраивает UBOOT_MACHINE и может также определять IMAGE_FSTYPES в отдельных случаях. Ниже приведен пример с уровня meta-fsl-arm.

     UBOOT_CONFIG ??= "sd"
     UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
     UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
     UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
     UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"

В этом примере выбран вариант sd из 4 возможных для UBOOT_MACHINE. Конфигурация sd определяет «mx6qsabreauto_config» как значение UBOOT_MACHINE, а «sdcard» задает IMAGE_FSTYPES для образа U-boot.

Обработка UBOOT_CONFIG рассмотрена в описании класса uboot-config (параграф 6.139. uboot-config.bbclass).

UBOOT_ENTRYPOINT

Задает точку входа для образа U-Boot, при создании которого эта переменная передается в качестве параметра команде uboot-mkimage.

UBOOT_LOADADDRESS

Задает адрес загрузки для образа U-Boot, при создании которого эта переменная передается в качестве параметра команде uboot-mkimage.

UBOOT_LOCALVERSION

Добавляет строку к имени локальной версии образа U-Boot. Например, для образа U-Boot версии 2013.10 можно задать полное имя 2013.10-yocto с помощью UBOOT_LOCALVERSION = «-yocto».

UBOOT_MACHINE

Задает значение, передаваемое команде make при сборке образа U-Boot и указывающее конфигурацию целевой платформы. Обычно эта переменная задается в файле конфигурации машины conf/machine/machine_name.conf.

Возможные значения переменной приведены в разделе Selection of Processor Architecture and Board Type файла U-Boot README.

UBOOT_MAKE_TARGET

Задает цель, указанную в Makefile (по умолчанию all).

UBOOT_SUFFIX

Указывает создаваемое расширение U-Boot. Например, u-boot.sb имеет расширение .sb. По умолчанию U-Boot использует расширение .bin

UBOOT_TARGET

Задает цель для сборки U-Boot, которая передается напрямую как часть команды make (например, SPL и AIS). Если эта переменная не задана, система сборки OE передает и использует значение all при сборке U-Boot.

UNKNOWN_CONFIGURE_WHITELIST

Задает список опций, для которых не нужно создавать предупреждений в процессе работы задачи do_configure, если сценарий configure сочтет опции не пригодными. Обычно недействительные опции просто не передаются сценарию configure (т. е. их следует удалять из EXTRA_OECONF и PACKAGECONFIG_CONFARGS). Однако имеются, например, базовые опции, которые могут быть не пригодны для некоторых сценариев configure. Предупреждать о таких опциях нет смысла, поэтому их добавляют в UNKNOWN_CONFIGURE_WHITELIST.

Проверка аргументов configure с использованием UNKNOWN_CONFIGURE_WHITELIST является частью класса insane и включается лишь в заданиях, наследующих класс autotools.

UPDATERCPN

Для задания, наследующих класс update-rc.d, переменная UPDATERCPN задает включаемый пакет initscript. По умолчанию используется значение ${PN}. С учетом того, что почти все задания, устанавливающие пакет initscripts, упаковывают его в основной пакет задания, эту переменную редко приходится устанавливать для заданий.

UPSTREAM_CHECK_GITTAGREGEX

Можно проверить использование каждым заданием последней версии разрабатываемого кода с помощью bitbake -c checkpkg. Если исходный код взят из репозитория Git, система сборки OE определяет последнюю версию, указывая самый новый тег для репозитория. Переменная UPSTREAM_CHECK_GITTAGREGEX позволяет задать регулярное выражение для фильтрации тегов, если принятый по умолчанию фильтр работает некорректно.

     UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"

UPSTREAM_CHECK_REGEX

Служит для задания регулярного выражения вместо принятого по умолчанию, когда система проверки пакетов анализирует страницу, найденную с помощью UPSTREAM_CHECK_URI., Например, UPSTREAM_CHECK_REGEX = «package_regex».

UPSTREAM_CHECK_URI

Можно проверить использование последней версии разрабатываемого кода для каждого задания с помощью команды bitbake
-c checkpkg
. Если исходные коды взяты из архива, последняя версия определяется просмотром списка в каталоге, где размещен архив с попыткой найти самый новый. Когда такой подход не работает, можно использовать UPSTREAM_CHECK_URI для указания URI со ссылкой на последнюю версию архива в форме UPSTREAM_CHECK_URI = «recipe_url».

USE_DEVFS

Управляет использованием devtmpfs для заполнения /dev. По умолчанию применяется USE_DEVFS = «1», но обычно указывается USE_DEVFS = «0» для статически заполняемого каталога /dev
(см. раздел Selecting a Device Manager [2]).

USE_VT

При использовании SysVinit определяет, нужно ли запускать программу getty на любом из виртуальных терминалов для записи журнала через эти терминалы. По умолчанию используется USE_VT = «0» в файле конфигурации машины для систем без подключенного графического дисплея, не поддерживающих функции виртуального терминала.

USER_CLASSES

Список классов для глобального наследования, которые используются системой сборки OE для включения дополнительных свойств (например, buildstats, image-mklibs
и
т. п.
). Принятый по умолчанию список задается в файле local.conf как USER_CLASSES ?= «buildstats image-mklibs image-prelink». Примером может служить файл meta-poky/conf/local.conf.sample в каталоге исходных кодов.

USERADD_ERROR_DYNAMIC

При установке значения error заставляет систему сборки OE выдавать сообщение об ошибке, если идентификаторы пользователя (uid) и группы (gid) не заданы в файлах files/passwd и files/group. При установке значения warn будут выводиться предупреждения.

По умолчанию система сборки динамически применяет значения uid и gid,
поэтому
переменная
USERADD_ERROR_DYNAMIC не устанавливается. Если нужны статические идентификаторы, следует задать в файле local.conf переменную USERADD_ERROR_DYNAMIC = «error». Переопределение принятого по умолчанию поведения предполагает установку статических значений uid и gid с помощью переменных USERADDEXTENSION, USERADD_UID_TABLES
и
USERADD_GID_TABLES.

USERADD_GID_TABLES

Задает файл паролей, используемый для получения статических идентификаторов групп (gid) при добавлении группы системой сборки OE в процессе установки пакета. При использовании статических значений gid
система
сборки
OE ищет в пути BBPATH файл files/group
и
применяет значения
идентификаторов. Переменная задается в файле local.conf
как
USERADD_GID_TABLES = «files/group». Для использования статических значений gid
устанавливается
USERADDEXTENSION = «useradd-staticids».

USERADD_PACKAGES

При наследовании класса useradd эта переменная задает отдельные пакеты задания, для которых нужно добавлять пользователей или группы. Например, для добавления пользователя в основном пакете задания служит строка USERADD_PACKAGES = «${PN}».

При использовании переменной USERADD_PACKAGES нужно задать одну или несколько переменных USERADD_PARAM, GROUPADD_PARAM
или
GROUPMEMS_PARAM.

USERADD_PARAM

При наследовании класса useradd эта переменная задает для пакета параметры, которые следует передать команде useradd для добавления пользователя при установке пакета. Ниже приведен пример из задания dbus.

     USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
                            --no-create-home --shell /bin/false \
                            --user-group messagebus"

Информация о стандартной команде Linux useradd
доступна
по ссылке
http://linux.die.net/man/8/useradd.

USERADD_UID_TABLES

Задает файл паролей, используемый для получения статических идентификаторов пользователей (uid) при добавлении системой сборки OE пользователя в процессе установки пакета. При использовании статических значений uid
система
сборки
OE ищет в пути BBPATH файл files/passwd и применяет найденные значения uid. Переменная задается в файле local.conf как USERADD_UID_TABLES = «files/passwd». Для использования статических идентификаторов указывается USERADDEXTENSION = «useradd-staticids».

USERADDEXTENSION

Значение useradd-staticids заставляет систему сборки OE при добавлении пользователей и групп применять статические файлы passwd и group найденные в пути BBPATH. Для этого в файл local.conf включается строка USERADDEXTENSION = «useradd-staticids», в результате чего система сборки OE реализует класс useradd-staticids. При использовании статических значений uid и gid нужно указать файлы files/passwd и files/group в переменных USERADD_UID_TABLES и USERADD_GID_TABLES,
а
также задать переменную
USERADD_ERROR_DYNAMIC.

V

VOLATILE_LOG_DIR

Задает постоянное наличие на целевой платформе каталога /var/log, используемого для записи журналов операций пост-установки. По умолчанию задано VOLATILE_LOG_DIR = «yes», что означает временные файлы журналов, а для постоянного их хранения следует установить значение «no».

W

WARN_QA

Задает проверки качества, отказы которых считаются предупреждениями системы сборки OE. Переменная указывается в файле конфигурации дистрибутива. Список возможных проверок указан в параграфе 6.56. insane.bbclass.

WKS_FILE_DEPENDS

При включении в задание, создающее образ, эта переменная указывает зависимости при сборке. Переменная используется только при активных образах Wic (IMAGE_FSTYPES содержит связанные с Wic записи).

WKS_FILE_DEPENDS похожа на переменную DEPENDS и может применяться в заданиях, собирающих образы Wic, добавляя зависимости к указанным в DEPENDS. Переменная позволяет задать список дополнительных зависимостей (например, естественные инструменты, загрузчики и т. п.), которые нужны для сборки образов Wic. Например, WKS_FILE_DEPENDS = «some-native-tool» указывает тот или иной естественный инструмент, от которого зависит сборка образа.

WKS_FILE

Задает расположение файла Wic kickstart, используемого системой сборки OE для создания образа с разделами (image.wic). Информация о работе с такими образами приведена в разделе Creating Partitioned Images Using Wic [2], а формат kickstart описывает Глава 9. Справочник по OpenEmbedded Kickstart (.wks).

WORKDIR

Имя рабочего каталога, в котором система OE собирает задание. Этот каталог размещается в структуре TMPDIR
и
относится к собираемому заданию
. Каталог WORKDIR определяется выражением ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}

Реальный каталог зависит от нескольких аспектов:

  • TMPDIR
    -
    выходной каталог верхнего уровня для сборки;
  • MULTIMACH_TARGET_SYSидентификатор целевой системы;
  • PN
    -
    имя задания;
  • EXTENDPE
    -
    эпоха (если переменная PE не задана, как в большинстве заданий, значение EXTENDPE пусто);
  • PV
    -
    версия задания;
  • PR
    -
    выпуск (revision) задания.

В качестве примера рассмотрим Source Directory верхнего уровня с именем poky, заданный по умолчанию каталог сборки poky/build и целевую систему qemux86-poky-linux. Пусть задание называется foo_1.3.0-r0.bb. В этом случае рабочим каталогом для сборки будет poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0

X

XSERVER

Указывает пакеты, которые нужно установить для поддержки X-сервера и драйверов для текущей машины при условии непосредственного включения в образ packagegroup-core-x11-xserver или опосредованного включения x11-base в IMAGE_FEATURES. По умолчанию значением XSERVER
будет
xserver-xorg xf86-video-fbdev xf86-input-evdev
, если в конфигурации машины не указано иное.

Глава 14. Контекст переменных

Хотя большинство переменных может применяться почти в любом контексте (файлы .conf, .bbclass, .inc, .bb), некоторые из них зачастую связаны с конкретным местом или контекстом. В этой главе описаны базовые привязки переменных к контексту.

14.1. Конфигурация

В последующий параграфах перечислены переменные конфигурации с контекстом distribution, machine и local.

14.1.1. Дистрибутив (Distro)

Переменные, контекстом которых служит конфигурация дистрибутива (distro), включают DISTRO,
DISTRO_NAME,
DISTRO_VERSION,
MAINTAINER,
PACKAGE_CLASSES,
TARGET_OS,
TARGET_FPU, TCMODE, TCLIBC.

14.1.2. Машина

Переменные, контекстом которых служит конфигурация машины, включают TARGET_ARCH, SERIAL_CONSOLES,
PACKAGE_EXTRA_ARCHS, IMAGE_FSTYPES, MACHINE_FEATURES,
MACHINE_EXTRA_RDEPENDS, MACHINE_EXTRA_RRECOMMENDS,
MACHINE_ESSENTIAL_EXTRA_RDEPENDS,
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS.

14.1.3. Локальные переменные

Переменные, контекстом которых служит локальная конфигурация в файле local.conf,
включают
DISTRO, MACHINE, DL_DIR, BBFILES, EXTRA_IMAGE_FEATURES,
PACKAGE_CLASSES, BB_NUMBER_THREADS, BBINCLUDELOGS,
ENABLE_BINARY_LOCALE_GENERATION.

14.2. Задания

В последующих параграфах указаны переменные из контекста заданий — требуемые и задающие зависимости, пути и дополнительные данные для сборки.

14.2.1. Требуемые переменные

В заданиях должны присутствовать переменные LICENSE,
LIC_FILES_CHKSUM
и
SRC_URI (для заданий, извлекающих локальные или удаленные файлы).

14.2.2. Зависимости

Зависимости между заданиями указываются в переменных DEPENDS,
RDEPENDS, RRECOMMENDS, RCONFLICTS
и
RREPLACES.

14.2.3. Пути

Переменные, определяющие пути в заданиях, включают WORKDIR,
S, FILES.

14.2.4. Дополнительная информация для сборки

Переменные, определяющие дополнительные данные для сборки заданий, включают DEFAULT_PREFERENCE,
EXTRA_OECMAKE, EXTRA_OECONF, EXTRA_OEMAKE, PACKAGECONFIG_CONFARGS,
PACKAGES.

Глава 15. Ответы на вопросы

15.1. Различия между Poky и OpenEmbedded

Термин Poky относится к конкретной системе сборки, предоставляемой YP и основанной на OE-Core и BitBake. Таким образом, базовым термином для систем сборки является «система сборки OE». Работа в YP с использованием Poky тесно связана с OE, при этом изменения сначала передаются в OE-Core или BitBake, а затем возвращаются в Poky. Это полезно для обоих проектов.

15.2. Выполнение требований к Git, tar и Python

Нужны версии программ для сборочного хоста можно получить разными способами, описанными в параграфе 1.3. Требуемые версии Git, tar и Python.

15.3. Стабильность работы Poky/OpenEmbedded-Core

  • Команда YP поддерживает уровень OE-Core компактным и целенаправленным, включая в него около 830 заданий в отличие от тысяч других, доступных в сообществе OE. Это упрощает тестирование и поддержку.

  • Команда YP проводит ручное и автоматизированное тестирование для небольшого набора эталонного оборудования и эмулируемых платформ.

  • В YP применяется автоматический сборщик, который обеспечивает тестирование сборки и интеграции.

15.4. Включение поддержки платы в YP

Поддержка новой платы добавляется созданием уровня BSP для нее. Создание уровня BSP описано в разделах Understanding and Creating Layers [2] и Yocto Project Board Support Package (BSP) Developer’s Guide [6]. Если плата не является совсем экзотической, добавление ее поддержки в YP достаточно просто.

15.5. Продукция, использующая систему сборки OE

Программы, работающие на Vernier LabQuest, используют систему сборки OE (см. сайт Vernier LabQuest). Существует множество подготовленных к производству (pre-production) устройств, использующих систему сборки OE и команда YP анонсирует их по мере выпуска.

15.6. Вывод системы сборки OE

Поскольку один и тот же набор заданий может применяться для вывода в разных форматах, вывод системы сборки OE зависит от способа запуска сборки. Обычно выводом служат образы, пригодные для установки на целевой платформе.

15.7. Добавление своего пакета в YP

Для добавления пакета нужно создать задание BitBake, как описано в разделе Writing a New Recipe [2].

15.8. Обновление программ на целевой платформе

Система сборки OE может создавать пакеты в разных форматах, включая IPK для OPKG, Debian (.deb) и RPM. Можно обновлять пакеты с помощью менеджера пакетов на устройстве, как в обычных дистрибутивах Linux. Однако управление пакетами на целевой платформе реализуется не всегда.

15.9. Ошибки chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x

Возможно вы запустили сборку на файловой системе NTFS, хотя следует применять ext2, ext3 или ext4.

15.10. Ошибка 404 при загрузке исходных кодов в систему сборки OE

Ничего страшного! Система сборки OE проверяет все указанные зеркала исходных кодов в поисках архивов и заранее выбранных версий управляемых SCM программ. Эта проверка помогает при крупных инсталляциях, поскольку может снизить нагрузку на серверы SCM. Указанный в ошибке адрес просто является одним из настроенных в системе сборки зеркал.

15.11. Машинозависимые данные в пакете

Установите SRC_URI_OVERRIDES_PACKAGE_ARCH = «0» в файле .bb и обеспечьте маркировку файла как машинозависимого вручную, если это нужно. Код обработки SRC_URI_OVERRIDES_PACKAGE_ARCH содержится в файле meta/classes/base.bbclass.

15.12. Работа через межсетевой экран

Большая часть выборок исходных кодов системой сборки OE выполняется с помощью утилиты wget, поэтому следует указать настройки прокси в файле .wgetrc, который может размещаться в домашнем каталоге или в /usr/local/etc/wgetrc.

Ниже приведен пример настройки типов прокси в файле .wgetrc. По умолчанию эти настройки отключены символами комментария, которые следует удалить для включения нужных вариантов.

     # You can set the default proxies for Wget to use for http, https, and ftp.
     # They will override the value in the environment.
     #https_proxy = http://proxy.yoyodyne.com:18023/
     #http_proxy = http://proxy.yoyodyne.com:18023/
     #ftp_proxy = http://proxy.yoyodyne.com:18023/

     # If you do not want to use proxy at all, set this to off.
     #use_proxy = on

YP также включает файл meta-poky/conf/site.conf.sample, показывающий настройки прокси-серверов для CVS и Git. Дополнительная информация о настройке разных типов прокси приведена на странице Working Behind a Network Proxy.

15.13. Различие между target и target-native

Цели *-native предназначены для работы на системах, применяемых для сборки. Обычно это инструменты, требуемые для помощи при сборке (например, quilt-native
служит для применения patch-файлов). Не относящиеся к естественные (non-native) задания работают на целевых платформах.

15.14. Непонятные отказы при сборке

Если при одной и той же сборки возникают разные отказы, это может объясняться двумя причинами:

  • проблемы на сборочном хосте;

  • сборка происходит на виртуальной машине, а система виртуализации выдает ошибки.

Система сборки OE обрабатывает огромный объем данных, что связано с большим числом операций, включающих сеть, диски и процессоры, поэтому могут проявляться ошибки в любой из этих подсистем. Случайные и необъяснимые отказы всегда связаны с проблемами в оборудовании или системе виртуализации.

15.15. Проблемы с iconv.h при сборке естественных заданий

При получении сообщения об ошибке, указывающего, что библиотека GNU libiconv не применяется, но файл iconv.h включен из libiconv, нужно проверить наличие ранее установленной версии в файлах заголовков /usr/local/include.

     #error GNU libiconv not in use but included iconv.h is from libiconv

Если такой файл найден, следует удалить прежнюю установку (uninstall) или временно переименовать файл.

Эта проблема является проявлением «утечки системы», когда система сборки OE находит и использует установленные ранее файлы при сборке естественного кода. Такая ошибка может быть связана не только с iconv.h. Убедитесь, что утечка не происходит из каталогов /usr/local/include и /opt.

15.16. Лицензионные требования

Вопросы лицензирования могут потребовать консультаций с юристами. Следует помнить, что для соблюдения требований GPL нужно включать информацию, позволяющую другим заново собрать и воспроизвести предлагаемый вами вариант. Это означает предоставление исходного кода, всех внесенных в него изменений (patch), а также конфигурации настройки и сборки пакета.

Информация о лицензировании представлена в разделе Licensing [1] и Maintaining Open Source License Compliance During Your Product’s Lifecycle [2].

15.17. Отключение курсора на сенсорном экране

Нужно добавить файл форм-фактора, как описано в разделе Miscellaneous BSP-Specific Recipe Files [6]. Для переменной HAVE_TOUCHSCREEN устанавливается значение 1.

15.18. Активизация сетевых интерфейсов

Используемый по умолчанию файл interfaces из задания netbase не активизирует сетевые интерфейсы автоматически. Поэтому нужно добавить зависящее от BSP задание netbase, которое включает файл interfaces (см. раздел Miscellaneous BSP-Specific Recipe Files [6]). Например, можно добавить на свой уровень файлы

     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend

15.19. Увеличение свободного пространства для образа

По умолчанию система сборки OE использует коэффициент 1,3 при расчете размера корневой файловой системы. Для изменения размера нужно установить несколько параметров, описанных ниже.

  • Размер образа. Система сборки OE использует переменную IMAGE_ROOTFS_SIZE для задания размера образа в килобайтах. Размер определяется с учетом начальной корневой файловой системы до внесения каких-либо изменений (таких как запрошенный размер и дополнительное свободное место).

  • Служебное пространство. Переменная IMAGE_OVERHEAD_FACTOR задает коэффициент, применяемый при расчете размера (по умолчанию 1,3).

  • Дополнительное свободное пространство. Переменная IMAGE_ROOTFS_EXTRA_SPACE служит для добавления свободного пространства в образ после определения IMAGE_ROOTFS_SIZE.

15.20. Поддержка имен файлов и каталогов с пробелами

Команда YP пытается решить эту задачу, но объем работы для системы сборки OE слишком велик, поскольку она включает много программ (например, autoconf), не способных работать с именами, содержащими пробелы. Пока эта задача не будет решена, поддержка имен с пробелами невозможна.

15.21. Использование внешнего инструментария

Настройка инструментария обеспечивает достаточную гибкость и контролируется в основном переменной TCMODE,
которая
указывает файл
tcmode-*.inc file для включения каталога meta/conf/distro/include в дереве исходных кодов. По умолчанию переменная TCMODE имеет значение default, которое задает системе сборки OE использование встроенного инструментария (файл tcmode-default.inc). Однако можно задать и другие инструменты. В частности, значения external-* позволяют применять внешний инструментарий. Примером может служить использование Sourcery G++ Toolchain, поддержка которого задана в отдельном уровне meta-sourcery,
доступном
по ссылке
http://github.com/MentorEmbedded/meta-sourcery/.

В дополнение к настройке инструментов можно задать и файл задания для инструментария, который должен упаковать заранее собранные объекты, такие как libgcc, libstdcc++, файлы locale и libc.

15.22. Работа OE через межсетевой экран и прокси

Способ получения системой сборки исходных кодов поддерживает множество настроек. Вы можете обеспечить ее доступ к исходным кодам в большинстве случаев, если доступен транспорт HTTP.

При поиске исходных кодов система сборки сначала просматривает локальный каталог загрузки, затем используется переменная PREMIRRORS, «восходящий» источник и переменная MIRRORS в указанном порядке.

Для дистрибутива poky система сборки OE использует источники YP из переменной PREMIRRORS по умолчанию в качестве источников SCM и обновлений для обычных архивов, а затем возвращается к другим зеркалам, если с зеркалом YP возникает отказ.

Например, можно добавить конкретный сервер, который система сборки будет проверять раньше других, путем включения в файл local.conf строк, подобных приведенным ниже.

     PREMIRRORS_prepend = "\
     git://.*/.* http://www.yoctoproject.org/sources/ \n \
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"

Эти изменения заставят систему сборки перехватывать запросы Git, FTP, HTTP, HTTPS и направлять из зеркалу http://. Можно использовать URL file://
для
указания локальных или сетевых каталогов
.

Существует также другой вариант BB_NO_NETWORK = «1».

Этот оператор говорит BitBake о необходимости выдать ошибку вместо попытки доступа через Internet. Это полезно в тех случаях, когда нужно ограничиться сборкой из локальных источников.

Еще одним решением служит BB_FETCH_PREMIRRORONLY = «1».

Этот оператор ограничивает систему сборки извлечением файлов лишь из источников, заданных переменной PREMIRRORS.
Этот
метод полезен для воспроизведения
сборок.

Можно также использовать оператор BB_GENERATE_MIRROR_TARBALLS = «1».

Этот оператор заставляет систему сборки генерировать архивы зеркал. Такой подход полезен при необходимости создания сервера-зеркала. В остальных случаях он приведет лишь к увеличению времени сборки.

В заключение рассмотрим пример работы через межсетевой экран, пропускающий только трафик HTTP. Можно внести приведенные ниже изменения в файл local.conf,
если
по умолчанию используется сервер из
PREMIRRORS.

     PREMIRRORS_prepend = "\
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"
     BB_FETCH_PREMIRRORONLY = "1"      

Это заставит систему сборки извлекать все источники по протоколу HTTP, а все обращения к источникам, не указанным в PREMIRRORS будут приводить к отказу.

Система сборки также принимает во внимание стандартные переменные окружения http_proxy, ftp_proxy, https_proxy и all_proxy для перенаправления запросов на промежуточные серверы (proxy). Дополнительную информацию можно найти на странице Working Behind a Network Proxy.

15.23. Очистка результатов предыдущей сборки

Очистить результаты предыдущей сборки достаточно просто. При использовании BitBake для сборки образа весь вывод помещается в каталог, созданный при запуске сценария настройки окружения (например. oe-init-build-env). По умолчанию сборочный каталог называется build,
но
можно назвать его иначе
. В сборочном каталоге имеется подкаталог tmp. Для удаления вывода сборки с сохранением исходных кодов и загруженных файлов достаточно удалить содержимое каталога tmp.

15.24. Странные значения ${bindir} и ${libdir} для заданий -native

Возможно придется применять исполняемые файлв и библиотеки из каталога, отличающегося из того, в который они изначально установлены. Ситуацию осложняет то, что оной раз эти файлы и библиотеки компилируются с ожиданием запуска из заданного изначально каталога. В этом случае проблема решается переносом файлов.

Этот случай является фундаментальной проблемой для людей, поддерживающих пакеты основных дистрибутивов Linux, а также для системы сборки OE. Поэтому имеется устоявшееся решение проблемы. Предполагается, что файлы Makefile, инструменты автоматической настройки и другие системы сборки будут учитывать переменные окружения, такие как bindir, libdir
и
sysconfdir,
указывающие
расположение исполняемых файлов,
библиотек и данных при фактическом
выполнении программы. Также предполагается
учет переменной
DESTDIR, которая добавляется перед всеми другими переменными при установке файлов системой сборки. Понятно, что на деле программа не запускается из DESTDIR.

Когда система OE использует задание для сборки программу под целевую архитектуру (т. е. одно из предназначенных для включения в создаваемый образ), эта программа в конечно итоге запускается из корневой файловой системы этого образа. Таким образом, система сборки подставляет значение /usr/bin для bindir, /usr/lib для libdir
и
т. д
.

DESTDIR является путем в каталоге сборки. Однако при сборке заданием естественной (т. е. предназначенной для сборочного хоста) программы она не будет устанавливаться в корневую систему сборочного хоста. Поэтому система сборки использует пути внутри сборочного каталога для DESTDIR, bindir и связанных переменных. Чтобы лучше понять это, рассмотрим два пути, из которых первый представляется обычным, а второй — нет.

     /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
        1.2.8-r0/sysroot-destdir/usr/bin

     /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
        zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
        build/tmp/sysroots/x86_64-linux/usr/bin

Пути эти кажутся необычными, но они корректны. Первый указывает цель, а второй предназначен для «естественного» задания. Эти пути являются результатом применения механизма DESTDIR
и
на практике весьма эффективны, несмотря
на необычный вид
.

15.25. Проблемы с заданиями *-native

Задание
не
доступно для других заданий
. Файлы отсутствуют в естественном sysroot, задание устанавливается в некорректное место или возникают ошибки с правами доступа в задаче do_install.

Такая ситуация возникает, когда система сборки не распознает переменные окружения, предоставленные ей программой BitBake. Такая проблема возникала с файлом Makefile, в котором использовалась переменная окружения BINDIR вместо стандартной переменной bindir. Жестко заданное значение /usr/bin работает в большинстве случаев, но не вариантом -native для задания. Ошибки с правами доступа могут быть вызваны файлом Makefile, который игнорирует DESTDIR или использует иное имя для этой переменной окружения.

Глава 16. Участие в разработке и дополнительная информация

16.1. Введение

Команда YP рада людям, экспериментирующим с YP. Имеется множество способов получения помощи при возникновении трудностей или ошибок. Здесь также представлена информация об участии в работе YP.

16.2. Вклад в разработку

YP с удовольствие принимает вклад других людей. Вы можете представить свои изменения в проект путем создания о и отправки запроса (pull) или прислав patch-файлы по электронной почте. Информация об обоих способах и определении ответственного за поддержку каждой области кода приведена в разделе Submitting a Change to the Yocto Project [2].

16.3. Yocto Project Bugzilla

YP использует свою реализацию Bugzilla для отслеживания дефектов (ошибок). Реализация of Bugzilla удобна для групповой работы, поскольку отслеживаются ошибки и изменения кода, которые могут использоваться для обмена информацией между разработчиками, представления изменений, обзора исправлений и контроля качества.

Иногда полезно зафиксировать, исследовать или отследить ошибку в самом YP (например, при возникновении проблем с поведением системы сборки, не соответствующим документации или ожиданиям).

Существуют базовые процедуры и рекомендации по представлению ошибок в Bugzilla. Информацию о фиксации ошибок в YP можно найти:

Информация о системе Bugzilla в целом доступна по ссылке http://www.bugzilla.org/about/.

16.4. Списки рассылки

Имеется множество списков рассылки, поддерживаемых YP, а также списки OE для обсуждения, представления правок и анонсов. Подписаться на интересующую рассылку можно с помощью приведенных ниже ссылок.

Дополнительная информация о рассылках приведена на сайте Yocto Project.

16.5. Дополнительная информация

  • Сайт Yocto Project

  • Страница Yocto Project Wiki. Основная страница wiki для YP, содержащая сведения о планировании проекта, устройстве выпусков, контроле качества и автоматизации и т. п.

  • OpenEmbedded сборочная система YP, служащая основой для Poky.

  • BitBake инструмент для обработки метаданных.

  • Yocto Project Mega-Manualодин файл HTML, включающий все руководства YP. Удобен для контекстного поиска.

  • FAQответы на часто задаваемые вопросы.

  • Release Notes. Свойства, обновления и возможные проблемы для текущего выпуска YP. Документы Release Notes доступны на странице Downloads сайта YP по ссылке RELEASE INFORMATION для нужного выпуска.

  • Bugzillaсистема отслеживания ошибок в YP, позволяющая каждому сообщить о возникшей проблеме.

  • Bugzilla Configuration and Bug Tracking Wiki Page. Информация об установке и использовании YP Bugzilla для записи и отслеживания дефектов YP.

  • Internet Relay Chat (IRC). Два канала IRC для обсуждения YP (#yocto) и Poky (#poky).

  • Quick EMUlator (QEMU). Система эмуляции и виртуализации с открытым исходным кодом.

Литература

[1] Yocto Project Overview and Concepts Manual4, https://www.yoctoproject.org/docs/2.7.1/overview-manual/overview-manual.html.

[2] Yocto Project Development Tasks Manual, http://www.yoctoproject.org/docs/2.7.1/dev-manual/dev-manual.html.

[3] Yocto Project Linux Kernel Development Manual5, http://www.yoctoproject.org/docs/2.7.1/kernel-dev/kernel-dev.html.

[4] BitBake User Manual6, https://www.yoctoproject.org/docs/2.7.1/bitbake-user-manual/bitbake-user-manual.html.

[5] Yocto Project Quick Build, https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html.

[6] Yocto Project Board Support Package (BSP) Developer’s Guide, http://www.yoctoproject.org/docs/2.7.1/bsp-guide/bsp-guide.html.

[7] Yocto Project Application Development and the Extensible Software Development Kit (eSDK)7, http://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html.

[8] Toaster User Manual, https://www.yoctoproject.org/docs/2.7.1/toaster-manual/toaster-manual.html.

[9] Yocto Project Profiling and Tracing Manual, https://www.yoctoproject.org/docs/2.7.1/profile-manual/profile-manual.html.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1GNU Project Debugger — отладчик проекта GNU.

2System On Chip — система на кристалле.

3Secondary Program Loader — вторичный загрузчик программ.

4Доступен перевод документа на русский язык по ссылке.

5Доступен перевод документа на русский язык по ссылке.

6Доступен перевод документа на русский язык по ссылке.

7Доступен перевод документа на русский язык по ссылке.

Рубрика: Linux | Комментарии к записи Справочник по Yocto Project (часть 4) отключены

Справочник по Yocto Project (часть 3)

Часть 2


Глава 13. Переменные

В этой главе перечислены и описаны основные переменные, используемые системой сборки OE.

A

ABIEXTENSION

Расширение поля ABI1 канонического имени GNU для архитектуры (например, «eabi»). Расширения ABI задаются во включаемых файлах для машин. Например, файл meta/conf/machine/include/arm/arch-arm.inc задает расширение ABIEXTENSION = «eabi».

ALLOW_EMPTY

Задает необходимость создания на выходе пустых пакетов, которые BitBake по умолчанию не создает. Принятое по умолчанию поведение может создавать проблемы в тех случаях, когда RDEPENDS или другое жесткое требование во время работы указывает необходимость пакета.

Как и в других переменных управления пакетами требуется суффикс в виде имени пакета, как показано ниже.

     ALLOW_EMPTY_${PN} = "1"
     ALLOW_EMPTY_${PN}-dev = "1"
     ALLOW_EMPTY_${PN}-staticdev = "1"   

ALTERNATIVE

Перечисляет команды в пакете, которым нужна схема вариативного именования. Иногда одна команда предоставляется несколькими пакетами и в таких случаях системе сборки OE приходиться использовать систему вариантов для создания разных имен двоичных файлов, чтобы команды могли существовать совместно.

При использовании этой переменной указывается список команд пакета, которые применяются также в другом пакете, как показано ниже. Например, если пакет busybox имеет 4 таких команды, можно указать ALTERNATIVE_busybox = «sh sed test bracket». Дополнительная информация о вариантах именования приведена в параграфе 6.141. update-alternatives.bbclass.

ALTERNATIVE_LINK_NAME

Применяется системой вариантов (alternative) для отображения дублированных команд на реальные файлы. Например, если команда bracket, поддерживаемая пакетом busybox, дублируется в другом пакете, нужно использовать переменную ALTERNATIVE_LINK_NAME для указания реального местоположения файла.

     ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["

В этом примере двоичный файл команды bracket ([) из busybox размещается в /usr/bin/. Если переменная ALTERNATIVE_LINK_NAME не задана, используется ${bindir}/name. (см. 6.141. update-alternatives.bbclass).

ALTERNATIVE_PRIORITY

Применяется системой вариантов для установки приоритета дублированных команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (6.141. update-alternatives.bbclass). Варианты синтаксиса даны ниже.

ALTERNATIVE_PRIORITY = "priority" ALTERNATIVE_PRIORITY[name] = "priority" ALTERNATIVE_PRIORITY_pkg[name] = "priority"

ALTERNATIVE_TARGET

Применяется системой вариантов для создания используемого по умолчанию местоположения для дубликатов команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (6.141. update-alternatives.bbclass). Варианты синтаксиса даны ниже.

ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target" ALTERNATIVE_TARGET_pkg[name] = "target"

Если переменная ALTERNATIVE_TARGET не определена, наследуется значение из ALTERNATIVE_LINK_NAME.

При совпадении ALTERNATIVE_LINK_NAME и ALTERNATIVE_TARGET к цели для ALTERNATIVE_TARGET добавляется «.{BPN}«. Если указанный файл не переименован, система вариантов переименует его, чтобы избежать необходимости переименования вариантов в задаче do_install, сохраняя при необходимости поддержку команды.

APPEND

Переопределяет список добавленных строк для каждой цели, указанной с LABELS
спользование переменной рассмотрено в описании класса grub-efi).

AR

Сокращенная команда и аргументы для работы ar.

ARCHIVER_MODE

При использовании с классом archiver определяет тип информации, использованной для создания архива. Эту переменную можно использовать для создания архивов исправленных (patched) и оригинальных исходных кодов, настроенных кодов и т. п. С помощью описанных ниже флагов.

ARCHIVER_MODE[src] = «original»

Используются оригинальные (неупакованные) исходные файлы.

ARCHIVER_MODE[src] = «patched»

Используются исправленные (patched) исходные файлы (принято по умолчанию).

ARCHIVER_MODE[src] = «configured»

Используются настроенные исходные файлы.

ARCHIVER_MODE[diff] = «1»

Используются различия (patch) между do_unpack и do_patch.

ARCHIVER_MODE[diff-exclude] ?= «file file …»

Список файлов и каталогов для исключения из diff.

ARCHIVER_MODE[dumpdata] = «1»

Используются данные окружения.

ARCHIVER_MODE[recipe] = «1»

Используются файлы заданий и включаемые файлы.

ARCHIVER_MODE[srpm] = «1»

Используются файлы RPM.

Информация об использовании переменной приведена в файле meta/classes/archiver.bbclass дерева исходных кодов.

AS

Сокращенная команда и аргументы для работы ассемблера.

ASSUME_PROVIDED

Список имен заданий (PN values), которые BitBake не будет пытаться собрать, предполагая, что они уже собраны. В OpenEmbedded-Core переменная ASSUME_PROVIDED задает естественные инструменты, которые не нужно собирать. Примером служит задание git-native, его указание позволяет применять Git хоста без сборки git-native.

ASSUME_SHLIBS

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

Например, приведенная ниже форма добавляет провайдера shlib с именем shlibname в packagename с необязательным указанием версии.

shlibname:packagename[_version]

Следующий пример добавляет общую библиотеку libEGL.so.1 как предоставляемую пакетом libegl-implementation.

     ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"

AUTHOR

Почтовый адрес для контактов с исходным автором или авторами для передачи правок и сообщений об ошибках.

AUTO_LIBNAME_PKGS

При наследовании класса debian (принято по умолчанию) переменная задает пакеты, которые следует проверять на предмет библиотек и переименовывать в соответствии с правилами Debian. По умолчанию принято значение ${PACKAGES}, которое включает класс debian для всех пакетов, явно создаваемых заданием.

AUTO_SYSLINUXMENU

Включает создание автоматического меню для загрузчика syslinux. Переменная должна устанавливаться в задании, класс syslinux проверяет ее.

AUTOREV

Когда для переменной SRCREV установлено значение данной переменной, это задает использование последнего выпуска исходных кодов из репозитория. Если используется SRCREV = «${AUTOREV}» для поиска последней версии программы, нужно убедиться, что PV содержит ${SRCPV}. Предположим, что имеется задание для ядра, наследующее класс kernel и применяется приведенный выше оператор. В этом случае ${SRCPV} не попадет автоматически в PV
и
нужно изменить
PV в задании для включения ${SRCPV}.

Дополнительные сведения приведены в разделе Automatically Incrementing a Binary Package Revision Number [2].

AVAILTUNES

Список определенных настроек CPU и ABI, доступных для системы сборки OE. С конкретной конфигурацией машины могут быть совместимы не все настройки и могут возникать несовместимости с разными библиотеками в конфигурации Multilib. Настройки добавляются с использованием оператора BitBake += в конец списка через пробел (см. раздел Basic Syntax [4]).

B

B

Каталог внутри каталога сборки, куда система сборки OE помещает объекты, созданные в процессе сборки задания. По умолчанию этот каталог совпадает с каталогом S,
определяемым
как

     S = "${WORKDIR}/${BP}"

Можно разделить каталог S
и
каталог, указанный переменной
B. Большинство заданий, применяющих автоматические инструменты поддерживают такое разделение. По умолчанию система сборки использует отдельные каталоги для gcc и некоторых заданий для ядра.

BAD_RECOMMENDATIONS

Перечисляет «лишь рекомендуемые» (recommended-only) пакеты, которые не устанавливаются. К таким пакетам относятся указанные через переменную RRECOMMENDS. Можно предотвратить установку любого из таких пакетов, указав его в переменной BAD_RECOMMENDATIONS.

BAD_RECOMMENDATIONS = "package_name package_name package_name ..."

Эту переменную можно задать глобально в файле local.conf или присоединить к заданию для конкретного образа, используя переопределение имени задания, как показано ниже.

BAD_RECOMMENDATIONS_pn-target_image = "package_name"

Важно отметить, что при отказе от установки пакетов с помощью этой переменной и наличии зависимости от них других пакетов (указанных в переменной RDEPENDS для задания), система сборки OE будет игнорировать запрос и установит пакеты для предотвращения нарушений в зависимостях.

Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.

См. также описания переменных NO_RECOMMENDATIONS и PACKAGE_EXCLUDE.

BASE_LIB

Имя каталоги библиотек для настройки CPU или ABI, которое применяется лишь в контексте Multilib (см. раздел Combining Multiple Versions of Library Files into One Image [2]). Переменная определяется во включаемых файлах машины в дереве исходного кода. Если Multilib не используется, переменная имеет значение lib.

BASE_WORKDIR

Задает базу для сетевого каталога, применяемого во всех задания (по умолчанию ${TMPDIR}/work).

BB_ALLOWED_NETWORKS

Задает список разделенных пробелами хостов, которые сборщику разрешено использовать для получения нужных исходных кодов. Ниже рассмотрены некоторые аспекты использования этой переменной.

  • Список хостов применяется лишь в при установке BB_NO_NETWORK = «0» или не заданной переменной.
  • Ограниченно поддерживаются шаблоны для начальной части имени хоста. Например, приведенная ниже строка будет соответствовать git.gnu.org, ftp.gnu.org
    и
    foo.git.gnu.org.

         BB_ALLOWED_NETWORKS = "*.gnu.org"

    Символ *
    работает
    только в начальной части
    имени,
    отделенной точкой от остального имени
    и не допускается его использование в
    других местах. Например, можно указать
    *.foo.bar,
    но *aa.foo.bar не будет работать.

  • Зеркала, не указанные в списке хостов, будут пропускаться с указанием в отладочном выводе.
  • Попытка доступа в сети, не указанную в списке, завершится отказом.

Использование BB_ALLOWED_NETWORKS вместе с переменной PREMIRRORS
очень
полезно. Добавление хоста
в PREMIRRORS
позволяет
получать исходные коды с этого хоста и
предотвращает ошибки, возникающие когда
неразрешенный хост указан в
SRC_URI. Это связано с тем, что сборщик не пытается использовать хосты из SRC_URI после успешной выборки на основе PREMIRRORS.

BB_DANGLINGAPPENDS_WARNONLY

Определяет обработку в BitBake ситуаций, когда файл дополнения (.bbappend) не имеет соответствующего задания (.bb). Такое часто возникает при рассинхронизации уровней (например, oe-core нужно задания, для которого старой версии уже нет, а другой уровень еще не обновлен с новой версией задания). По умолчанию в такой ситуации возникает критическая ошибка и это обеспечивает наиболее безопасный вариант. Поведение можно изменить указав для переменной BB_DANGLINGAPPENDS_WARNONLY значение «1», «yes» или «true» в файле local.conf каталога сборки.

BB_DISKMON_DIRS

Отслеживает доступное пространство и inode при сборке, позволяя контроль по этим параметрам (по умолчанию отключен). Переменная задается в форме BB_DISKMON_DIRS = «<action>,<dir>,<threshold> […]», где

<action>

ABORT — незамедлительное прерывание сборки при превышении порога.

STOPTASKS — остановка сборки после завершения текущих задач в случае превышения порога.

WARN — вывод предупреждения и продолжение сборки. Последующие предупреждения выдаются в соответствии с переменной BB_DISKMON_WARNINTERVAL, которая должна быть определена.

<dir>

Любые каталоги для мониторинга, разделенные пробелами. Если каталоги расположены на одном устройстве, отслеживается лишь первый.

<threshold>

Минимальное пространство на диске или/и минимальное число inode. Можно применять суффиксы G (Гбайт), M (Мбайт), K (Кбайт, принято по умолчанию). Не следует использовать GB, MB или KB.

     BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
     BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
     BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"

Первый пример работает только при установке переменной BB_DISKMON_WARNINTERVAL и заставляет систему сборки немедленно прерывать процесс, если свободное пространство в ${TMPDIR} становится меньше 1 Гбайта или число inode ниже 100 Кбайт. Поскольку указаны 2 каталога, система сборки будет выдавать предупреждение при снижении свободного места в ${SSTATE_DIR} меньше 1 Гбайт или inode меньше 100 Кбайт. Следующие предупреждения будут выдаваться с интервалами, заданными BB_DISKMON_WARNINTERVAL.

Второй пример будет останавливать сборку по завершении задач, когда свободное место в ${TMPDIR} станет меньше 1 Гбайт. Число inode не отслеживается.

Третий пример задает немедленное прерывание сборки при числе свободных inode в ${TMPDIR} меньше 100 Кбайт без отслеживания свободного места в каталоге.

BB_DISKMON_WARNINTERVAL

Задает интервал предупреждений о нехватке места на диске и свободных inode. Для использования переменной нужно задать BB_DISKMON_DIRS с действием WARN. В процессе сборки при снижении свободного места будут выдаваться предупреждения с заданным интервалом. Если при установке BB_DISKMON_DIRS = «WARN» интервал не указан, используется BB_DISKMON_WARNINTERVAL = «50M,5K». При задании переменной в файле конфигурации применяется форма BB_DISKMON_WARNINTERVAL = «<disk_space_interval>,<disk_inode_interval>».

<disk_space_interval>

Интервал свободного пространства в G (Гбайт), M (Мбайт) или K (Кбайт). Не используйте GB, MB или KB.

<disk_inode_interval>

Интервал свободных inode в G (Гбайт), M (Мбайт) или K (Кбайт). Не используйте GB, MB или KB.

     BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
     BB_DISKMON_WARNINTERVAL = "50M,5K"

Эти переменные заставляют BitBake выдавать предупреждения каждый раз, когда свободное место в каталоге ${SSTATE_DIR}
снижается на
50 Мбайт или число свободных inode — на 5 Кбайт. Предупреждения будут выдаваться после того, как свободное место станет меньше 1 Гбайт или число свободных inode — меньше 100 Кбайт.

BB_GENERATE_MIRROR_TARBALLS

Заставляет систему сборки размещать архивы репозиториев исходного кода (например, Git), включая метаданные, в каталоге DL_DIR. Для повышения производительности система сборки OE п умолчанию не сохраняет такие архивы.

Переменная устанавливается в файле local.conf каталога сборки.

BB_NUMBER_THREADS

Максимальное число задач, которые BitBake следует запускать параллельно. Система сборки OE автоматически устанавливает для этой переменной число ядре на хосте сборки. Например, в системе с 2-ядерным процессором и поддержкой hyper-threading по умолчанию задается BB_NUMBER_THREADS = «4». Для 1-процессорных систем не следует переопределять эту переменную. Оптимизация скорости сборки описана в Speeding Up a Build [2].

BB_SERVER_TIMEOUT

Указывает время (в секундах), по истечение которого сервер BitBake выключается при отсутствии активности. Например, в файле local.conf можно указать 20-секундное ожидание в виде BB_SERVER_TIMEOUT = «20». Для постоянной работы сервера следует установить BB_SERVER_TIMEOUT = «-1».

BBCLASSEXTEND

Позволяет расширить задание для сборки вариантов программ. Существуют распространенные варианты заданий, такие как «естественные» (например, quilt-native, копирующее Quilt для работы на системе сборки), «кросс-» (например, gcc-cross для создания на сборочной машине программ для работы на целевой платформе MACHINE), nativesdk для машины SDK вместо MACHINE и mulitlib в форме multilib:multilib_name. Для сборки разных вариантов задания с минимальным количеством кода обычно просто добавляются в задание приведенные ниже строки.

BBCLASSEXTEND =+ "native nativesdk"
     BBCLASSEXTEND =+ "multilib:multilib_name"

Механизм BBCLASSEXTEND создает варианты задания, переписывая значения переменных и применяя переопределения, такие как _class-native. Например, для создания естественного (native) варианта задания переменная DEPENDS в задании foo переписывает как DEPENDS для foo-native.

Даже при использовании BBCLASSEXTEND
задание
анализируется однократно
, что вносит некоторые ограничения. Например, невозможно включить разные файлы в зависимости от варианта, поскольку оператор include обрабатывается в процессе разбора задания.

BBFILE_COLLECTIONS

Список имен настроенных уровней, используемых для поиска других переменных BBFILE_*. Обычно каждый уровень добавляет свое имя в конце этой переменной в своем файле conf/layer.conf.

BBFILE_PATTERN

Переменная, которая преобразуется для сопоставления с файлами из переменной BBFILES в определенном слое. Эта переменная используется в файле conf/layer.conf и должна иметь суффикс с именем конкретного слоя (например, BBFILE_PATTERN_emenlow).

BBFILE_PRIORITY

Задает уровень приоритета для файлов заданий уровня. Эта переменная полезна в случаях, когда одноименные задания указаны в разных уровнях. Установка переменной позволяет задать приоритет заданий своего уровня, позволяя сделать его предпочтительным по сравнению с другими. Предпочтения, задаваемые этой переменной взаимодействуют с версиями заданий (переменная PV). Например, уровень, имеющий задание с более высоким значением PV, может иметь меньшее значение BBFILE_PRIORITY и быть менее предпочтительным.

Большее значение BBFILE_PRIORITY означает более высокий приоритет. Если переменная не задана, ее значение устанавливается на основе зависимостей уровня (см. LAYERDEPENDS). Если уровень не имеет зависимостей и приоритет не задан, определяется минимальным заданным приоритетом + 1 (т. е. 1, если приоритет не задан).

С помощью команды bitbake-layers show-layers можно посмотреть все настроенные уровни с их приоритетами.

BBFILES

Разделенный пробелами список файлов заданий, который BitBake использует для сборки программ. При указании файлов заданий можно применять синтаксис Python glob.

BBFILES_DYNAMIC

Активирует содержимое при наличии идентифицированных уровней, которые задаются коллекциями, определенными в них. Переменная используется для исключения файлов .bbappend, для которых соответствующие файлы .bb размещены на уровне, пытающемся изменить другие уровни, но не желающем задавать жесткую зависимость от этих уровней. Переменная BBFILES_DYNAMIC задается в форме collection_name:filename_pattern. Пример указывает имена двух коллекций и два шаблона имен файлов.

     BBFILES_DYNAMIC += " \
         clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
         core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
     "

Другой пример показывает сообщение об ошибке при обнаружении непригодной записи и разбор прерывается.

 ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
         /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
         /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend

BBINCLUDELOGS

Управляет отображением журнала сборки программой BitBake при возникновении отказов.

BBINCLUDELOGS_LINES

При установленной переменной BBINCLUDELOGS задает максимальное число строк из журнала задачи для отображения в случаях отказа. По умолчанию журнал выводится целиком.

BBLAYERS

Список уровней, включаемых в сборку. Переменная указывается в файле bblayers.conf каталога сборки. Например,

     BBLAYERS = " \
       /home/scottrif/poky/meta \
       /home/scottrif/poky/meta-poky \
       /home/scottrif/poky/meta-yocto-bsp \
       /home/scottrif/poky/meta-mykernel \
       "

Здесь включены 4 уровня, один из которых (meta-mykernel)
является пользовательским
.

BBMASK

Управляет исключением файлов заданий и дополнений из обработки BitBake, «пряча» ненужные файлы. BitBake игнорирует задания и дополнения, соответствующие выражениям маски. Значение переменной передается компилятору регулярных выражений Python, в маске применяется синтаксис Python Regular Expression (re). Сравнение выполняется для полных путей к файлам. Приведенный ниже пример обеспечивает игнорирование BitBake всех заданий и дополнений в каталоге meta-ti/recipes-misc/.

     BBMASK = "meta-ti/recipes-misc/"

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

     BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
     BBMASK += "/meta-oe/recipes-support/"
     BBMASK += "/meta-foo/.*/openldap"
     BBMASK += "opencv.*\.bbappend"
     BBMASK += "lzma"

Для исключения каталога следует указывать символ / в конце имени.

BBMULTICONFIG

Позволяет BitBake выполнить сборку со множеством конфигураций и указывает каждую конфигурацию (multiconfig). С помощью этой переменной можно задать BitBake сборку нескольких целей, каждая из которых имеет свою конфигурацию. Переменная задается в файле conf/local.conf,
например,
BBMULTIFONFIG = «configA configB configC». Каждый конфигурационный файл должен размещаться в каталоге сборки внутри каталога conf/multiconfig (например, build_directory/conf/multiconfig/configA.conf). Использование переменной в среде с поддержкой сборки нескольких конфигураций описано в разделе Building Images for Multiple Targets Using Multiple Configurations [2].

BBPATH

Применяется BitBake для поиска файлов .bbclass и файлов конфигурации подобно системной переменной PATH.

При использовании BitBake извне каталога сборки нужно обеспечить, чтобы переменная BBPATH указывала сборочный каталог. Установка выполняется так же, как для других переменных среды и переменная должна быть задана до начала работы BitBake.

$ BBPATH = "build_directory" $ export BBPATH $ bitbake target

BBSERVER

При определении в среде BitBake переменная BBSERVER указывает удаленный сервер BitBake. Переменная экспортируется в среду BitBake как показано ниже.

     export BBSERVER=localhost:$port"

По умолчанию BBSERVER присутствует также в BB_HASHBASE_WHITELIST,
поэтому
переменная
BBSERVER исключена из расчета контрольной суммы и данных зависимостей.

BINCONFIG

При наследовании класса binconfig-disabled эта переменная указывает двоичные сценарии настройки, которые следует отключить в пользу запроса информации с помощью pkg-config. Класс binconfig-disabled будет изменять указанные сценарии для возврата ошибки, позволяющего найти и заменить вызовы таких сценариев. При добавлении нескольких сценариев они разделяются пробелами, как показано ниже для задания libpng.

     BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"

BINCONFIG_GLOB

При наследовании класса binconfig эта переменная задает шаблон для сценариев конфигурации, которые нужно редактировать. При редактировании изменяются пути, заданные во время компиляции, чтобы они были пригодны для установки в sysroot и могли использоваться процессами сборки других заданий. Переменная использует шаблоны оболочки при сопоставлении имен, похожие на fnmatch и glob. Информацию о работе переменной можно найти в файле meta/classes/binconfig.bbclass дерева исходных кодов, а также в параграфе 6.7. binconfig.bbclass.

BP

Базовое имя и версия задания без дополнительных суффиксов (-native, lib64-
и
т. п.).
BP имеет вид ${BPN}-${PV}.

BPN

Это вариант переменной PN с удаленными общими префиксами и суффиксами, такими как nativesdk-, -cross, -native, а также lib64- и lib32-. Точный список удаляемых префиксов и суффиксов задается переменными MLPREFIX и SPECIAL_PKGSUFFIX.

BUGTRACKER

Задает идентификатор URL сайта отслеживания ошибок для задания. Система сборки OE не использует эту переменную, она служит лишь указателем для разработчиков в случае необходимости сообщить об ошибке.

BUILD_ARCH

Указывает архитектуру хоста сборки (например, i686). Система сборки OE устанавливает переменную по выводу команды uname.

BUILD_AS_ARCH

Задает зависящие от архитектуры флаги ассемблера для хоста сборки (по умолчанию «»).

BUILD_CC_ARCH

Задает зависящие от архитектуры флаги компилятора C для хоста сборки (по умолчанию «»).

BUILD_CCLD

Задает команду компоновки, используемую хостом сборки в случае применения для компоновки компилятора C. По умолчанию BUILD_CCLD указывает GCC и передает в качестве аргумента значение BUILD_CC_ARCH.

BUILD_CFLAGS

Задает флаги, передаваемые компилятору C при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение CFLAGS.

BUILD_CPPFLAGS

Задает флаги, передаваемые препроцессору C (т. е. компиляторам C и C++). При сборке в контексте -native по умолчанию используется значение CPPFLAGS.

BUILD_CXXFLAGS

Задает флаги, передаваемые компилятору C++ при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение CXXFLAGS.

BUILD_FC

Задает флаги, передаваемые компилятору Fortran для хоста сборки. По умолчанию переменная указывает Gfortran и передает значение BUILD_CC_ARCH.

BUILD_LD

Задает флаги команду компоновщика для хоста сборки. По умолчанию переменная указывает компоновщик GNU (ld) и передает значение BUILD_LD_ARCH.

BUILD_LD_ARCH

Задает зависящие от архитектуры флаги компоновщика для хоста сборки (по умолчанию «»).

BUILD_LDFLAGS

Задает флаги, передаваемые компоновщику при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение LDFLAGS.

BUILD_OPTIMIZATION

Задает флаги оптимизации, передаваемые компилятору C при сборке для сборочного хоста или SDK через заданные по умолчанию значения переменных BUILD_CFLAGS и BUILDSDK_CFLAGS. По умолчанию переменная BUILD_OPTIMIZATION имеет значение -O2 -pipe.

BUILD_OS

Указывает операционную систему сборочного хоста (например, linux). Система сборки OE устанавливает переменную по первому слову вывода команды uname, преобразованному в нижний регистр.

BUILD_PREFIX

Префикс двоичного файла инструментария для естественных заданий. Система сборки OE использует значение переменной TARGET_PREFIX при сборке естественных заданий.

BUILD_STRIP

Указывает команду для вырезания отладочных символов из файлов, созданных для сборочного хоста (по умолчанию ${BUILD_PREFIX}strip).

BUILD_SYS

Задает систему (включая архитектуру и ОС), используемую при сборке для сборочного хоста (задания native). Система сборки OE автоматически назначает эту переменную на основе значений BUILD_ARCH, BUILD_VENDOR и BUILD_OS то значение не требуется менять).

BUILD_VENDOR

Задает имя производителя для использования при сборке для сборочного хоста (по умолчанию «»).

BUILDDIR

Указывает местоположение каталога сборки, который можно задать опосредованно через сценарий oe-init-build-env, указав путь в команде запуска сценария. Если сценарий запущен без указания каталога сборки, по умолчанию BUILDDIR будет применять текущий каталог.

BUILDHISTORY_COMMIT

При наследовании класса buildhistory управляет фиксацией вывода истории сборки в локальном репозитории Git. При значении 1 этот локальный репозиторий будет поддерживаться автоматически классом buildhistory с фиксацией при каждой сборке изменений в каждом каталоге верхнего уровня вывода истории сборки (images, packages, sdk). Это позволяет отслеживать историю сборки. По умолчанию класс buildhistory не фиксирует вывод истории сборки в локальном репозитории Git, т. е. BUILDHISTORY_COMMIT ?= «0».

BUILDHISTORY_COMMIT_AUTHOR

При наследовании класса buildhistory
указывает
автора для каждой фиксации
Git. Чтобы переменная работала, нужно установить BUILDHISTORY_COMMIT = «1». Git требует в переменной BUILDHISTORY_COMMIT_AUTHOR
значение
в формате
email@host. Использование недействительного адреса или хоста не ведет к ошибке. По умолчанию класс buildhistory задает BUILDHISTORY_COMMIT_AUTHOR ?= «buildhistory <buildhistory@${DISTRO}>»

BUILDHISTORY_DIR

При наследовании класса buildhistory эта переменная задает каталог для хранения данных истории сборки. По умолчанию устанавливается BUILDHISTORY_DIR ?= «${TOPDIR}/buildhistory».

BUILDHISTORY_FEATURES

При наследовании класса buildhistory эта переменная задает включенные функции истории сборки (см. Maintaining Build Output Quality [2]). Свойства указываются в форме разделенного пробелами списка элементов:

  • imageанализ содержимого образов, включая список установленных пакетов;
  • packageанализ содержимого отдельных пакетов;
  • sdkанализ содержимого SDK;
  • taskсохранение подписей выходных файлов задач sstate (по одному файлу на задачу с контрольной суммой SHA-256 для каждого подготовленного файла).

По умолчанию класс buildhistory устанавливает BUILDHISTORY_FEATURES ?= «image package sdk».

BUILDHISTORY_IMAGE_FILES

При наследовании класса buildhistory переменная задает список путей к файлам, копируемым из образа в каталог истории сборки каталога image-files в каталоге для образа, чтобы можно было отследить содержимое каждого файла. По умолчанию копируются /etc/passwd и /etc/group, что позволяет контролировать изменения пользователей и групп. Можно включить в список любой файл. Задание некорректного пути в переменной не ведет к ошибке, поэтому можно указать даже не всегда присутствующие файлы. По умолчанию класс buildhistory устанавливает BUILDHISTORY_IMAGE_FILES ?= «/etc/passwd /etc/group».

BUILDHISTORY_PUSH_REPO

При наследовании класса buildhistory переменная может задавать удаленный репозиторий, в который история сборки выталкивает (push) изменения Git. Для работы переменной BUILDHISTORY_PUSH_REPO нужно установить BUILDHISTORY_COMMIT = «1». Репозиторий должен соответствовать заданному удаленному адресу, понятному Git, или удаленному имени, установленному вручную с использованием git
remote
в локальном репозитории. По умолчанию класс buildhistory устанавливает BUILDHISTORY_PUSH_REPO ?= «».

BUILDSDK_CFLAGS

Указывает флаги для передачи компилятору C при сборке для SDK. При сборке в контексте nativesdk- переменная CFLAGS получает значение этой переменной по умолчанию.

BUILDSDK_CPPFLAGS

Указывает флаги для передачи препроцессору C (для компиляторов C и C++) при сборке для SDK. При сборке в контексте nativesdk- переменная CPPFLAGS
получает
значение этой переменной по умолчанию
.

BUILDSDK_CXXFLAGS

Указывает флаги для передачи компилятору C++ при сборке для SDK. При сборке в контексте nativesdk- переменная CXXFLAGS получает значение этой переменной по умолчанию.

BUILDSDK_LDFLAGS

Указывает флаги для передачи компоновщику при сборке для SDK. При сборке в контексте nativesdk- переменная LDFLAGS получает значение этой переменной по умолчанию.

BUILDSTATS_BASE

Указывает местоположение каталога со статистикой сборки при включенном и используемом классе buildstats. По умолчанию BUILDSTATS_BASE имеет значение ${TMPDIR}/buildstats/.

BUSYBOX_SPLIT_SUID

Управляет для задания BusyBox расщеплением выходного файла на 2 части, одна из который выполняет функции, требующие setuid
root
, а другая делает все остальное (где не требуется setuid
root
).

BUSYBOX_SPLIT_SUID по умолчанию имеет значение 1, обеспечивающее на выходе два исполняемых файла. Установка значения 0 отменяет расщепление выходного файла.

C

CACHE

Задает каталог, используемый BitBake для хранения кэшированных метаданных чтобы не анализировать их при каждом запуске BitBake.

CC

Сокращенная команда и аргументы для запуска компилятора C.

CFLAGS

Задает флаги для передачи компилятору C. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CFLAGS зависит от собираемого объекта:

  • TARGET_CFLAGS при сборке для целевой платформы;
  • BUILD_CFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CFLAGS при сборке для SDK (nativesdk-).

CLASSOVERRIDE

Внутренняя переменная, задающая переопределение класса, который следует применять (например, class-target, class-native и т. п.). Классы, использующие эту переменную (например, native, nativesdk и т. п.), устанавливают подходящее значение. Переменная CLASSOVERRIDE получает используемое по умолчанию значение class-target из файла bitbake.conf.

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

     do_install_append_class-target() {
         install my-extra-file ${D}${sysconfdir}
     }

Ниже приведен пример, где переменная FOO получает значение native при сборке для сборочного хоста и other — остальных случаях

     FOO_class-native = "native"
     FOO = "other"

Базовым механизмом использования CLASSOVERRIDE является просто включение в принятое по умолчанию значение OVERRIDES.

CLEANBROKEN

При установке в задании значения 1 для этой переменной команда make clean не будет работать для собираемой программы, поэтому система сборки OE не будет пытаться запустить ее при выполнении задачи do_configure.

COMBINED_FEATURES

Указывает список аппаратных свойств, включенных в MACHINE_FEATURES и DISTRO_FEATURES. Это определяет список свойств, которыми имеет смысл управлять на уровне конфигурации машины и дистрибутива. Например, свойство bluetooth требует аппаратной поддержки, но является также опцией дистрибутива.

COMMON_LICENSE_DIR

Указывает каталог meta/files/common-licenses в дереве исходных кодов, где хранятся файлы базовых лицензий.

COMPATIBLE_HOST

Регулярное выражение, указывающее один или несколько хостов (естественное задание) или целей (неестественное задание), с которыми задание совместимо. Выражение сопоставляется с HOST_SYS. Переменную можно использовать для предотвращения сборки заданий для несовместимых классов систем. Особенно полезно это при сборке ядер. Переменная также помогает ускорить синтаксический анализ, поскольку система сборки будет пропускать несовместимые задания.

COMPATIBLE_MACHINE

Регулярное выражение, указывающее одну или несколько целевых машин, совместимых с заданием. Выражение сравнивается с MACHINEOVERRIDES. Можно использовать эту переменню для предотвращения сборки кода для машин, которые не совместимы с заданием. Особенно полезно это при сборке ядер. Переменная также помогает повысить скорость анализа, поскольку система сборки будет пропускать несовместимые с машиной задания.

COMPLEMENTARY_GLOB

Задает шаблоны сопоставления при установке списка дополнительных пакетов для всех пакетов, явно или неявно включенных в образ. Переменная использует шаблоны соответствия имен Unix (fnmatch), похожие на шаблоны преобразования путей Unix (glob).

Результирующий список пакетов связан с элементом, который может быть добавлен в IMAGE_FEATURES.Примером может служить элемент dev-pkgs при добавлении которого в IMAGE_FEATURES будут устанавливаться пакеты -dev (заголовки и другие файлы для разработки) для каждого пакета в образе.

Для добавления указанного шаблоном свойства служит флаг переменной и значение шаблона, например, COMPLEMENTARY_GLOB[dev-pkgs] = ‘*-dev’.

COMPONENTS_DIR

Сохраняет компоненты sysroot для каждого задания. Система сборки OE использует переменную при создании зависимых от задания каталогов sysroot для других заданий. По умолчанию установлено «${STAGING_DIR}-components» (т. е. «${TMPDIR}/sysroots-components«).

CONF_VERSION

Отслеживает версию файла local.conf. Значение увеличивается при каждом изменении совместимости build/conf/.

CONFFILES

Указывает редактируемые или настраиваемые файлы в пакете. Если система PMS2 применяется для управления пакетами на целевой платформе, возможна замена конфигурационных файлов после установки пакета, что может быть нежелательно. Иными словами, в пакете могут быть редактируемые файлы, которые не следует менять при обновлении пакета. Переменная CONFFILES позволяет указать эти файлы и PMS не будет обновлять их.

Для использования переменной CONFFILES имя пакета переопределяется в указанием результирующего пакета. Затем указывается список разделенных пробелами файлов, например, CONFFILES_${PN} += «${sysconfdir}/file1 ${sysconfdir}/file2 ${sysconfdir}/file3»

Переменные CONFFILES и FILES связаны между собой и файлы из CONFFILES должны быть подмножеством файлов из FILES,
поскольку
они являются частью пакета
.

При указании путей в переменной CONFFILES хорошим тоном является использование подходящих переменных. Например, следует указывать ${sysconfdir} вместо /etc
или
${bindir} вместо /usr/bin. Список этих переменных приведен в начале файла meta/conf/bitbake.conf в дереве исходных кодов.

CONFIG_INITRAMFS_SOURCE

Задает файлы для initramfs. Система сборки OE получает и использует эту переменную ядра Kconfig, как переменную окружения, которая по умолчанию имеет пустое значение («»).

CONFIG_INITRAMFS_SOURCE может указывать один архив cpio (.cpio)
или список разделенных пробелами
каталогов и файлов для сборки образа
initramfs. Файл cpio должен включать архив файловой системы для использования в качестве образа initramfs. Каталоги должны включать схему файловой системы для включения в образ initramfs, а файлы — записи в соответствии с форматом, описанным программой usr/gen_init_cpio в дереве ядра.

Если задано множество каталогов и файлов, образ initramfs будет включать из. Информация о создании initramfs приведена в разделе Building an Initial RAM Filesystem (initramfs) Image [2].

CONFIG_SITE

Список файлов, содержащих результаты теста autoconf,
относящиеся
к текущей сборке. Переменная используется
утилитами
Autotools при настройке конфигурации (configure).

CONFIGURE_FLAGS

Минимальные аргументы для GNU configure.

CONFLICT_DISTRO_FEATURES

При наследовании класса distro_features_check эта переменная указывает свойства дистрибутива, которые будут вызывать конфликты при сборке образа. Иными словами, при включении свойства в CONFLICT_DISTRO_FEATURES и DISTRO_FEATURES в одной конфигурации будет возникать ошибка.

COPYLEFT_LICENSE_EXCLUDE

Список разделенных пробелами лицензий для исключения источников, архивируемых классом archiver.
Если
лицензия из переменной
LICENSE включена в COPYLEFT_LICENSE_EXCLUDE,
ее
источник не будет архивироваться
.
Переменная
имеет более высокий приоритет по
сравнению с
COPYLEFT_LICENSE_INCLUDE.

Принятое по умолчанию значение «CLOSED Proprietary» устанавливается классом copyleft_filter, который наследуется классом archiver.

COPYLEFT_LICENSE_INCLUDE

Список разделенных пробелами лицензий для включения источников, архивируемых классом archiver. Если лицензия из переменной LICENSE включена в COPYLEFT_LICENSE_INCLUDE, ее источник будет архивироваться. Принятое по умолчанию значение задается классом copyleft_filter, наследуемым классом archiver,
и содержит GPL*, LGPL* и AGPL*.

COPYLEFT_PN_EXCLUDE

Список заданий для исключения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение «» указывает отсутствие явного исключения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.

COPYLEFT_PN_INCLUDE

Список заданий для включения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение «» указывает отсутствие явного включения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.

COPYLEFT_RECIPE_TYPES

Список разделенных пробелами типов заданий для включения в архив исходных кодов, создаваемый классом archiver. Задания могут иметь тип target, native, nativesdk, cross, crosssdk
и
cross-canadian. По умолчанию применяется тип target* и для COPYLEFT_RECIPE_TYPES оно устанавливается классом copyleft_filter,
который
наследуется классом
archiver.

COPY_LIC_DIRS

При установке значения 1 для этой переменной и COPY_LIC_MANIFEST система сборки OE копирует в образ файлы лицензий из каталога /usr/share/common-licenses
для
каждого пакета
. Файлы лицензий помещаются в образ при его сборке.

COPY_LIC_DIRS не предлагает путь добавления лицензий для вновь устанавливаемых пакетов в образах с файловой системой read-only, которая не разрешает запись (см. описание LICENSE_CREATE_PACKAGE).
Дополнительная информация о предоставлении
текстов лицензий приведена в разделе
Providing License Text [2].

COPY_LIC_MANIFEST

При установке значения 1 система сборки OE копирует манифест лицензии в файл образа /usr/share/common-licenses/license.manifest в процессе сборки.

COPY_LIC_MANIFEST не предлагает для вновь устанавливаемых в образ пакетов путь добавления лицензий, который может лучше подходить для файловых систем без возможности записи read-only), не позволяющих вносить изменения (см. описание переменной LICENSE_CREATE_PACKAGE).
Сведения о предоставлении текстов
лицензий приведены также в разделе
Providing License Text [2].

CORE_IMAGE_EXTRA_INSTALL

Задает список пакетов для добавления в образ. Переменную следует включать лишь в файл local.conf каталога сборки. Эта переменная заменила ранее применявшуюся переменную POKY_EXTRA_INSTALL.

COREBASE

Задает родительский каталог уровня метаданных OpenEmbedded-Core (meta).

COREBASE_FILES

Список файлов из каталога COREBASE,
которые
следует скопировать, если они не относятся
к уровням, указанным в
bblayers.conf. Переменная предназначена для копирования метаданных из системы сборки OE в расширяемый SDK. Явное указание копируемых файлов из COREBASE требуется потому, что этот каталог обычно содержит каталоги сборки и другие файлы, которые не нужны в eSDK.

CPP

Сокращенная команда и аргументы для запуска препроцессора C.

CPPFLAGS

Задает флаги для передачи препроцессору C (для компиляторов C и C++). Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CPPFLAGS зависит от собираемого объекта:

  • TARGET_CPPFLAGS при сборке для целевой платформы;
  • BUILD_CPPFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CPPFLAGS при сборке для SDK (nativesdk-).

CROSS_COMPILE

Префикс двоичных файлов инструментария для целевой платформы (совпадает со значением TARGET_PREFIX). Система сборки OE устанавливает CROSS_COMPILE
лишь в определенном контексте (например, при сборке заданий для ядра или модулей ядра).

CVSDIR

Каталог для хранения файлов, выбранных в системе CVS.

CXX

Сокращенная команда и аргументы для запуска компилятора C++.

CXXFLAGS

Задает флаги для передачи компилятору C++. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CXXFLAGS зависит от собираемого объекта:

  • TARGET_CXXFLAGS при сборке для целевой платформы;
  • BUILD_CXXFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CXXFLAGS при сборке для SDK (nativesdk-).

D

D

Каталог назначения в каталоге сборки, куда устанавливаются компоненты задачей do_install
(по умолчанию ${WORKDIR}/image). Задачи, читающие каталог или записывающие в него, следует запускать в fakeroot [1].

DATE

Дата начала сборки в формате YMD (например, 20150209 для 9 февраля 2015 г.).

DATETIME

Дата и время начала текущей сборки в формате, пригодном для временных меток.

DEBIAN_NOAUTONAME

При
наследовании класса
debian
(принято
по умолчанию) переменная задает отмену
переименования библиотек в стиле
Debian для отдельного пакета. При установке переменной должно применяться имя пакета, например, DEBIAN_NOAUTONAME_fontconfig-utils = «1».

DEBIANNAME

При наследовании класса debian (принято по умолчанию) переменная позволяет переопределить имя библиотеки для отдельного пакета. Такое переопределение происходит редко и при установке переменной должно применяться имя пакета, например, DEBIANNAME_${PN} = «dbus-1».

DEBUG_BUILD

Задает сборку пакетов с отладочной информацией. Это влияет на значение SELECTED_OPTIMIZATION.

DEBUG_OPTIMIZATION

Опции для передачи в TARGET_CFLAGS и CFLAGS при компиляции системы с отладкой. По умолчанию переменная имеет значение -O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe.

DEFAULT_PREFERENCE

Задает незначительное смещение при выборе приоритета для задания. Чаще всего для переменной устанавливают значение -1 в заданиях для development-версий программ. Это ведет к сборке по умолчанию стабильной версии задания при отсутствии PREFERRED_VERSION. Смещение от DEFAULT_PREFERENCE невелико и часто переопределяется BBFILE_PRIORITY,
если
эта переменная различается в двух
уровнях, содержащих разные версии одного
задания
.

DEFAULTTUNE

Используемые по умолчанию настройки CPU и ABI для системы сборки OE. Переменная DEFAULTTUNE помогает определить TUNE_FEATURES. Принятые по умолчанию настройки явно или неявно задаются машиной (MACHINE), однако их можно переопределить с помощью значений переменной AVAILTUNES.

DEPENDS

Список зависимостей при сборке задания. Это зависимости от других заданий (например, заголовков и общих библиотек). Например, задание foo может включать зависимость DEPENDS = «bar». Это означает, что все файлы, установленные заданием bar, будут доступны в подходящей промежуточной системе sysroot, указанной переменными STAGING_DIR*, при выполнении задачи do_configure для foo. Этот механизм реализуется за счет зависимости do_configure от do_populate_sysroot для каждого задания, указанного в DEPENDS, через объявление [deptask] в классе base.

Иногда нужно явно указать, например, STAGING_DIR_HOST. Стандартные классы и связанные со сборкой переменные настраиваются для автоматического использования подходящей промежуточной системы sysroot.

Другим примером может служить применение DEPENDS для добавления утилит, работающих на сборочном хосте в процессе сборки. Например, задание codegen может включать DEPENDS = «codegen-native».

Дополнительная информация приведена в описании класса native class и переменной EXTRANATIVEPATH.

  • DEPENDS содержит список имен заданий, точнее — список имен PROVIDES, обычно совпадающих с именами заданий. Включение в DEPENDS имен пакетов, таких как foo-dev, не имеет смысла. Вместо этого следует указать foo, поскольку это приведет к включению всех пакетов, составляющих foo, включая foo-dev.
  • Задание, указывающее в DEPENDS другое задание, само по себе не добавляет зависимость между этими заданиями при работе. Однако, как указано в разделе Automatically Added Runtime Dependencies [1], зависимости при работе часто добавляются автоматически, поэтому для большинства заданий достаточно указать DEPENDS.
  • DEPENDS зачастую требуется даже для заданий, устанавливающих ранее собранные компоненты. Например, если libfoo является ранее скомпилированной библиотекой, которая связана с libbar, тогда привязка к libfoo
    требует наличия libfoo и libbar в sysroot. Без зависимости от libbar в переменной DEPENDS задания, устанавливающего libfoo, другие задания не смогут ссылаться на libfoo.

Информация о зависимостях при работе приведена в описании переменной RDEPENDS, а также в разделах Tasks и Dependencies [4].

DEPLOY_DIR

Указывает базовую область, куда система сборки OE помещает образы, пакеты, SDK и другие выходные файлы, предназначенные для внешнего использования. По умолчанию этот каталог размещается в каталоге сборки как ${TMPDIR}/deploy. Структура каталога сборки описана в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания рассмотрено в разделах Images, Package Feeds, и Application Development SDK [1].

DEPLOY_DIR_DEB

Указывает область, используемую системой сборки OE для размещения пакетов Debian, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_deb. Конфигурационный файл BitBake изначально определяет DEPLOY_DIR_DEB как каталог DEPLOY_DIR_DEB = «${DEPLOY_DIR}/deb»

Класс package_deb использует DEPLOY_DIR_DEB для обеспечения записи задачей do_package_write_deb пакетов Debian в корректный каталог (см. раздел Package Feeds [1]).

DEPLOY_DIR_IMAGE

Указывает область, используемую системой сборки OE для размещения и связанных с ними файлов, готовых для развертывания вне системы сборки. Переменная является машинозависимой, поскольку содержит ${MACHINE}. По умолчанию этот каталог размещается в каталоге сборки как ${DEPLOY_DIR}/images/${MACHINE}/.

Информация о структуре каталога сборки приведена в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания описано в разделах Images и Application Development SDK [1].

DEPLOY_DIR_IPK

Указывает область, используемую системой сборки OE для размещения пакетов IPK, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_ipk. Конфигурационный файл BitBake изначально определяет эту переменную как DEPLOY_DIR_IPK = «${DEPLOY_DIR}/ipk»

Класс package_ipk использует DEPLOY_DIR_IPK для обеспечения записи задачей do_package_write_ipk пакетов IPK в корректный каталог (см. раздел Package Feeds [1]).

DEPLOY_DIR_RPM

Указывает область, используемую системой сборки OE для размещения пакетов RPM, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_rpm. Конфигурационный файл BitBake изначально определяет эту переменную как DEPLOY_DIR_RPM = «${DEPLOY_DIR}/rpm»

Класс package_rpm использует DEPLOY_DIR_RPM для обеспечения записи задачей do_package_write_rpm t пакетов RPM в корректный каталог (см. раздел Package Feeds [1]).

DEPLOY_DIR_TAR

Указывает область, которую система сборки OE использует для размещения архивов, готовых для внешнего использования. Переменная применяется при наличии в переменной PACKAGE_CLASSES строки package_tar. Конфигурационный файл BitBake изначально определяет эту переменную как подкаталог в DEPLOY_DIR
-
DEPLOY_DIR_TAR = «${DEPLOY_DIR}/tar». Класс package_tar использует переменную DEPLOY_DIR_TAR для гарантии того, что задача do_package_write_tar
будет
записывать пакеты
TAR в подходящий каталог. Дополнительная информация о процессе упаковки приведена в разделе Package Feeds [1].

DEPLOYDIR

При наследовании класса deploy эта переменная указывает временную рабочую область для разворачиваемых файлов, установленную в классе deploy как DEPLOYDIR = «${WORKDIR}/deploy-${PN}». Заданиям, наследующим класс deploy,
следует
копировать разворачиваемые файлы в
DEPLOYDIR, а класс затем скопирует их в DEPLOY_DIR_IMAGE.

DESCRIPTION

Описание пакета, используемое менеджерами пакетов. Если значение DESCRIPTION не задано, автоматически принимается значение переменной SUMMARY.

DISTRO

Короткое имя для дистрибутива. Длинные имена задаются переменной DISTRO_NAME.

Переменная DISTRO соответствует файлу конфигурации (.conf) дистрибутива, корневое имя которого совпадает со значением переменной. Например, файл конфигурации дистрибутива Poky называется poky.conf и размещается в каталоге meta-poky/conf/distro дерева исходных кодов. В этом файле переменная задана как DISTRO = «poky».

Конфигурационные файлы дистрибутивов размещаются в каталоге conf/distro метаданных с конфигурацией дистрибутива. Значение DISTRO должно быть без пробелов и обычно указывается строчными буквами. Если переменная DISTRO пуста, используется заданное по умолчанию значение, которое указано в файле meta/conf/distro/defaultsetup.conf дерева исходных кодов.

DISTRO_CODENAME

Задает кодовое имя для собираемого дистрибутива.

DISTRO_EXTRA_RDEPENDS

Задает список определяемых дистрибутивом приложений, которые включаются во все образы. Эта переменная работает через packagegroup-base, поэтому на деле применяется только к наиболее функциональным образам, включающим группу packagegroup-base. Переменная указывается в файле конфигурации дистрибутива .conf.

DISTRO_EXTRA_RRECOMMENDS

Задает список специфических для дистрибутива приложений, добавляемых по все образы при наличии пакетов (пакеты могут отсутствовать или быть пустыми, например, модули ядра). Пакеты из списка устанавливаются автоматически, но их можно удалить.

DISTRO_FEATURES

Поддержка программ, которую нужно включить в дистрибутив, задаваемая в конфигурационном файле. В большинстве случаев наличие или отсутствие свойства в DISTRO_FEATURES передается в соответствующую опцию сценария настройки при выполнении задачи do_configure для заданий, которые могут поддерживать это свойство. Например, указание x11 в DISTRO_FEATURES приведет к возможности включения поддержки X11 для каждой собираемой программы. Другими примерами служат поддержка Bluetooth и NFS. Более полный список включенных в YP свойств (возможностей) представлен в параграфе 12.2. Свойства дистрибутива.

DISTRO_FEATURES_BACKFILL

Свойства для добавления в DISTRO_FEATURES при отсутствии в DISTRO_FEATURES_BACKFILL_CONSIDERED. Переменная указывается в файле meta/conf/bitbake.conf и не предназначена для настройки пользователем. Лучше просто указать переменную для свойств, включаемых во все конфигурации дистрибутива (параграф 12.4. Отключение автоматически добавляемых свойств).

DISTRO_FEATURES_BACKFILL_CONSIDERED

Свойства из переменной DISTRO_FEATURES_BACKFILL, которые не следует включать (добавлять в DISTRO_FEATURES) при сборке (параграф 12.4. Отключение автоматически добавляемых свойств).

DISTRO_FEATURES_DEFAULT

Вспомогательная переменная со списком принятых по умолчанию свойств дистрибутива за исключением свойств, относящихся к библиотеке C (libc).

При создании пользовательского дистрибутива может оказаться полезной возможность многократного использования заданных по умолчанию опций DISTRO_FEATURES без необходимости переписывать весь набор. Это можно сделать, указав в конфигурационном файле дистрибутива DISTRO_FEATURES ?= «${DISTRO_FEATURES_DEFAULT} myfeature».

DISTRO_FEATURES_FILTER_NATIVE

Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий native. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVE.

DISTRO_FEATURES_FILTER_NATIVESDK

Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVESDK.

DISTRO_FEATURES_NATIVE

Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке естественных заданий. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVE.

DISTRO_FEATURES_NATIVESDK

Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVESDK.

DISTRO_NAME

Длинное имя дистрибутива (короткое задает переменная DISTRO).

Переменная DISTRO_NAME соответствует файлу конфигурации (.conf) дистрибутива, корневое имя которого совпадает со значением переменной. Например, файл конфигурации дистрибутива Poky называется poky.conf и размещается в каталоге meta-poky/conf/distro дерева исходных кодов. В этом файле poky.conf переменная DISTRO_NAME задана как DISTRO_NAME = «Poky (Yocto Project Reference Distro)».

Конфигурационные файлы дистрибутивов размещаются в каталоге conf/distro метаданных с конфигурацией дистрибутива. Если переменная DISTRO_NAME пуста, используется заданное по умолчанию значение, которое указано в файле meta/conf/distro/defaultsetup.conf дерева исходных кодов.

DISTRO_VERSION

Версия дистрибутива.

DISTROOVERRIDES

Список разделенных двоеточиями переопределений для текущего дистрибутива. По умолчанию список включает значение DISTRO. Можно расширить DISTROOVERRIDES для добавления переопределений, применяемых к дистрибутиву. Базовым механизмом для DISTROOVERRIDES является включение в принятое по умолчанию значение OVERRIDES.

DL_DIR

Основной каталог загрузок, используемый процессом сборки для хранения загруженных файлов. По умолчанию DL_DIR принимает файлы, подходящие для «зеркалирования» всего, кроме репозиториев Git. Если нужны архивы репозиториев Git, следует использовать переменную BB_GENERATE_MIRROR_TARBALLS.

Каталог загрузки DL_DIR указывается в файле conf/local.conf. Каталог поддерживает себя и не нужно его трогать. По умолчанию загрузки выполняются в каталог сборки. Если нужно использовать другой каталог, следует убрать символ комментария в строке #DL_DIR ?= «${TOPDIR}/downloads».

При первой сборке система загружает множество архивов исходного кода из разных проектов, что может продолжаться достаточно долго. Архивы сохраняются в каталоге, указанном DL_DIR и система сборки ищет там архивы исходных кодов. При очистке или повторной сборке можно сохранить каталог загрузки для ускорения процесса.

Этот каталог можно использовать для разных сборок, выполняемых на хосте разработки. Дополнительная информация о загрузке архивов исходного кода при работе через прокси или межсетевой экран приведена в параграфе 15.12. Работа через межсетевой экран, а также на странице Working Behind a Network Proxy.

DOC_COMPRESS

При наследовании класса compress_doc эта переменная задает правила сжатия, используемые системой сборки OE для страниц man и info. По умолчанию применяется компрессия gz (gzip), но можно выбрать xz или bz2. Информация об использовании этой переменной и правилах приведена в комментариях в файле meta/classes/compress_doc.bbclass.

E

EFI_PROVIDER

При сборке загружаемых образов (типы hddimg, iso, wic.vmdk в IMAGE_FSTYPES), переменная указывает применяемый загрузчик EFI. По умолчанию используется grub-efi, но можно задать systemd-boot (см. параграфы 6.130. systemd-boot.bbclass и 6.53. image-live.bbclass).

ENABLE_BINARY_LOCALE_GENERATION

Переменная, задающая варианты locale для glibc, которые создаются при сборке (полезно для платформ с ОЗУ, не превышающим 64 Мбайт).

ERR_REPORT_DIR

При использовании с классом report-error задает путь, используемый для хранения отладочных файлов, созданных инструментом отчетов об ошибках, для централизованного хранения сведений об ошибках сборки. По умолчанию переменная имеет значение ${LOG_DIR}/error-report, которое можно изменить в файле local.conf с помощью строки ERR_REPORT_DIR = «path«.

ERROR_QA

Задает проверки качества, об отказах которых системой сборки OE будут выдаваться сообщения об ошибках. Переменная задается в конфигурации дистрибутива, список проверок приведен в параграфе 6.56. insane.bbclass.

EXCLUDE_FROM_SHLIBS

Запускает распознаватель общих библиотек в системе сборки OE для исключения пакета целиком при сканировании общих библиотек. Функциональность распознавателя общих библиотек частично определяется внутренней функцией package_do_shlibs, которая является частью задачи do_package task. Следует знать, что распознаватель общих библиотек может неявно определять некоторые зависимости между пакетами.

Переменная EXCLUDE_FROM_SHLIBS похожа на PRIVATE_LIBS, которая исключает отдельные библиотеки, а не весь пакет. Переменная устанавливается для конкретного пакета в форме EXCLUDE_FROM_SHLIBS = «1».

EXCLUDE_FROM_WORLD

Указывает BitBake исключить задание из сборки world (т. е. bitbake
world
). При сборках world программа BitBake находит, анализирует и собирает все задания, найденные в каждом уровне, указанном в файле bblayers.conf. Для исключения задания следует установить в этой переменной значение 1 в задании.

Добавленные в EXCLUDE_FROM_WORLD могут все-таки включаться в сборку world для выполнения зависимостей других заданий. Включение в EXCLUDE_FROM_WORLD лишь блокирует явное включение задания в сборку.

EXTENDPE

применяется с файлами и именами путей для создания префикса версии задания на основе значения PE. Если для задания установлено значение PE больше 0, переменная EXTENDPE принимает это значение (т. е. при PE = «1» EXTENDPE становится «1_»). Если переменная PE в задании не установлена (принято по умолчанию) или равна 0, EXTENDPE получает значение «». Дополнительные сведения приведены в описании переменной STAMP.

EXTENDPKGV

Полная спецификация версии пакета, как она указана в финальных пакетах, создаваемых заданием. Значение переменной обычно служит для исправления зависимостей при работе от конкретной версии другого пакета в том же задании.

     RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"

Отношения зависимости нужны для того, чтобы менеджер пакетов обновлял эти пакеты в режиме блокировки.

EXTERNAL_KERNEL_TOOLS

Установленная переменная показывает инструменты, не включенные в дерево исходных кодов. Инструменты, доступные в дереве, обычно являются предпочтительными, но установка этой переменной позволяет системе сборки OE отдать предпочтение внешним инструментам. Использование переменной рассмотрено в параграфе 6.66. kernel-yocto.bbclass.

EXTERNALSRC

При наследовании класса externalsrc эта переменная указывает каталог исходных кодов за пределами системы сборки OE. При установке этой переменной она задает значение переменной S, используемой системой OE для указания распакованного исходного кода. Информация о классе externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass,
а
использование переменной описано в
разделе
Building Software from an External Source [2].

EXTERNALSRC_BUILD

При наследовании класса externalsrc эта переменная указывает каталог, в котором собирается исходный код задания, находящийся вне системы сборки OE. При установке этой переменной она задает значение переменной B,
используемой
системой
OE для указания сборочного каталога. Информация о классе externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass,
а
использование переменной описано в
разделе
Building Software from an External Source [2].

EXTRA_AUTORECONF

Для заданий, наследующих класс autotools, эта переменная позволяет задать дополнительные опции команды autoreconf,
выполняемой
задачей
do_configure
(по
умолчанию
—exclude=autopoint).

EXTRA_IMAGE_FEATURES

Список разделенных пробелами дополнительных возможностей для включения в образ. Обычно эта переменная указывается в файле local.conf сборочного каталога. Возможно ее указание и в других файлах, но делать этого не следует. Для включения базовых возможностей образа служит переменная IMAGE_FEATURES.

Ниже приведены примеры некоторых дополнительных возможностей.

dbg-pkgs

Добавляет пакеты -dbg для отлаживания и профилирования.

debug-tweaks

Делает образ пригодны для отладки, например, позволяя вход в систему пользователя root без пароля и включая запись в системный журнал событий после установки. Дополнительная информация представлена в описаниях свойств allow-empty-password и post-install-logging в параграфе 12.3. Свойства образа.

dev-pkgs

Добавляет в образ пакеты разработки -dev.

read-only-rootfs

Создает образ, корневая система которого доступна только для чтения (см. раздел Creating a Read-Only Root Filesystem [2]).

tools-debug

Добавляет средства отладки, такие как gdb и strace.

tools-sdk

Добавляет служебные пакеты, такие как gcc, make, pkgconfig и т. п.

tools-testapps

Добавляет средства тестирования, такие как ts_print, aplay, arecord и т. п.

Полный список возможностей, включенных в выпуск YP, представлен в параграфе 12.3. Свойства образа.

Пример настройки свойств образа с помощью этой переменной приведен в разделе Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES [2].

EXTRA_IMAGECMD

Задает опции команды создания образа, указанной в IMAGE_CMD. При установке этой переменной используется переопределение соответствующего типа образа, например, EXTRA_IMAGECMD_ext3 ?= «-i 4096».

EXTRA_IMAGEDEPENDS

Список заданий для сборки, которые не предоставляют пакетов, устанавливаемых в корневую файловую систему.

Иногда для сборки финального образа нужны задания, которые не требуются в корневой файловой системе. Переменная EXTRA_IMAGEDEPENDS позволяет указать эти задания для выполнения зависимостей. Типичные примером является требование иметь загрузчик в конфигурации машины.

Добавление пакетов в корневую систему управляется переменными *RDEPENDS и *RRECOMMENDS.

EXTRANATIVEPATH

Список каталогов в ${STAGING_BINDIR_NATIVE},
добавляемых
в начало переменной окружения
PATH. Например, для добавления в путь поиска каталогов «${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:» можно указать EXTRANATIVEPATH = «foo bar».

EXTRA_OECMAKE

Опции CMake (см. параграф 6.17. cmake.bbclass).

EXTRA_OECONF

Опции сценария configure.
Передача
опций зависит от переменной
PACKAGECONFIG_CONFARGS.

EXTRA_OEMAKE

Опции GNU make. Поскольку переменная EXTRA_OEMAKE по умолчанию пуста, ее требуется установить в соответствии с нужными опциями GNU. Переменные PARALLEL_MAKE и PARALLEL_MAKEINST также используют EXTRA_OEMAKE для передачи требуемых флагов.

EXTRA_OESCONS

При наследовании класса scons эта переменная задает дополнительные параметры конфигурации, которые нужно передать команде scons.

EXTRA_USERS_PARAMS

При наследовании класса extrausers эта переменная представляет пользовательские и групповые операции на уровне образа. Это более глобальный метод предоставления конфигурации пользователей и групп по сравнению с использованием класса useradd, который связывает конфигурации пользователей и групп с конкретным заданиям.

Набор команд, которые можно представить с помощью EXTRA_USERS_PARAMS,
приведен
в описании класса
extrausers. Эти команды отображаются на одноименные команды Unix, как показано ниже.

     # EXTRA_USERS_PARAMS = "\
     # useradd -p '' tester; \
     # groupadd developers; \
     # userdel nobody; \
     # groupdel -g video; \
     # groupmod -g 1020 developers; \
     # usermod -s /bin/sh tester; \
     # "

F

FEATURE_PACKAGES

Определяет пакеты для включения в образ, когда соответствующее свойство включено в переменную IMAGE_FEATURES. При установке значения переменной FEATURE_PACKAGES следует указывать суффикс в виде имени свойства, например,

FEATURE_PACKAGES_widget = "package1 package2"

В этом примере при наличии свойства widget в IMAGE_FEATURES
в
образ будут добавлены пакеты
package1 и package2. Пакеты, устанавливаемые свойствами через переменную FEATURE_PACKAGES,
зачастую
являются группами
. Несмотря на схожесть имен, не следует путать переменную FEATURE_PACKAGES с группами пакетов, встречающимися в документации.

FEED_DEPLOYDIR_BASE_URI

Указывает базовый идентификатор (URL) сервера и местоположение на нем метаданных и пакетов, требуемых OPKG для поддержки управления пакетами IPK в процессе работы. Переменная задается в файле local.conf,
например,
FEED_DEPLOYDIR_BASE_URI = «http://192.168.7.1/BOARD-dir». Здесь предполагается, что пакеты обслуживаются по протоколу HTTP, а базы данных хранятся на сервере в каталоге BOARD-dir. В этом случае система сборки OE будет создавать набор конфигурационных файлов для целевой платформы, которые подойдут для указанного хранилища.

FILES

Список файлов и каталогов, помещенных в пакет. Пакеты, созданные заданием перечисляются в переменной PACKAGES. Для использования переменной FILES имя пакета переопределяется с указанием результирующего пакета. Затем указывается список разделенных пробелами файлов или путей, указывающих файлы, включенные в результирующий пакет.

     FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
  • При указании файлов и путей можно применять синтаксис Python glob.
  • При указании путей в переменной FILES хорошим тоном является использование подходящих переменных. Например, следует указывать ${sysconfdir} вместо /etc
    или
    ${bindir} вместо /usr/bin. Список этих переменных приведен в начале файла meta/conf/bitbake.conf в дереве исходных кодов, где также представлены принятые по умолчанию значения различных переменных FILES_*.

Если некоторые из файлов в FILES являются редактируемыми и их не следует переписывать в процессе обновления пакета системой PMS, можно указать эти файлы, чтобы PMS не переписывала их (см. описание переменной CONFFILES).

FILES_SOLIBSDEV

Задает спецификацию файлов для сопоставления с SOLIBSDEV. Иными словами, FILES_SOLIBSDEV определяет полный путь к символьным ссылкам на общие библиотеки для целевой платформы. Переменная задается в файле bitbake.conf как FILES_SOLIBSDEV ?= «${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}».

FILESEXTRAPATHS

Расширяет путь поиска OE для файлов и исправлений при обработке файлов заданий и добавлений. Используются принятые по умолчанию каталоги, используемые BitBake, определяются переменной FILESPATH,
которая может быть расширена с помощью
FILESEXTRAPATHS
. Лучше делать это с помощью переменной FILESEXTRAPATHS из файла .bbappend file и помещать пути в начало, как показано ниже.

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

В этом примере система сборки смотрит сначала в каталоге, имя которого совпадает с именем соответствующего файла добавления.

При использовании FILESEXTRAPATHS
обязательно указывайте оператор
незамедлительного расширения
(:=). Это гарантирует, что BitBake будет вычислять THISDIR в момент обнаружения директивы, а не позднее, когда расширение может привести в каталог, где нет нужных файлов.

Включайте двоеточие в конце строки при ее добавлении пути в начало. Это нужно для того, чтобы указать BitBake расширение пути путем вставки каталогов в начало пути поиска.

Ниже приведен еще один вариант использования.

     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

В этом примере система сборки расширяет переменную FILESPATH для включения файлов из того же каталога, что и соответствующий файл добавления. Выражение FILESEXTRAPATHS_prepend := «path_1:path_2:path_3:» добавляет 3 пути.

В другом примере показано, как можно расширить путь поиска и включить зависящее от MACHINE
переопределение, полезно
е
на уровне
BSP — FILESEXTRAPATHS_prepend_intel-x86-common := «${THISDIR}/${PN}:»

Этот оператор присутствует в файле linux-yocto-dev.bbappend, который имеется в YP Source Repositories (раздел meta-intel/common/recipes-kernel/linux). Здесь в зависимости от машины изменяется специальное определение PACKAGE_ARCH для множества машин meta-intel.

Для уровней, поддерживающих один пакет BSP, переопределение может задаваться значением MACHINE.

Добавление пути в начало через файлы .bbappend позволяет расширять путь с помощью множества файлов дополнения, находящихся на разных уровнях но относящихся к одному заданию.

FILESOVERRIDES

Подмножество OVERRIDES,
используемое
системой сборки
OE для создания FILESPATH. Переменная использует переопределение для автоматического расширения FILESPATH
(пример работы приведен в описании FILESPATH,
а
более подробная информация о
переопределениях - в разделе
Conditional Syntax (Overrides) [4]). По умолчанию переменная задается в форме FILESOVERRIDES = «${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}». Переменную не следует редактировать вручную. Значения совпадают с ожидаемыми переопределениями и используются системой сборки ожидаемым способом.

FILESPATH

Принятый по умолчанию набор каталогов, в котором система сборки OE ищет исправления и файлы. В процессе сборки BitBake просматривает каждый каталог из FILESPATH в указанном порядке для поиска файлов и исправления, заданных каждым URI file:// в операторах SRC_URI задания. Используемое по умолчанию значение переменной FILESPATH определено в файле base.bbclass каталога meta/classes в дереве исходных кодов.

     FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
        "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"

Переменная FILESPATH расширяется автоматически с использованием переопределений из переменной FILESOVERRIDES.

  • Не следует редактировать переменную FILESPATH вручную. Если нужно задать поиск файлов в каталогах, отличающихся от принятых по умолчанию, расширьте FILESPATH с помощью FILESEXTRAPATHS.
  • Принятые по умолчанию каталоги FILESPATH не отображаются на каталоги пользовательских уровней, где используются файлы добавления (.bbappend). Если нужно искать файлы или исправления, указанные в файлах добавления, следует расширить переменную FILESPATH с помощью FILESEXTRAPATHS.

Такое поведение системы поиска может быть полезно во многих случаях. В качестве примера может служить приведенная ниже структура каталогов с общей и машино-зависимой конфигурацией.

     files/defconfig
     files/MACHINEA/defconfig
     files/MACHINEB/defconfig

В этом примере оператор SRC_URI содержит file://defconfig. С учетом сказанного можно установить MACHINE = MACHINEA и заставить систему сборки использовать файлы из каталога files/MACHINEA, а установка MACHINE = MACHINEB приведет к использованию файлов из files/MACHINEB. Для остальных машин система сборки будет использовать файлы из files/defconfig.

Дополнительная информации о внесении изменений в исходные коды приведена в разделах Patching [1] и Patching Code [2], а также в параграфе 7.1.19. do_patch.

FILESYSTEM_PERMS_TABLES

Позволяет задать свою таблицу настроек прав доступа к файлу как часть конфигурации процесса подготовки пакетов. Например, при потребности в согласованном наборе прав доступа для групп и пользователей в рамках проекта лучше устанавливать эти права в пакетах, но это возможно не всегда. По умолчанию система сборки OE использует файл fs-perms.txt из каталога meta/files в дереве кодов. При создании своей таблицы разрешений следует поместить ее на свой уровень или уровень дистрибутива.

Переменная определяется в файле conf/local.conf каталога сборки и указывает пользовательский файл fs-perms.txt. Можно задать несколько таблиц доступа. Пути к файлам должны быть определены в переменной BBPATH. Рекомендации по созданию таблицы прав даны в файле fs-perms.txt.

FONT_EXTRA_RDEPENDS

При наследовании класса fontcache задает зависимости при работе от шрифтовых пакетов. По умолчанию FONT_EXTRA_RDEPENDS имеет значение «fontconfig-utils».

FONT_PACKAGES

При наследовании класса fontcache указывает пакеты, содержащие файлы шрифтов, которые нужно кэшировать в Fontconfig. По умолчанию класс fontcache предполагает шрифты в основном задании пакета (${PN}). Эта переменная нужна для случаев, когда шрифты размещаются не в основном пакете.

FORCE_RO_REMOVE

Значение 1 форсирует удаление пакетов, указанных в ROOTFS_RO_UNNEEDED,
при создании корневой файловой системы.

FULL_OPTIMIZATION

Опции, передаваемые в TARGET_CFLAGS и CFLAGS при компиляции оптимизированной системы (по умолчанию -O2 -pipe ${DEBUG_FLAGS}).

G

GCCPIE

Включает поддержку PIE3 для компилятора GCC. Включение PIE в GCC осложняет организацию атак ROP4. По умолчанию в файле security_flags.inc указано GCCPIE ?= «—enable-default-pie».

GCCVERSION

Задает принятый по умолчанию компилятор GNU C (GCC). По умолчанию в файле meta/conf/distro/include/tcmode-default.inc задано GCCVERSION ?= «8.%». Можно указать другую версию в файле local.conf.

GDB

Сокращенная команда и аргументы для запуска отладчика GNU (gdb).

GITDIR

Каталог для хранения локальной копии репозитория Git при его клонировании.

GLIBC_GENERATE_LOCALES

Задает список языковых файлов GLIBC, если не нужны все такие файлы (занимает много времени). При удалении языка en_US.UTF-8 следует должным образом установить переменную IMAGE_LINGUAS. По умолчанию создаются файлы для всех языков. Значение GLIBC_GENERATE_LOCALES можно указать в файле local.conf как GLIBC_GENERATE_LOCALES = «en_GB.UTF-8 en_US.UTF-8″.

GROUPADD_PARAM

При наследовании класса useradd эта переменная указывает, какие параметры для пакета следует передать команде groupadd, если нужно добавить группу при установке пакета. Например, для задания dbus указывается GROUPADD_PARAM_${PN} = «-r netdev»

Информация о стандартной команде Linux groupadd доступна по ссылке http://linux.die.net/man/8/groupadd.

GROUPMEMS_PARAM

При наследовании класса useradd эта переменная указывает, какие параметры для пакета следует передать команде groupmems, если нужно изменить состав группы при установке пакета.

Информация о стандартной команде Linux groupmems доступна по ссылке http://linux.die.net/man/8/groupmems.

GRUB_GFXSERIAL

Указывает режим работы загрузчика GRUB5. Установите для этой переменной значение 1 в файле local.conf или файле конфигурации дистрибутива для включения графического режима и консоли serial. Использование переменной рассмотрено в описании класса grub-efi.

GRUB_OPTS

Опции для добавления в конфигурацию загрузчика GRUB, разделенные точкой с запятой (;). Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.

GRUB_TIMEOUT

Задает время ожидания перед выбором заданной по умолчанию метки default LABEL загрузчике GRUB. Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.

GTKIMMODULES_PACKAGES

При наследовании класса gtk-immodules-cache эта переменная указывает пакеты, содержащие устанавливаемые модули ввода GTK+, когда они не находятся в основном пакете.

H

HOMEPAGE

Web-сайт, на котором можно найти дополнительную информацию о собираемой заданием программе.

HOST_ARCH

Имя целевой архитектуры, которое обычно совпадает с TARGET_ARCH. Система сборки OE поддерживает множество вариантов архитектуры, включая arm, i586, x86_64, powerpc, powerpc64, mips, mipsel.

HOST_CC_ARCH

Указывает зависящие от архитектуры флаги, передаваемые компилятору C. Принятая по умолчанию инициализация HOST_CC_ARCH зависит от цели сборки:

  • TARGET_CC_ARCH при сборке для целевой платформы;
  • BUILD_CC_ARCH при сборке для сборочного хоста (-native);
  • BUILDSDK_CC_ARCH при сборке для SDK (nativesdk-).

HOST_OS

Задает имя целевой операционной системы, которое обычно совпадает с TARGET_OS. Для переменной можно установить значение linux в системах на основе glibc и linux-musl в системах на основе musl. Для платформ ARM/EABI возможны также значения linux-gnueabi и linux-musleabi.

HOST_PREFIX

Задает префикс для инструментов кросс-компиляции. HOST_PREFIX обычно совпадает с TARGET_PREFIX.

HOST_SYS

Задает систему, включая архитектуру и ОС, для которой выполняется сборка в контексте текущего задания. Система сборки OE автоматически устанавливает эту переменную на основе значений HOST_ARCH, HOST_VENDOR и HOST_OS. Например, для естественного задания на 32-битовой машине x86 с ОС Linux переменная будет иметь значение i686-linux, а для задания на платформе little-endian MIPS с ОС Linux — mipsel-linux. Менять переменную не нужно.

HOSTTOOLS

Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. Если заданный в переменной инструмент не найден, система сборки OE выдает ошибку и сборка не начинается.

HOSTTOOLS_NONFATAL

Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. В отличие от инструментов HOSTTOOLS
система
сборки
OE не выдает ошибку при отсутствии указанного в HOSTTOOLS_NONFATAL.
Таким
образом, эта переменная указывает
необязательные инструменты хоста
.

HOST_VENDOR

Задает имя производителя целевого хоста. HOST_VENDOR обычно совпадает с TARGET_VENDOR.

I

ICECC_DISABLED

Управляет работой icecc (Icecream), рассмотренной в параграфе 6.49. icecc.bbclass. Установка в файле local.conf ICECC_DISABLED ??= «1» отключает функцию, ICECC_DISABLED = «» — включает.

ICECC_ENV_EXEC

Указывает пользовательский сценарий icecc-create-env, используется классом icecc и устанавливается в файле local.conf. Если сценарий не указан, система сборки OE использует принятый по умолчанию сценарий из задания icecc-create-env.bb, который является измененной версией сценария из состава icecc.

ICECC_PARALLEL_MAKE

Опции, передаваемые команде make в задаче do_compile для параллельной компиляции. Эта переменная обычно имеет форму -j x, где x указывает максимальное число параллельных потоков. Опция влияет на все машины в сети сборки, где работает демон iceccd. При поддержке машинами множества ядер определение максимального числа потоков может потребовать некоторых экспериментов для учета скорости машин, задержек в сети, доступной памяти и текущей загрузки машин. Поэтому, в отличие от переменной PARALLEL_MAKE, для
установки
ICECC_PARALLEL_MAKE нет строгих правил.

При отсутствии ICECC_PARALLEL_MAKE система сборки не будет определять и задавать число используемых ядер, как это делается для PARALLEL_MAKE.

ICECC_PATH

Путь к исполняемому файлу icecc, задаваемый в файле local.conf. Если путь не задан, класс icecc пытается найти icecc с помощью команды which.

ICECC_USER_CLASS_BL

Указывает пользовательские классы, для который не следует использовать распределенную компиляцию Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной классы будут компилироваться локально.

ICECC_USER_PACKAGE_BL

Указывает пользовательские задания, которые не нужно учитывать в распределенной компиляции Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной пакеты будут компилироваться локально.

ICECC_USER_PACKAGE_WL

Указывает пользовательские задания с пустой переменной PARALLEL_MAKE,
для
которых нужно принудительно использовать
параллельную удаленную компиляции с
использованием системы распределенной
компиляции
Icecream. Переменная используется классом icecc
и
может указываться в файле
local.conf.

IMAGE_BASENAME

Базовое имя выходных файлов образа, по умолчанию совпадающее с именем задания (${PN}).

IMAGE_BOOT_FILES

Список разделенных пробелами файлов, установленных в корневой раздел пр подготовке образа с использованием Wic и подключаемым модулем bootimg-partition. По умолчанию файлы устанавливаются с теми же именами, которые были у исходных файлов. Для изменения имен их следует отделять от исходных имен точкой с запятой (;). Исходные файлы должны размещаться в DEPLOY_DIR_IMAGE. Ниже приведены два примера.

     IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
     IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"

Кроме того, исходные файлы можно указать с помощью шаблона glob. В этом случае целевой файл должен иметь такое же имя, как и базовое имя в пути к исходному файлу. Для установки файлов в целевой системе их имена передаются после точки с запятой (;), как показано в приведенных ниже примерах.

     IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
     IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/"

Первый пример устанавливает все файлы из ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles в корневой раздел целевой системы, а второй устанавливает те же файлы в каталог boot внутри целевого раздела.

Информация о работе с Wic приведена в разделе Creating Partitioned Images Using Wic [2], а Глава 9. Справочник по OpenEmbedded Kickstart (.wks) содержит описание Wic.

IMAGE_CLASSES

Список классов, которые нужно наследовать всем образам. Обычно эта переменная служит для задания классов, регистрирующих разные типы образов, которые создает система сборки OE. По умолчанию используется IMAGE_CLASSES = image_types,
но
можно установить другое значение в
файле
local.conf или в конфигурационном файле дистрибутива (см. meta/classes/image_types.bbclass в каталоге исходных кодов).

IMAGE_CMD

Задает команду создания файла образа определенного типа, соответствующего значению IMAGE_FSTYPES (например, ext3, btrfs
и
т. п.
). При установке переменной следует использовать переопределение для связанного типа, как показано ниже.

     IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
        --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
        ${EXTRA_IMAGECMD}"

Обычно эту переменную не требуется устанавливать, если не добавляется поддержка нового типа образов. Примеры установки этой переменной можно найти в файле meta/classes/image_types.bbclass.

IMAGE_DEVICE_TABLES

Задает один или несколько файлов с пользовательскими таблицами устройств, которые передаются команде makedevs как часть создания образа. Эти файлы указывают базовые узлы устройства, которые следует создать в иерархии /dev внутри образа. Если переменная не указана, используется файл files/device_table-minimal.txt is used, найденный в пути BBPATH. Пример таблицы устройств имеется в файле meta/files/device_table-minimal.txt.

IMAGE_FEATURES

Основной список свойств (возможностей) для включения в образ. Обычно эта переменная указывается в задании для образа. Можно указать переменную в файле local.conf в каталоге сборки, но лучше так не поступать.

Для добавления возможностей за пределами задания для образа служит переменная EXTRA_IMAGE_FEATURES.

Список возможностей, включенных в выпуск YP, представлен в параграфе 12.3. Свойства образа. Пример настройки образа с помощью этой переменной приведен в разделе Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES [2].

IMAGE_FSTYPES

Задает формат, применяемый системой сборки OE при создании корневой файловой системы. Например, для создания файлов систем, использующих форматы .ext3 и .tar.bz2
служит
IMAGE_FSTYPES = «ext3 tar.bz2».

Полный список поддерживаемых форматов приведен в описании переменной IMAGE_TYPES.

  • Если задание для образа использует строку inherit image и в нем установлена переменная IMAGE_FSTYPES, ее значение должно быть установлено до строки inherit image.
  • Способ обработки этой переменной в системе сборки OE не позволяет обновлять ее содержимое с помощью _append или _prepend
    и
    требует использования оператора
    += для добавления опций в IMAGE_FSTYPES.

IMAGE_INSTALL

Используется в заданиях для указания пакетов, устанавливаемых в образ с помощью класса image.
Переменную
следует применять осторожно, чтобы не
возникло проблем с порядком установки
. Имеются вспомогательные классы (например, core-image),
принимающие списки, используемые с
IMAGE_FEATURES,
и
включающие элементы в автоматически
создаваемые записи
IMAGE_INSTALL в дополнение к имеющимся.

При использовании переменной лучше всего ее задавать, как показано ниже.

IMAGE_INSTALL_append = " package-name"

Не забывайте указывать пробел перед именем пакета.

  • При работе с образом core-image-minimal-initramfs не используйте переменную IMAGE_INSTALL для задания устанавливаемых пакетов. В этом случае нужна переменная PACKAGE_INSTALL, которая позволяет заданию initramfs использовать фиксированный набор приложений, на который не влияет переменная IMAGE_INSTALL. Информация о создании initramfs приведена в разделе Building an Initial RAM Filesystem (initramfs) Image [2].
  • Использование переменной IMAGE_INSTALL с
    оператором
    BitBake +=
    в
    файле
    /conf/local.conf file или иных файлах задания для образе не рекомендуется, поскольку применение этого оператора может приводить к проблемам с порядком установки. Класса core-image.bbclass устанавливает для IMAGE_INSTALL принятое по умолчанию значение с помощью оператора ?=, использование += для переменной IMAGE_INSTALL в файле conf/local.conf
    приводит к неожиданному поведению. Кроме того, та же операция из задания для образа может завершаться отказом в зависимости от ситуации. В обоих случаях поведение будет отличаться от ожидаемого пользователем для оператора +=.

IMAGE_LINGUAS

Задает список языков (locale) для включения в образ при создании корневой файловой системы. Система сборки OE автоматически разделяет языковые файлы по отдельным пакетам. Назначение переменной IMAGE_LINGUAS гарантирует включение языковых пакетов во все пакеты, выбранные для инсталляции в образ. Переменная задается в форме IMAGE_LINGUAS = «pt-br de-de». Пример показывает установку языковых файлов для бразильского португальского и немецкого языка для включенных в образ пакетов (т. е. *-locale-pt-br и *-locale-de-de, а для некоторых пакетов *-locale-pt и *-locale-de, поскольку часть пакетов обеспечивает файлы языков без учета страны). Генерация языковых файлов GLIBC рассмотрена в описании переменной GLIBC_GENERATE_LOCALES.

IMAGE_MANIFEST

Файл манифеста для образа, перечисляющий все установленные пакеты (по одной строке на пакет) в форме packagename packagearch version. Класс image определяет файл манифеста как IMAGE_MANIFEST = «${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest». Местоположение выводится из переменных DEPLOY_DIR_IMAGE и IMAGE_NAME. Создание образов описано в разделе Image Generation [1].

IMAGE_NAME

Имя выходных файлов образа без расширений, задаваемое в форме IMAGE_NAME = «${IMAGE_BASENAME}-${MACHINE}-${DATETIME}».

IMAGE_OVERHEAD_FACTOR

Определяет коэффициент, который система сборки использует для начального размера образа в случаях, когда используемое в образе пространство (возврат команды du), умноженное на этот коэффициент, превышает сумму IMAGE_ROOTFS_SIZE и IMAGE_ROOTFS_EXTRA_SPACE. Результатом использования коэффициента для начального размера является увеличение свободного пространства в образе. По умолчанию система сборки использует для этой переменной значение 1,3, что приводит к добавлению 30% свободного пространства в финальный образ. Следует учитывать, что применяемые после инсталляции сценарии и система управления пакетами используют пространство из этой области. Поэтому коэффициент не задает точно свободное пространство, получаемое в результате. Определение общего размера образа зависит от переменной IMAGE_ROOTFS_SIZE.

Установленное по умолчанию свободное пространство в 30% обеспечивает достаточно места для загрузки и использования пост-установочных сценариев для большинства случаев. Если это значение не подходит, можно изменить размер свободного пространства. Например, для резервирования 50% свободно места можно задать IMAGE_OVERHEAD_FACTOR = «1.5». Можно также обеспечить дополнительное свободное пространство на диске с помощью переменной IMAGE_ROOTFS_EXTRA_SPACE.

IMAGE_PKGTYPE

Определяет тип пакета (DEB, RPM, IPK или TAR), используемый системой сборки OE. Переменная определяется классом package_deb, package_rpm, package_ipk или package_tar. Класс package_tar больше не применяется и не поддерживается, поэтому не следует его использовать. Классы populate_sdk_* и image используют переменную IMAGE_PKGTYPE для упаковки образов и SDK.

Переменную IMAGE_PKGTYPE не следует устанавливать вручную, поскольку она задается опосредованно через подходящий класс package_* с использованием переменной PACKAGE_CLASSES. Система сборки OE применяет первый тип пакета (DEB, RPM или IPK) из этой переменной.

Архивы .tar никогда не применяются в качестве замены форматов DEB, RPM и IPK для образов и SDK.

IMAGE_POSTPROCESS_COMMAND

Задает список функций, однократно вызываемых системой сборки OE при создании окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_POSTPROCESS_COMMAND += «function; … «

Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

IMAGE_PREPROCESS_COMMAND

Задает список функций, вызываемых системой сборки OE перед созданием окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_PREPROCESS_COMMAND += «function; … «

Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

IMAGE_ROOTFS

Местоположение корневой файловой системы в процессе ее создания (задача do_rootfs). Значение этой переменной не следует менять.

IMAGE_ROOTFS_ALIGNMENT

Задает выравнивание для выходного файла образа в килобайтах. Если размер образа не кратен этому значению, он округляется вверх до кратного значения. По умолчанию установлено значение 1 (см. IMAGE_ROOTFS_SIZE).

IMAGE_ROOTFS_EXTRA_SPACE

Задает дополнительное свободное пространства в создаваемом образе (в килобайтах). По умолчанию дополнительное пространство не выделяется (0). Заданное переменной пространство добавляется в образ после того, как система сборки определит размер образа в соответствии с переменной IMAGE_ROOTFS_SIZE.

Переменная полезна для резервирования свободного пространства в файловой системе после загрузки образа. Например, для обеспечения свободных 5 Гбайт можно указать IMAGE_ROOTFS_EXTRA_SPACE = «5242880». В частности, Yocto Project Build Appliance задает 40 Гбайт дополнительного места с помощью строки IMAGE_ROOTFS_EXTRA_SPACE = «41943040».

IMAGE_ROOTFS_SIZE

Определяет размер создаваемого образа к килобайтах. Система сборки OE определяет окончательный размер создаваемого образа с учетом начального диска, используемого для образа, запрошенного размера образа и запрошенного свободного пространства после загрузки образа. Псевдокод для определения размера можно представить в виде

    if (image-du * overhead) < rootfs-size:
        internal-rootfs-size = rootfs-size + xspace
    else:
        internal-rootfs-size = (image-du * overhead) + xspace

где

image-du — значение, возвращаемое командой du для образа;

overhead — IMAGE_OVERHEAD_FACTOR;

rootfs-size — IMAGE_ROOTFS_SIZE;

internal-rootfs-size — начальный размер корневой файловой системы до каких-либо изменений;

xspace — IMAGE_ROOTFS_EXTRA_SPACE.

IMAGE_TYPEDEP

Указывает зависимость одного типа образа от другого, например, для образа из класса image-live
IMAGE_TYPEDEP_live = «ext3». В этом примере переменная обеспечивает включение live в переменную IMAGE_FSTYPES
и система сборки OE создает сначала образ ext3, поскольку одной из частей образа live является раздел формата ext3 с корневой файловой системой.

IMAGE_TYPES

Задает полный список поддерживаемых по умолчанию типов образов: btrfs, cpio, cpio.gz, cpio.lz4, cpio.lzma, cpio.xz, cramfs, elf, ext2, ext2.bz2, ext2.gz, ext2.lzma, ext3, ext3.gz, ext4, ext4.gz, hdddirect, hddimg, iso, jffs2, jffs2.sum, multiubi, squashfs, squashfs-lzo, squashfs-xz, tar, tar.bz2, tar.gz, tar.lz4, tar.xz, ubi, ubifs, wic, wic.bz2, wic.gz, wic.lzma.

Полная информация об этих типах приведена в файлах meta/classes/image_types*.bbclass дерева исходных кодов.

INC_PR

Помогает указать выпуск для заданий, использующих общий включаемый файл. Можно считать эту переменную частью варианта задания, устанавливаемой из включаемого файла.

Предположим, что имеется набор заданий, используемых в нескольких проектах, и для каждого из этих заданий задан выпуск (в переменной PR). В этом случае при изменении номера выпуска задания нужно найти все эти задания и убедиться в корректности обновления номера выпуска. Это может осложняться использованием заданий в разных местах, когда обновляются задания, обеспечивающие общую функциональность. Более эффективным способом в таких случаях является установка переменной INC_PR во включаемых файлах, совместно используемых заданиями, с последующим преобразованием переменной в заданиях для определения выпуска.

Ниже приведен пример использования переменной INC_PR с учетом общего включаемого файла, определяющего эту переменную. После ее указания во включаемом файле переменную можно
использовать для установки значений
PR в каждом задании. При установке PR для задания можно более точно указать выпуск, добавляя значение в конце переменной INC_PR,
как
показано ниже.

     recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
     recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
     recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
     recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"

Первая строка в этом примере показывает базовый номер выпуска, используемый всеми заданиями, которые применяют включаемый файл. Остальные строки уточняют выпуски для отдельных заданий, устанавливая PR.

INCOMPATIBLE_LICENSE

Задает список разделенных пробелами имен лицензий (как в переменной LICENSE), которые следует исключить при сборке. Значения, не содержащие замены исключенных лицензий, собираться не будут, пакеты, с несовместимыми лицензиями будут удалены. Эта функциональность регулярно проверяется лишь для INCOMPATIBLE_LICENSE = «GPL-3.0 LGPL-3.0 AGPL-3.0». Ваши установки могут отличаться, но все равно может потребоваться указание несовместимых лицензий или замен для создания образа.

INHERIT

Задает глобальное наследование указанных классов. Анонимные функции классов не выполняются для базовой конфигурации и в каждом отдельном задании. Система сборки OE игнорирует изменение переменной INHERIT в отдельных заданиях. Дополнительная информация приведена в разделе INHERIT Configuration Directive [4].

INHERIT_DISTRO

Указывает классы, которые будут наследоваться на уровне дистрибутива. Обычно менять эту переменную не требуется. Используемое по умолчанию значение переменной задано в файле meta/conf/distro/defaultsetup.conf как INHERIT_DISTRO ?= «debian devshell sstate license».

INHIBIT_DEFAULT_DEPS

Предотвращает добавление заданных по умолчанию зависимостей (компилятор C и стандартная библиотека libc) в DEPENDS. Переменная обычно применяется в заданиях, которым не нужен компилятор C. Установка значения 1 предотвращает добавление принятых по умолчанию зависимостей.

INHIBIT_PACKAGE_DEBUG_SPLIT

Установка значения 1 в этой переменной предотвращает отделение отладочной информации при подготовке пакетов. По умолчанию система сборки отделяет отладочную информацию в процессе выполнения задачи do_package
(см. описание PACKAGE_DEBUG_SPLIT_STYLE).

INHIBIT_PACKAGE_STRIP

Установка значения 1 отменяет удаление системой сборки символов из собранных пакетов и предотвращает включение исходных файлов в пакеты -dbg. По умолчанию система сборки OE вырезает символы из двоичных файлов и помещает отладочные символы в ${PN}-dbg. Поэтому не следует устанавливать переменную INHIBIT_PACKAGE_STRIP,
если
планируется отладка
.

INHIBIT_SYSROOT_STRIP

Установка значения 1 отменяет удаление системой сборки символов из двоичных файлов sysroot, выполняемое по умолчанию. Для использования переменной в задании нужно включить класс staging, который применяет функцию sys_strip() для проверки значения переменной и выполнения нужных действий.

Переменная применяется редко. Примером может служить создание прошивки для пустой платформы (bare-metal) с использованием внешних инструментов GCC. Более того, даже при вырезании информации из двоичных файлов инструментария остаются другие файлы, которые нужны для сборки и не вырезаются.

INITRAMFS_FSTYPES

Задает формат выходного образа initramfs, используемого при загрузке. Поддерживаемые форматы совпадают с возможными форматами IMAGE_FSTYPES. По умолчанию в файле meta/conf/bitbake.conf для этой переменной задается значение cpio.gz. Механизм initramfs в Linux в отличие от initrd предполагает возможность сжатия образа.

INITRAMFS_IMAGE

Задает имя задания (PROVIDES) для образа, используемое при сборке образа initramfs. Иными словами, переменная вызывает дополнительное задание для сборки как зависимость от используемого для корневой файловой системы задания (например, core-image-sato). Представленное задание для образа initramfs должно устанавливать в IMAGE_FSTYPES значение INITRAMFS_FSTYPES.

Образ обеспечивает временную корневую файловую систему, используемую для начальной инициализации (например, загрузки модулей, требуемых для монтирования реальной корневой файловой системы). В файле meta/recipes-core/images/core-image-minimal-initramfs.bb дерева исходных кодов приведен пример задания initramfs. Для выбора этого образца в качестве задания для образа initramfs нужно установить в переменной INITRAMFS_IMAGE значение core-image-minimal-initramfs. Использование переменной INITRAMFS_IMAGE рассмотрено в файле meta-poky/conf/local.conf.sample.extended, а также в описании классов image и kernel.

Если значение переменной INITRAMFS_IMAGE пусто (принято по умолчанию), образ initramfs не создается.

Переменная INITRAMFS_IMAGE_BUNDLE позволяет связать генерируемый образ с образом ядра. Сведения о создании образов initramfs приведены в разделе Building an Initial RAM Filesystem (initramfs) Image [2].

INITRAMFS_IMAGE_BUNDLE

Управляет дополнительным проходом do_bundle_initramfs при компиляции ядра для образа, заданного переменной INITRAMFS_IMAGE, с целью создания одного двоичного файла с образами ядра и initramfs. Для этого используется свойство ядра CONFIG_INITRAMFS_SOURCE.

Дополнительный проход компиляции для связывания initramfs предотвращает зацикливание зависимостей между заданиями для ядра и initramfs, когда initramfs включает модули ядра. В таких случаях задание initramfs зависит от ядра для получения модулей, а ядро зависит от initramfs, поскольку initramfs встраивается в образ ябра.

Объединенный двоичный файл размещается в каталоге tmp/deploy внутри каталога сборки.

Установка INITRAMFS_IMAGE_BUNDLE = «1» в конфигурационном файле системы сборки OE ведет к генерации образа ядра с initramfs, указанной в INITRAMFS_IMAGE. По умолчанию класс kernel устанавливает пустое значение INITRAMFS_IMAGE_BUNDLE ?= «».

Переменная должна указываться в конфигурационном файле, а не в файле задания. Дополнительная информация приведена в файле local.conf.sample.extended, а создание initramfs описано в разделе Building an Initial RAM Filesystem (initramfs) Image [2].

INITRAMFS_LINK_NAME

Имя ссылки для исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass как INITRAMFS_LINK_NAME ?= «initramfs-${KERNEL_ARTIFACT_LINK_NAME}». Этот же файл задает переменную KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

INITRAMFS_NAME

Базовое имя исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass как INITRAMFS_NAME ?= «initramfs-${KERNEL_ARTIFACT_NAME}». Этот же файл задает KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

INITRD

Задает список файловых систем для конкатенации и использования в качестве исходного RAM-диска (initrd). Переменная не обязательна и применяется классом image-live.

INITRD_IMAGE

При сборке загружаемых образов live (IMAGE_FSTYPES содержит live) переменная задает задание для образа, которое следует собрать для создания образа исходного RAM-диска. По умолчанию задано значение core-image-minimal-initramfs (см. параграф 6.53. image-live.bbclass).

INITSCRIPT_NAME

Имя файла со сценарием инициализации, установленное в ${sysconfdir}/init.d. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass,
и
является обязательной
.

INITSCRIPT_PACKAGES

Список пакетов, содержащих сценарии инициализации. При задании нескольких пакетов нужно добавлять имя пакета в конце к другим INITSCRIPT_* как переопределение. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass. Переменная не обязательна и по умолчанию имеет значение переменной PN.

INITSCRIPT_PARAMS

Задает опции для передачи update-rc.d. Например, INITSCRIPT_PARAMS = «start 99 5 2 . stop 20 0 1 6 .» указывает сценарий с уровнем запуска (runlevel) 99, запускаемый на уровнях 2 и 5, останавливаемый на уровнях 0, 1 и 6.

По умолчанию переменная имеет значение defaults, устанавливаемое классом update-rc.d. Значение переменной передается через команду update-rc.d. Дополнительная информация доступна по ссылке.

INSANE_SKIP

Задает проверки QA, пропускаемые для конкретного пакета в задании. Например, для пропуска проверки символьных ссылок для файлов .so в основном пакете задания в это задание добавляется приведенная ниже переменная. Следует указывать переопределенное имя задания (в примере ${PN}).

     INSANE_SKIP_${PN} += "dev-so"

Список проверок QA, которые можно указать в этой переменной, приведен в параграфе 6.56. insane.bbclass.

INSTALL_TIMEZONE_FILE

По умолчанию задание tzdata включает файл /etc/timezone. Установка INSTALL_TIMEZONE_FILE = 0 на уровне конфигурации отменяет это.

IPK_FEED_URIS

При использовании менеджера IPK и включенном на целевой платформе управлении пакетами эта переменная может служить для установки opkg в целевом образе с целью указания источника пакетов на означенном сервере. После организации источника можно устанавливать и обновлять пакеты при работе платформы.

K

KARCH

Указывает архитектуру ядра, применяемую для сборки конфигурации — powerpc, i386, x86_64, arm, qemu, mips. Переменная KARCH определяется в описаниях BSP [3].

KBRANCH

Регулярное выражение, применяемое процессом сборки для явного указания ветви ядра, которая проверяется, изменяется (patch) и настраивается в процессе сборки. Нужно задать эту переменную для точного выбора ветви ядра, используемой в процессе сборки.

Значение этой переменной устанавливается в наборе заданий и файле добавления для ядра. Например, для ядра linux-yocto_4.12 файлом задания является meta/recipes-kernel/linux/linux-yocto_4.12.bb. Переменная KBRANCH в этом файле задается в форме

     KBRANCH ?= "standard/base"

Переменная применяется также из файла добавления для ядра, чтобы указать конкретную ветвь ядра для целевой платы или оборудования. В предыдущем примере файл добавления для ядра (linux-yocto_4.12.bbappend) размещается на уровне BSP для данной машины. Например, файл добавления для Beaglebone, EdgeRouter и базовых версий 32- и 64-битовых машин IA (meta-yocto-bsp) называется meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend. Ниже приведены операторы и этого файла.

     KBRANCH_genericx86  = "standard/base"
     KBRANCH_genericx86-64  = "standard/base"
     KBRANCH_edgerouter = "standard/edgerouter"
     KBRANCH_beaglebone = "standard/beaglebone"
     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"

Операторы KBRANCH указывают ветвь ядра, которая будет использоваться при сборке для каждого BSP.

KBUILD_DEFCONFIG

При использовании с классом kernel-yocto задает размещенный в дереве исходных кодов ядра конфигурационный файл для использования при сборке ядра. Обычно при использовании файла defconfig для настройки конфигурации ядра при сборке файл помещается в каталог вашего уровня как и файлы исправлений, а также файлы с фрагментами конфигурации. Однако если вы хотите использовать файл defconfig как часть дерева ядра, можно воспользоваться переменной KBUILD_DEFCONFIG и добавить переменную KMACHINE для указания файла defconfig.

Для использования переменной следует указать ее в файле добавления для задания ядра в виде KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file. Например, для сборки raspberrypi2 KMACHINE с файлом defconfig, названным bcm2709_defconfig, служит KBUILD_DEFCONFIG_raspberrypi2 = «bcm2709_defconfig».

Как вариант, можно указать в файле добавления KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file.

Информация об использовании KBUILD_DEFCONFIG приведена в разделе Using an «In-Tree» defconfig File [3].

KERNEL_ALT_IMAGETYPE

Задает другой тип образа ядра в дополнение к типу, указанному переменной KERNEL_IMAGETYPE.

KERNEL_ARTIFACT_NAME

Указывает имя для всех элементов сборки (artifact). Значение переменной задается в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}». Дополнительная информация приведена в описаниях переменных PKGE, PKGV, PKGR и MACHINE. Для переменной IMAGE_VERSION_SUFFIX устанавливается значение DATETIME.

KERNEL_CLASSES

Список классов, определяющих типы образов ядра, которые должен наследовать класс kernel. Обычно эта переменная добавляется для включения расширенных типов образов. Примером является класс kernel-fitimage, включающий поддержку fitImage и заданный в файле meta/classes/kernel-fitimage.bbclass. Можно зарегистрировать свои типы образов ядра с помощью этой переменной.

KERNEL_DEVICETREE

Задает имя создаваемого файла с деревом устройств ядра Linux (.dtb). Имеется устаревший способ указания полного пути к дереву устройств, однако предпочтительней использовать файл .dtb. Для использования переменной нужно указать включаемые файлы в задании для ядра в форме require recipes-kernel/linux/linux-dtb.inc или require recipes-kernel/linux/linux-yocto.inc.

KERNEL_DTB_LINK_NAME

Имя ссылки на двоичное дерево устройств (DTB6) в файле meta/classes/kernel-artifact-names.bbclass, указанное как KERNEL_DTB_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». Переменная KERNEL_ARTIFACT_LINK_NAME в
том же файле
имеет форму KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_DTB_NAME

Базовое имя DTB, задаваемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_DTB_NAME ?= «${KERNEL_ARTIFACT_NAME}». Переменная KERNEL_ARTIFACT_NAME в том же файле имеет форму KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

KERNEL_EXTRA_ARGS

Задает дополнительные аргументы команды make, которые система сборки OE использует при компиляции ядра.

KERNEL_FEATURES

Включает дополнительные метаданные ядра. В системе сборки OE принятые по умолчанию метаданные BSP обеспечиваются переменными KMACHINE и KBRANCH. Можно использовать переменную KERNEL_FEATURES из задания или файла добавления для ядра, чтобы добавить метаданные для всех или определенных BSP.

Добавляемые через эту переменную метаданные включают фрагменты конфигурации и описания функций, которые обычно включают исправления (patch), а также фрагменты конфигурации. Переменная KERNEL_FEATURES обычно переопределяется для конкретной машины. Таким способом обеспечивается проверяемый, но не обязательный набор функций и конфигурационных параметров ядра.

Например, можно в задание linux-yocto-rt_4.добавить
функции
netfilter и taskstats для всех BSP, а также конфигурации virtio для всех машин QEMU. Два последних оператора добавляют конкретные конфигурации к целевым типам машин.

KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc"
KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc"

KERNEL_FIT_LINK_NAME

Имя ссылки на плоское дерево образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass
как KERNEL_FIT_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». В том же файле указывается переменная KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_FIT_NAME

Базовое имя плоского дерева образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_FIT_NAME ?= «${KERNEL_ARTIFACT_NAME}». В этом же файле устанавливается переменная KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

KERNEL_IMAGE_LINK_NAME

Имя ссылки для образа ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_IMAGE_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». В том же файле файле устанавливается переменная KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_IMAGE_MAXSIZE

Задает максимальный размер образа ядра в килобайтах. При установке переменной размер ядра сравнивается с ее значением при выполнении задачи do_sizecheck
с
возвратом ошибки в случае превышения
заданного размера
. Переменная полезна для систем с ограниченным пространством для хранения образа ядра. По умолчанию переменная не устанавливается и размер ядра не ограничен.

KERNEL_IMAGE_NAME

Базовое имя образа ядра. Переменная задается файлом meta/classes/kernel-artifact-names.bbclass в форме KERNEL_IMAGE_NAME ?= «${KERNEL_ARTIFACT_NAME}». Значение переменной KERNEL_ARTIFACT_NAME
в
том же файле имеет форму
KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

KERNEL_IMAGETYPE

Тип ядра, собираемого для устройства, который обычно задается конфигурационными файлами для машины. По умолчанию применяется zImage. Эта переменная используется при сборке ядра и передается команде make как цель сборки. Для сборки дополнительного типа образа используется переменная KERNEL_ALT_IMAGETYPE.

KERNEL_MODULE_AUTOLOAD

Указывает модули ядра, которые нужно автоматически загружать при загрузке системы. Переменную можно использовать в любом месте, доступном заданию для ядра или внешнего (out-of-tree) модуля (например, в файле конфигурации машины или дистрибутива, файле дополнения к заданию или самом задании).

KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"

Включение KERNEL_MODULE_AUTOLOAD заставляет систему сборки OE указать список автоматически загружаемых модулей в файле /etc/modules-load.d/modname.conf. Модули указываются по одному в строке, например, KERNEL_MODULE_AUTOLOAD += «module_name«.

Информация о заполнении файла modname.conf в синтаксисом modprobe.d приведена в описании переменной KERNEL_MODULE_PROBECONF.

KERNEL_MODULE_PROBECONF

Задает список модулей, для которых система сборки OE предполагает найти значения module_conf_modname,
задающие
конфигурацию каждого модуля. Информация
о настройке модулей приведена в описании
переменн
ой
module_conf.

KERNEL_PATH

Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].

Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_SRC, которая идентична KERNEL_PATH
. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.

KERNEL_SRC

Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].

Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_PATH, которая идентична KERNEL_SRC. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.

KERNEL_VERSION

Указывает версию ядра, извлеченную из файла version.h или utsrelease.h в дереве кода ядра. Установка этой переменной не оказывает влияния, пока не будет настроена конфигурация ядра, поэтому попытка обращения к ней до настройки конфигурации не приведет к желаемому результату.

KERNELDEPMODDEPEND

Указывает, нужны ли данные, упомянутые в переменной PKGDATA_DIR. KERNELDEPMODDEPEND контролирует не наличие этих данных, а их использование. Если данные не нужны, укажите KERNELDEPMODDEPEND в задании initramfs, это позволит предотвратить возможное зацикливание зависимостей.

KFEATURE_DESCRIPTION

Дает краткое описание фрагмента конфигурации. Эта переменная применяется в файлах .scc, описывающих файлы с фрагментами конфигурации. Например, в файле в файле smp.scc эта переменная включает опции SMP в форме define KFEATURE_DESCRIPTION «Enable SMP».

KMACHINE

Машина, известная ядру. Иногда используемое ядром имя машины не совпадает с именем в системе сборки OE. Например, имя машины, которое система OE воспринимает как core2-32-intel-common, будет иным в ядре Linux Yocto (intel-core2-32). Для таких случаев переменная KMACHINE сопоставляет имена машины в ядре и системе сборки OE.

Эти сопоставления выполняются в ветвях метаданных ядер Yocto Linux. В качестве примера рассмотрим файл common/recipes-kernel/linux/linux-yocto_3.19.bbappend.

     LINUX_VERSION_core2-32-intel-common = "3.19.0"
     COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
     SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
     SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
     KMACHINE_core2-32-intel-common = "intel-core2-32"
     KBRANCH_core2-32-intel-common = "standard/base"
     KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"

Оператор KMACHINE говорит, что ядро воспринимает имя машины как intel-core2-32, однако система сборки OE именует ее как core2-32-intel-common.

KTYPE

Определяет тип ядра, используемый при сборке конфигурации. Задания linux-yocto определяют типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Переменная KTYPE задается в описании BSP, а ее значение должно соответствовать значению переменной LINUX_KERNEL_TYPE в задании для ядра.

L

LABELS

Указывает список целей для автоматической настройки конфигурации. Использование переменной рассмотрено в описании класса grub-efi.

LAYERDEPENDS

Список разделенных пробелами уровней, от которых зависит данный уровень. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERDEPENDS_mylayer = «anotherlayer (=3)», где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная
указывается в файле
conf/layer.conf
и
должна иметь суффикс в виде имени
конкретного уровня (например,
LAYERDEPENDS_mylayer).

LAYERDIR

При использовании в файле layer.conf указывает путь к текущему уровню. Переменная не доступна за пределами layer.conf и ссылки разыменовываются сразу по завершении разбора файла.

LAYERRECOMMENDS

Список разделенных пробелами уровней, рекомендованных для использования с данным уровнем. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERRECOMMENDS_mylayer = «anotherlayer (=3)», где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная указывается в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERRECOMMENDS_mylayer).

LAYERSERIES_COMPAT

Перечисляет версии OpenEmbedded-Core, с которыми совместим уровень. Переменная LAYERSERIES_COMPAT позволяет указать, какие комбинации уровня и OE-Core предполагаются работоспособными. Переменная позволяет системе определить, когда уровень не будет проверяться с новыми выпусками OE-Core (например, не поддерживается).

Для указания версии OE-Core, с которой совместим уровень, используется эта переменная в файле conf/layer.conf. Для указания версии используйте имя выпуска YP (например, warrior). При указании нескольких версий OE-Core для уровня они разделяются пробелами, как показано ниже.

LAYERSERIES_COMPAT_layer_root_name = "warrior thud"

Установка LAYERSERIES_COMPAT требуется стандартом Yocto Project Compatible версии 2. Система сборки OE выдает предупреждения, если переменная не установлена для уровня.

LAYERVERSION

Опционально задает версию уровня одним числом. Можно использовать это значение в LAYERDEPENDS для другого уровня для указания зависимости от конкретной версии уровня. Переменная применяется в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERVERSION_mylayer).

LD

Сокращенная команда и аргументы для запуска компоновщика.

LDFLAGS

Задает флаги, передаваемые компоновщику. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятое по умолчанию значение LDFLAGS зависит от собираемого объекта:

  • TARGET_LDFLAGS при сборке для целевой платформы;
  • BUILD_LDFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_LDFLAGS при сборке для SDK (nativesdk-).

LEAD_SONAME

Задает основной (первичный) файл скомпилированной библиотеки (.so), к которому класс debian применяет свои правила именования в образах с множеством библиотек. Переменная применяется с классам debian.

LIC_FILES_CHKSUM

Контрольная сумма текста лицензии в исходном коде задания для отслеживания изменений в тексте. Если текст лицензии будет изменен, это приведет к отказу сборки, указывающему разработчику просмотреть изменение в тексте. Эта переменная должна указываться для всех заданий, кроме тех, где установлено LICENSE = CLOSED. Дополнительную информацию о лицензировании можно найти в разделе Tracking License Changes [2].

LICENSE

Список лицензий для задания в соответствии с приведенными ниже правилами:

  • не допускаются пробелы в именах лицензий;
  • имена лицензий разделяются символом | при возможности выбора лицензии;
  • имена лицензий разделяются символом & (амперсанд) при наличии нескольких лицензий для разных частей кода;
  • между именами лицензий можно использовать символы пробела;
  • для стандартных лицензий применяются имена из файла meta/files/common-licenses/ или имена флагов SPDXLICENSEMAP,
    заданные
    в файле
    meta/conf/licenses.conf.

Ниже приведено несколько примеров.

     LICENSE = "LGPLv2.1 | GPLv3"
     LICENSE = "MPL-1 & LGPLv2.1"
     LICENSE = "GPLv2+"

Первый пример взят из заданий для Qt, распространяемых по лицензии LGPL версии 2.1 или GPL версии 3. Во втором примере представлено лицензирование Cairo, где применяются две лицензии для разных частей кода. Последний пример взят из sysstat, где используется одна лицензия.

Можно также задавать лицензии на уровне пакета для случаев использования компонентами разных лицензий. Например, если часть кода распространяется по лицензии GPLv2, но сопровождается документацией, которая использует лицензию GNU FDL7 1.2, можно указать

     LICENSE = "GFDL-1.2 & GPLv2"
     LICENSE_${PN} = "GPLv2"
     LICENSE_${PN}-doc = "GFDL-1.2"

LICENSE_CREATE_PACKAGE

Установка LICENSE_CREATE_PACKAGE = 1 заставляет систему сборки OE создавать дополнительный пакет (${PN}-lic)ого задания и добавлять эти пакеты в переменную RRECOMMENDS_${PN}.

Пакет ${PN}-lic создает каталог /usr/share/licenses с именем ${PN} (базовое имя задания) и помещает в него файлы с лицензией и информацией об авторских правах (т. е. копии подходящих лицензий из meta/common-licenses, соответствующие лицензиям, указанным в переменной LICENSE метаданных задания, и копии файлов, указанных в LIC_FILES_CHKSUM как файлы с текстами лицензий).

Дополнительная информация о предоставлении текстов лицензий приведена в описаниях переменных COPY_LIC_DIRS и COPY_LIC_MANIFEST, а также в разделе Providing License Text [2].

LICENSE_FLAGS

Перечисляет для задания дополнительные флаги, которые следует включить в LICENSE_FLAGS_WHITELIST, чтобы задание можно было собрать. Флаги в списке разделяются пробелами. Это значение не зависит от LICENSE и обычно применяется для маркировки заданий, которым могут требоваться дополнительные лицензии для использования в коммерческой продукции. Дополнительная информация о лицензировании приведена в разделе Enabling Commercially Licensed Recipes [2].

LICENSE_FLAGS_WHITELIST

Перечисляет флаги лицензий, которым при указании в LICENSE_FLAGS для задания, не следует препятствовать в сборке. Это иногда называют «белым списком» лицензий. Дополнительная информация о лицензировании приведена в разделе Enabling Commercially Licensed Recipes [2].

LICENSE_PATH

Путь к дополнительным лицензиям, используемым при сборке. По умолчанию система сборки OE применяет COMMON_LICENSE_DIR для определения каталога с общим текстом лицензии, используемой при сборке. Эта переменная позволяет добавить каталоги в форме LICENSE_PATH += «path-to-additional-common-licenses«.

LINUX_KERNEL_TYPE

Определяет тип ядра, применяемый при сборке конфигурации. В заданиях linux-yocto определены типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Если переменная LINUX_KERNEL_TYPE не задана, применяется тип standard. Вместе с переменной KMACHINE значение LINUX_KERNEL_TYPE определяет аргументы поиска, применяемые инструментами ядра при поиске подходящего описания в метаданных ядра для определения исходных файлов и конфигурации.

LINUX_VERSION

Версия Linux с сайта kernel.org, для которой будет собираться образ ядра с помощью системы OE. Эта переменная указывается в задании для ядра. Например, задание linux-yocto-3.4.bb из каталога meta/recipes-kernel/linux определяет переменную

     LINUX_VERSION ?= "3.4.24"

Значение LINUX_VERSION используется при определении переменной PV для задания

     PV = "${LINUX_VERSION}+git${SRCPV}"

LINUX_VERSION_EXTENSION

Строка расширения, компилируемая в строку версии ядра Linux, собираемого в системе OE. Эта переменная указывается в задании для ядра. Например, задание определяет ее как

     LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"

Определение этой переменной по существу задает значение конфигурационного параметра ядра CONFIG_LOCALVERSION, которое доступно по команде uname. Ниже приведен пример вывода команды.

     $ uname -r
     3.7.0-rc8-custom

LOG_DIR

Задает каталог, в который система сборки OE записывает log-файлы (по умолчанию ${TMPDIR}/log). Каталоги с журналами для каждой задачи задаются с помощью переменной T.

M

MACHINE

Задает целевое устройство, для которого собирается ядро. Переменная указывается в файле local.conf каталога сборки. По умолчанию задан архитектура x86, эмулируемая с помощью QEMU, как MACHINE ?= «qemux86». Переменная соответствует одноименному файлу конфигурации машины, в котором установлена конфигурация для нее. Таким образом, при установке qemux86 будет в наличии файл qemux86.conf, хранящийся в каталоге исходных кодов (подкаталог meta/conf/machine). Ниже приведен список машин, включенных в дистрибутив YP.

     MACHINE ?= "qemuarm"
     MACHINE ?= "qemuarm64"
     MACHINE ?= "qemumips"
     MACHINE ?= "qemumips64"
     MACHINE ?= "qemuppc"
     MACHINE ?= "qemux86"
     MACHINE ?= "qemux86-64"
     MACHINE ?= "genericx86"
     MACHINE ?= "genericx86-64"
     MACHINE ?= "beaglebone"
     MACHINE ?= "mpc8315e-rdb"
     MACHINE ?= "edgerouter"

Последние 5 ссылок относятся к эталонным платам YP уровня meta-yocto-bsp. Возможна установка в переменной значений, обеспечиваемых дополнительными уровнями BSP.

MACHINE_ARCH

Задает архитектуру конкретной машины и устанавливается автоматически из переменной MACHINE или TUNE_PKGARCH. Не следует менять значение MACHINE_ARCH
вручную.

MACHINE_ESSENTIAL_EXTRA_RDEPENDS

Зависящий от машины список обязательных пакетов для установки в создаваемый образ. Процесс сборки зависит от наличия этих пакетов. Кроме того, поскольку эти пакеты важны для машины, без них она может не загрузиться. Переменная влияет на образы, основанные на packagegroup-core-boot, включая образ core-image-minimal.

Эта переменная похожа на MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS,
но
сборка создаваемого образа зависит от
сборки пакетов из списка. При отсутствии
нужных пакетов сборка станет невозможной
.

В качестве примера рассмотрим машину, для которой нужно во время загрузки запускать пакет example-init для инициализации оборудования. В этом случае файл конфигурации для машины (.conf)
должен включать строку

     MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

Список зависимых от машины пакетов для включения в собираемый образ. Процесс сборки не зависит от наличия этих пакетов. Однако эти пакеты важны для загрузки машины. Переменная влияет на образы, основанные на packagegroup-core-boot, включая образ core-image-minimal.

Эта переменная похожа на MACHINE_ESSENTIAL_EXTRA_RDEPENDS,
но
сборка образа не зависит от сборки
пакетов из списка, т. е. при отсутствии
пакета образ все равно будет собран.
Обычно эта переменная служит для
управления важными компонентами ядра,
которые могут встраиваться непосредственно
в ядро (не модуль) и тогда пакет создаваться
не будет
.

Рассмотрим пример с пользовательским ядром, где нужен драйвер для определенного сенсорного экрана, чтобы использовать машину. Драйвер может быть встроен в ядро или собран как модуль в зависимости от конфигурации. При сборке драйвера в виде модуля его нужно установить, но хочется, чтобы сборка выполнялась и для случая встраивания драйвера в ядро. Данная переменная устанавливает отношение «рекомендации» и во втором случае сборка не будет прерываться в случае отсутствия пакета. Для модуля kernel-module-ab123
в файл конфигурации машины включается
строка
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += «kernel-module-ab123».

В этом примере задание kernel-module-ab123 должно явно установить свою переменную PACKAGES,
чтобы
BitBake не использовал переменную PACKAGES_DYNAMIC из задания ядра для соблюдения зависимости.

Примерами таких устройств являются драйверы флэш-памяти, экрана, клавиатуры, мыши или сенсорного экрана.

MACHINE_EXTRA_RDEPENDS

Список машинозависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины, но сборка образа зависит от этих пакетов. Переменная влияет лишь на образы, основанные на packagegroup-base, которые не включают core-image-minimal и core-image-full-cmdline. Переменная похожа на MACHINE_EXTRA_RRECOMMENDS, но отличается тем, что сборка образа зависит
от указанных в ней пакетов.

Примером может служить машина с поддержкой WiFi, которая не существенна для загрузки. Однако при сборке более функционального образа может потребоваться WiFi. В этом случае предполагается наличие пакета с микрокодом WiFi, поэтому логична зависимость процесса сборки от наличия этого пакета. Для решения этой задачи (в предположении, что пакет называется wifidriver-firmware) следует включить в файл .conf для машины строку MACHINE_EXTRA_RDEPENDS += «wifidriver-firmware».

MACHINE_EXTRA_RRECOMMENDS

Список машинозависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины и сборка образа не зависит от этих пакетов. Переменная влияет лишь на образы, основанные на packagegroup-base, которые не включают core-image-minimal и core-image-full-cmdline. Переменная похожа на MACHINE_EXTRA_RDEPENDS, но отличается тем, что сборка образа не зависит от указанных в ней пакетов.

Примером может служить машина с поддержкой WiFi, которая не существенна для загрузки. Однако при сборке более функционального образа может потребоваться WiFi. В этом случае пакет с модулем WiFi для ядра не будет создаваться, если драйвер встроен в ядро, но нужно выполнение сборки без ошибок, несмотря на отсутствие пакета. Для решения этой задачи (в предположении, что пакет называется kernel-module-examplewifi) следует включить в файл .conf для машины строку MACHINE_EXTRA_RRECOMMENDS += «kernel-module-examplewifi».

MACHINE_FEATURES

Задает список аппаратных функций, которые MACHINE может поддерживать. Включение дополнительных свойств управляется переменными DISTRO_FEATURES, COMBINED_FEATURES и IMAGE_FEATURES. Список аппаратных возможностей, поддерживаемых YP, приведен в параграфе 12.1. Свойства машины.

MACHINE_FEATURES_BACKFILL

Свойства, добавляемые в MACHINE_FEATURES при их отсутствии в переменной MACHINE_FEATURES_BACKFILL_CONSIDERED. Эта переменная задана в файле meta/conf/bitbake.conf и не предназначена для настройки пользователем. О сослаться на переменную для просмотра функций, «засыпанных» в конфигурации всех машин (см. параграф 12.4. Отключение автоматически добавляемых свойств).

MACHINE_FEATURES_BACKFILL_CONSIDERED

Свойства из MACHINE_FEATURES_BACKFILL, которые не следует добавлять в MACHINE_FEATURES при сборке (см. параграф 12.4. Отключение автоматически добавляемых свойств).

MACHINEOVERRIDES

Разделенный двоеточиями список переопределений, применяемых для конкретной машины. По умолчанию этот список включает значение переменной MACHINE.

Переменную MACHINEOVERRIDES можно расширить добавляя переопределения, применяемые к машине. Например, все машины, эмулируемые в QEMU (qemuarm, qemux86 и т. п.), включают файл meta/conf/machine/include/qemu.inc, который добавляет значение в начало переменной MACHINEOVERRIDES =. «qemuall:». Это позволяет переопределять переменные для всех машин, эмулируемых в QEMU, как показано в примере из задания connman-conf.

     SRC_URI_append_qemuall = "file://wired.config \
                               file://wired-setup \
                              "   

Базовым механизмом для MACHINEOVERRIDES является включение в значение по умолчанию переменной OVERRIDES.

MAINTAINER

Адрес электронной почты для поддержки дистрибутива.

MIRRORS

Задает дополнительные пути для поиска исходных кодов системой сборки OE, которая сначала пытается найти коды в локальном каталоге загрузки. При отсутствии кодов в этом каталоге система просматривает репозитории, указанные переменной PREMIRRORS, затем «восходящий источник» и репозитории, указанные переменной MIRRORS. В дистрибутиве (DISTRO) poky принятое по умолчанию значение MIRRORS указано в файле conf/distro/poky.conf репозитория meta-poky.

MLPREFIX

Задает префикс, добавляемый к переменной PN для получения специальной версии задания или пакета (версии Multilib). Переменная применяется там, где нужно добавить или удалить префикс переменной (например, BPN). MLPREFIX устанавливается при наличии префикса у переменной PN.

ML в имени MLPREFIX означает MultiLib. Это возникло в то время, когда строка nativesdk служила суффиксом, а не префиксом имени задания. Префикс nativesdk учитывается в MLPREFIX.

Для разъяснения случаев применения MLPREFIX рассмотрим пример с использованием BBCLASSEXTEND для обеспечения версии задания nativesdk в дополнении к версии для целевой платформы. Если это задание заявляет зависимость при сборке от других заданий с помощью переменной DEPENDS, то зависимость от foo будет автоматически переопределяться в зависимость от nativesdk-foo. Однако зависимости вида do_foo[depends] += «recipe:do_foo» не будут переопределяться автоматически. Если нужно переопределение таких зависимостей, можно указать do_foo[depends] += «${MLPREFIX}recipe:do_foo».

module_autoload

Переменная заменена KERNEL_MODULE_AUTOLOAD,
поэтому
следует
отредактировать
все
файлы, включающие ее. Например,
module_autoload_rfcomm = «rfcomm» заменить на KERNEL_MODULE_AUTOLOAD += «rfcomm».

module_conf

Задает строки с синтаксисом modprobe.d для включения в файл /etc/modprobe.d/modname.conf. Эту переменную можно использовать в любом месте, доступном заданию для ядра или внешнего (out-of-tree) модуля (например, в файле конфигурации машины или дистрибутива, файле дополнения к заданию или самом задании). При использовании переменной нужно также перечислить модули ядра в переменной KERNEL_MODULE_AUTOLOAD.

Базовый синтаксис переменной имеет вид module_conf_module_name = «modprobe.d-syntax«. Нужно применять переопределение имен модулей ядра.

Включение module_conf заставляет систему сборки OE заполнять файл /etc/modprobe.d/modname.conf строками с синтаксисом modprobe.d (информацию о синтаксисе можно
получить по команде man modprobe.d
). Например, добавление опций arg1 и arg2 для модуля mymodule
может
иметь вид
module_conf_mymodule = «options mymodule arg1=val1 arg2=val2».

Автоматическая загрузка модулей ядра управляется переменной KERNEL_MODULE_AUTOLOAD.

MODULE_TARBALL_DEPLOY

Управляет созданием файла modules-*.tgz
с
модулями ядра, созданны
ми
при сборке
(0 отменяет запись архива).

MODULE_TARBALL_LINK_NAME

Имя ссылки для архива модулей ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как MODULE_TARBALL_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». Для KERNEL_ARTIFACT_LINK_NAME
в
том же файле устанавливается значение
KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}»

MODULE_TARBALL_NAME

Базовое имя архива модулей ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass
как
MODULE_TARBALL_NAME ?= «${KERNEL_ARTIFACT_NAME}». Переменная KERNEL_ARTIFACT_NAME в том же файле получает значение KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

MULTIMACH_TARGET_SYS

Однозначно указывает тип целевой системы, для которой собираются пакеты. Переменная позволяет размещать вывод для разных целевых систем в разные подкаталоги одного выходного каталога. По умолчанию переменная имеет значение ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}. Некоторые классы (например, cross-canadian) меняют значение MULTIMACH_TARGET_SYS. Дополнительная информация приведена в описаниях переменных STAMP и STAGING_DIR_TARGET.

N

NATIVELSBSTRING

Строка, указывающая дистрибутив хоста. Строка включает идентификатор дистрибутива, за которым следует номер выпуска, возвращаемый командой lsb_release или прочитанный в файле /etc/lsb-release. Например, при работе на хосте Ubuntu 12.10 переменная будет иметь значение Ubuntu-12.10. Если дистрибутив определить не удается, переменная получает значение Unknown.

Переменная используется по умолчанию для разделения естественных пакетов разных дистрибутивов (например, для предотвращения проблем, связанный с несовместимостью версий glibc). Кроме того, эта переменная проверяется по SANITY_TESTED_DISTROS,
если
та установлена
.

NM

Сокращенная команда и аргументы для запуска nm
(просмотр
символ
ов
из объектных файлов)
.

NO_GENERIC_LICENSE

Предотвращает ошибки QA при использовании в задании необычной, незакрытой лицензии. Имеются пакеты, такие как linux-firmware, со множеством мало распространенных лицензий. Время от времени также появляются новые лицензии, чтобы избежать введения множества базовых лицензий, которые применимы к конкретному пакету. Переменная NO_GENERIC_LICENSE позволяет скопировать лицензию, которой нет в числе базовых. Например, в задание можно добавить лицензию NO_GENERIC_LICENSE to с помощью NO_GENERIC_LICENSE[license_name] = «license_file_in_fetched_source«. В приведенном ниже примере используется файл LICENSE.Abilis.txt file в качестве лицензии для извлеченного исходного кода.

     NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"

NO_RECOMMENDATIONS

Предотвращает установку пакетов, которые лишь рекомендованы (устанавливаются через переменную RRECOMMENDS). Например, NO_RECOMMENDATIONS = «1» включает эту функцию.

Переменную можно установить глобально в файле local.conf или присоединить к заданию для конкретного образа, переопределяя имя задания в виде NO_RECOMMENDATIONS_pn-target_image = «1».

Важно понимать, что при включении в эту переменную пакетов, от которых зависят другие пакеты (указаны в переменной RDEPENDS), система сборки OE будет игнорировать запрос и установит пакеты, чтобы не нарушать зависимостей.

Некоторые рекомендованные пакеты могут потребоваться для некоторых функций, таких как модули ядра. Вы можете указать такие пакеты в переменной IMAGE_INSTALL.

Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.

См. также описания переменных BAD_RECOMMENDATIONS и PACKAGE_EXCLUDE.

NOAUTOPACKAGEDEBUG

Выключает автоматическое выделение для пакета файлов .debug. Если задание требует установки FILES_${PN}-dbg вручную, можно задать переменную NOAUTOPACKAGEDEBUG,
позволяющую
определить содержимое отладочного
пакета. Например,

     NOAUTOPACKAGEDEBUG = "1"
     FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
     FILES_${PN}-dbg = "/usr/src/debug/"
     FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"

Продолжение


1Application Binary Interface — интерфейс двоичных приложений.

2Package Management System — система управления пакетами.

3Position Independent Executables — независимые от расположения исполняемые файлы.

4Return Oriented Programming — ориентированное на возвращаемое значение программирование.

5GNU GRand Unified Bootloader.

6Device tree binary.

7Free Documentation License — свободное распространение документации.

Рубрика: Linux | Комментарии к записи Справочник по Yocto Project (часть 3) отключены