Глава 8, Сборка и отладка

Эта глава разделена на две части. Первая половина посвящена среде сборки Linux. Это включает в себя:

▪Сборку ядра Linux

▪Сборку приложений пользовательского пространства

▪Сборку корневой файловой системы

▪Обсуждение популярных интегрированных сред разработки (Integrated Development Environment, IDE)

Вторая половина посвящена техникам отладки и профилирования для встраиваемого Linux. Это включает в себя:

▪Профилирование памяти

▪Отладка ядра и приложения

▪Профилирование приложения и ядра

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

Сборка ядра и приложения по отдельности имеет свои преимущества и недостатки. Основным преимуществом является то, что она проста в использовании. Если вы хотите добавить новое приложение, надо просто собрать это приложение и загрузить его на плату. Эта процедура проста и быстра. В этом отличие от большинства систем реального времени, где должен быть пересобран весь образ и система должна быть перезагружена. Тем не менее, основной недостаток процедуры раздельной сборки в том, что не существует автоматической взаимосвязи между функциями ядра и приложениями. Большинство разработчиков встраиваемых систем хотели бы иметь механизм сборки системы, когда конфигурация, выбранная для системы, отдельные компоненты (ядро, приложения и корневая файловая система), получается автоматически собранной вместе со всеми зависимостями. Однако, в Linux это не так. Сложность сборке добавляет необходимость сборки загрузчика и процесс упаковки корневой файловой системы в единый загружаемый образ.

Чтобы детально разобраться в этой проблеме, рассмотрим случай OEM поставщика, который поставляет два продукта: мост Ethernet и маршрутизатор, использующие одно и то же оборудование. Хотя большая часть программного обеспечения остаётся одной и той же (например, загрузчик, BSP, и тому подобное), различия в основных возможностях двух продуктов заключаются в программном обеспечении. В результате, OEM поставщик хотел бы сохранить единый базовый код для обоих продуктов, но чтобы программное обеспечение для системы собиралось в зависимости от выбранной системы (мост или маршрутизатор). Это, по сути, сводится к чему-то такому: по команде make bridge из каталога верхнего уровня должно быть выбрано программное обеспечение, необходимое для продукта "мост", и, аналогично, по команде make router должно быть собрано программное обеспечение для маршрутизатора. Для достижения этой цели придётся проделать много работы:

▪Соответствующим образом должно быть сконфигурировано ядро и должны быть выбраны соответствующие протоколы (такие, как spanning bridge для моста или IP-forwarding для маршрутизатора), драйверы, и так далее.

▪Соответствующим образом должны быть построены приложения пользовательского пространства (например, должна быть собрана служба маршрутизации).

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

▪Должны быть выбраны и упакованы в корневую файловую систему соответствующие файлы конфигурации (например, HTML файлы и CGI скрипты).

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

При выборе компонентов в процессе сборки необходима некоторая информация, так что может быть разработана платформа для сборки всей системы. Это может быть сделано путём разработки собственных скриптов и интеграции различных процедур сборки. В качестве альтернативы пользователь может оценить, подходят ли под его или её требования некоторые интегрированные среды разработки, доступные на рынке. Рынок IDE для Linux всё ещё находится в младенческой фазе и больше сконцентрирован на механизмах сборки ядра, просто потому, что сборка приложения варьируется в зависимости от приложения (нет стандартов, которым следуют при сборке приложений). Добавление ваших собственных приложений или экспорт зависимостей между приложениями просто не могут быть предложены многими средами разработки; даже если они предлагают это сделать, это может потребовать некоторых навыков. Интегрированные среды разработки обсуждаются в отдельном разделе. Если вы решили использовать IDE, пропустите раздел сборки и сразу переходите к разделу отладки. Но в случае, если вы планируете настраивать процедуры сборки, оставайтесь и читайте дальше.