СТА 4/2010

чтобы заголовочные файлы ядра были модифицированы в соответствии с выбранной архитектурой процессора (более детально об этом – в следующем разделе). Выбор конкретной версии ядра Linux для проекта обычно зависит от того, какой уровень поддержки вашей целевой аппаратуры обеспечивается основной веткой кода ядра, а также от того, для каких версий ядра существу# ют необходимые вам «заплатки» (пат# чи). «Заплатки» обычно добавляют поддержку новых процессоров и уст# ройств, а также содержат исправления ошибок, пока не включённые в основ# ную ветку кода ядра. Предоставляются такие «заплатки» обычно производите# лями «кремния», которые используют Linux для внутренних целей, но не предлагают коммерческих Linux#реше# ний. Другие «заплатки» зачастую мож# но взять с сайтов, посвящённых конк# ретной архитектуре. В дополнение к этому для некоторых классов процессоров (например, про# цессоров без аппаратного диспетчера памяти – MMU) часто требуются спе# цифические «заплатки», обычно до# ступные только для конкретных версий ядра. Несмотря на то что поддержка процессоров без MMU уже интегриро# вана в основную ветку ядра 2.6, всё ещё существует множество дополнитель# ных «заплаток», которые могут быть необходимы для поддержки вашей це# левой аппаратуры. И, наконец, «за# платки», добавляющие поддержку от# раслевых спецификаций типа CELF (Consumer Electronics Linux Forum) или CGL (Carrier Grade Linux), могут тре# бовать предварительного применения ряда других «заплаток». Когда вы определитесь с номером версии ядра Linux и всех необходимых «заплаток» и получите исходный текст, интеграция «заплаток» в код ядра мо# жет не пройти из#за конфликтующих изменений в коде. Чтобы устранить эти конфликты, вам придётся вручную ре# дактировать исходный текст ядра. Процесс этот обычно носит итератив# ный характер, и вы вынуждены будете пройти через множество циклов моди# фикации и проверки, пока у вас полу# чится предположительно корректное дерево исходных текстов ядра Linux для вашего устройства. С этого момен# та вы можете начать конфигурировать ваше ядро – скомпилировать его вы пока не можете, но теперь у вас есть хо# тя бы заголовочные файлы, которые потребуются для построения инстру# ментария кросс#компиляции. П ОИСК / ПОСТРОЕНИЕ ИНСТРУМЕНТАЛЬНОГО ПАКЕТА И СОПУТСТВУЮЩЕГО ПО Самая серьёзная проблема любого проекта, основанного на «доморощен# ной» Linux, – это инструментальный пакет для построения системного и прикладного ПО, а также ядра ОС. Большинство Linux#платформ исполь# зуют инструментарий на базе GNU Compiler Collection, свободно распро# страняемого пакета компиляторов, включающего в себя самый распрост# ранённый в мире компилятор языка Си – GCC. Использование GCC пред# полагает наличие ещё двух программ# ных пакетов: библиотеки языка Си и набора утилит, включающих в себя ас# семблер, компоновщик, библиотекарь и ряд других инструментов, обеспечи# вающих создание исполняемых прог# рамм и сопутствующих библиотек для целевого устройства. Совокупность всех этих компонентов и называется инструментальным пакетом. GCC портирован на большое число различных процессорных архитектур, так что физическая возможность гене# рировать бинарные модули для боль# шинства доступных аппаратных плат# форм обычно уже есть. Аналогично стандартная библиотека Си и утилиты тоже портированы на множество раз# личных систем. Однако поддержка последних моделей процессоров обыч# но требует соответствующих «запла# ток» для утилит, GCC и библиотеки языка Си, которые нужно заполучить, интегрировать, разрешить все конф# ликты и т.п. С генерацией бинарных модулей для встраиваемых систем связана ещё одна интересная проблема. Поскольку Linux на вашем устройстве ещё не работает, то резидентную (так называемую род# ную. – Прим. пер. ) версию GCC вам выполнять физически негде. К тому же у большинства встраиваемых аппарат# ных платформ просто недостаточно ре# сурсов, чтобы хранить и выполнять компилятор и связанные с ним компо# ненты. По этим причинам разработка для Linux#платформы обычно произ# водится на обычном настольном ком# пьютере с использованием специаль# ного инструмента, называемого кросс# компилятором. Кросс#компилятор вы# полняется на инструментальной систе# ме, но бинарные файлы, которые он генерирует, предназначаются для целе# вой системы с другой архитектурой. Инструментальная система отличает кросс#компиляторы от резидентных компиляторов по префиксам в име# нах – эти префиксы содержат назва# ния целевых платформ. Если вам повезёт, то вы сможете най# ти и скачать готовый пакет кросс# инструментария для процессора, ис# пользуемого в вашей целевой системе. Однако, сделав это, вы сразу станови# тесь заложником умений того челове# ка, который этот пакет собрал, и его выбора включённых в пакет библио# тек. Даже если вы не прочь попытать счастья, имейте в виду – вы рискуете поставить свой проект в зависимость от неподдерживаемого программного компонента. Удобство скачивания готового кросс# инструментария может быстро улету# читься, если вы впоследствии столкнё# тесь с проблемами в процессе его ис# пользования (особенно в плане произ# водительности результирующих бинар# ных модулей) и вам будет некуда обра# титься за исправлениями и поддерж# кой. Многие проекты встраиваемого ПО также требуют архивации исходных текстов, из которых был построен инструментарий, а они запросто могут быть недоступны, потому что инстру# ментарий строили не вы. Когда возни# кает одна или обе из перечисленных проблем, проектная команда часто принимает решение собрать свой собственный кросс#инструментарий, чтобы не зависеть от доступного, но не# поддерживаемого стороннего решения. Построение среды кросс#компиля# ции в составе кросс#компилятора GCC, стандартной библиотеки языка Си и набора утилит может оказаться чрезвычайно сложной задачей. «За# платки» и обновления для конкретных архитектур, процессоров и устройств рассеяны по множеству Web#сайтов, и все их придётся перед сборкой инстру# ментария интегрировать вручную. Как и в случае с конфигурированием кода ядра, наложение «заплаток» из разных источников зачастую не срабатывает из#за конфликтов в версиях кода, кото# рые также придётся разрешать самос# тоятельно. Процесс этот обычно итера# ционный, и циклов модификации и проверки потребуется больше одного. Как только исходный код будет го# тов, вам нужно будет построить все компоненты среды кросс#компиляции в правильном порядке. Сначала с по# ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 21 СТА 4/2010 www.cta.ru © СТА-ПРЕСС