Сетевые модульные тесты ядра

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

Зачем запускать тесты?

Эти тесты существуют по трем основным причинам:

  1. Точная версия ядра Linux, используемого на устройстве, обычно зависит от устройства, и трудно понять, будет ли какое-либо ядро ​​работать правильно, без запуска тестов.
  2. Перенос исправлений ядра на разные версии ядра или разные деревья устройств может вызвать тонкие проблемы, которые невозможно обнаружить без запуска тестов.
  3. Новые сетевые функции могут потребовать новых функций ядра или исправления ошибок ядра.

Если тесты не пройдены, сетевой стек устройства будет вести себя неправильно, вызывая заметные пользователю ошибки подключения (например, отключение сетей Wi-Fi). Устройство, скорее всего, также не пройдет тесты Android Compatibility Test Suite (CTS).

Использование тестов

В тестах используется пользовательский режим Linux для загрузки ядра как процесса на хост-компьютере Linux. См. Создание среды сборки для подходящих версий операционной системы. Среда модульного тестирования загружает ядро ​​с соответствующим образом диска и запускает тесты из файловой системы хоста. Тесты написаны на Python 2.x и используют интерфейсы TAP для проверки поведения ядра и API сокетов.

Компиляция ядра для ARCH=um

Для выполнения тестов ядро ​​должно скомпилироваться для ARCH=um SUBARCH=x86_64 . Это поддерживаемая архитектура как в основной ветке разработки, так и в общих деревьях ядра Android (например, android-4.4 ). Но иногда ядра устройств не компилируются в этом режиме, потому что деревья устройств содержат специфичный для устройства или оборудования код в общих файлах (например, sys/exit.c ).

Во многих случаях достаточно убедиться, что аппаратно-зависимый код находится за #ifdef . Обычно это должен быть #ifdef в параметре конфигурации, который управляет конкретной функцией, относящейся к коду. Если такой опции конфигурации нет, поместите аппаратно-зависимый код внутрь блоков #ifndef CONFIG_UML .

Как правило, исправление этого должно быть обязанностью поставщика дерева ядра (например, поставщика набора микросхем или SoC). Мы работаем с OEM-производителями и поставщиками, чтобы гарантировать, что текущие и будущие ядра будут компилироваться для ARCH=um SUBARCH=x86_64 без каких-либо изменений.

Запуск тестов

Тесты находятся в kernel/tests/net/test . Рекомендуется запускать тесты из мастера AOSP , поскольку они являются самыми последними; в некоторых случаях функции ядра, необходимые для правильной работы в данном выпуске Android, еще не имеют полного тестового покрытия в данном выпуске. Информацию о том, как запускать тесты, см. в файле README сетевого теста ядра . По сути, из верхней части дерева ядра запустите:

ANDROID_TREE/kernel/tests/net/test/run_net_test.sh all_tests.sh

Прохождение испытаний

Исходные файлы Python для сетевых тестов ядра содержат комментарии, определяющие фиксации ядра, которые, как известно, необходимы для прохождения тестов. Тесты должны проходить в общих деревьях ядра - все общие ветки ядра android-4.4 и выше - в проекте kernel/common в AOSP. Следовательно, прохождение тестов на ядре — это просто вопрос непрерывного слияния с соответствующей общей веткой ядра.

Содействие

Проблемы с отчетами

Сообщайте о любых проблемах с сетевыми тестами ядра в системе отслеживания проблем Android с пометкой Component-Networking .

Документирование коммитов и добавление тестов

Сообщайте о проблемах, как описано выше, и, если возможно, загрузите изменения для устранения проблемы, если:

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