Грег Роуз (Greg Rose), компания LynuxWorks

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

Существует ли операционная система для вашего микропроцессора?

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

Поддержка встраиваемых процессоров в ОС Linux

Самая распространенная на сегодня версия Linux это, безусловно, версия для совместимых с ПК компьютеров, созданных на базе процессоров с архитектурой х86. Современные персональные компьютеры это недорогие системы, способные выступать как в роли инструментальных, так и целевых платформ. В мире такие машины использует большая часть Linux-разработчиков, и именно для этих компьютеров прежде всего и пишутся различные программы. Процессоры семейства х86 применяются не только в персональных, но и во многих встраиваемых системах. В настоящее время существует множество моделей х86-процессоров от чрезвычайно быстродействующих до самых экономичных. Полностью совместимый с ПК компьютер может уместиться сегодня на один кристалл. Для некоторых разработчиков все, что им нужно это версия ОС Linux для архитектуры х86. Однако в определенных случаях процессоры х86 могут быть не самым лучшим выбором. В тех приложениях, где требуется очень низкий уровень энергопотребления, более уместными могут оказаться процессоры типа ARM или Hitachi SH, имеющие при существенно меньшей рассеиваемой мощности ту же производительность. В других ситуациях предпочтение следует отдать дешевым микропроцессорам, имеющим ядро PowerPC, сопроцессор и необходимый набор функций ввода/вывода. В предполагающих интенсивную обработку данных системах более оправданным может быть применение процессоров типа MIPS, характеризующихся лучшим, чем у х86, соотношением цены и производительности. Сегодня рынок встраиваемых микропроцессоров сильно фрагментирован. В сущности, он всегда был таким, и ничто не указывает на скорую его консолидацию.

Хорошая новость состоит в том, что модификации ОС Linux существуют для многих типов встраиваемых микропроцессоров, в том числе для архитектур PowerPC, MIPS, ARM, StrongArm и SH. Плохая это то, что программных продуктов для этих модификаций создано гораздо меньше, чем для процессоров х86. Однако теперь обновленные Linux-дистрибутивы для иных, нежели х86, платформ появляются регулярно, и вскоре ситуация должна улучшиться. О поддержке версий операционной системы Linux для различных процессорных платформ заявляет все большее число производителей программного обеспечения. Впрочем, основной движущей силой являются здесь пользователи. Растущий спрос на приложения, стеки протоколов и собственно Linux-версии для различных процессоров существенно ускоряет процесс создания соответствующих модификаций этой ОС.

Может ли операционная система работать в безоператорном и бездисковом режимах?

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

ОС Linux в безоператорных и бездисковых вариантах

Операционная система Linux разрабатывалась на основе модели UNIX и задумывалась как ОС для настольных компьютеров. В традиционных версиях Linux для взаимодействия с оператором имеется алфавитно-цифровая консоль, позволяющая управлять загрузкой операционной системы, осуществлять ввод команд и контролировать работу ОС. Однако встроенным системам оператор, как правило, не нужен, и потому во встраиваемой Linux подобное взаимодействие предусматриваться не должно. Как и во всех версиях ОС UNIX, хранение и поиск постоянных данных и исполняемых программ осуществляется в Linux средствами файловой системы. Различные устройства также представляются в виде специальных файлов. Реализованная на дисковых накопителях файловая система является неотъемлемой частью исполнительной среды Linux.

Создание безоператорной версии операционной системы Linux не составляет особого труда: достаточно заменить устройство консоль фиктивным устройством. Если вместо выполнения процедуры регистрации стартовый скрипт будет сразу осуществлять запуск прикладных программ, то и взаимодействия с оператором удастся избежать. Мониторинг при необходимости можно выполнять удаленно, что обеспечивается возможностью дистанционного входа в систему и назначением псевдоустройству TTY роли консоли. Операционные системы семейства Linux поддерживают различные графические пользовательские интерфейсы (X-windows и др.), однако последние являются опциональными и для нормальной работы ОС не требуются.

Проблему бездисковости можно решить несколькими способами. Существуют модули флэш-памяти, способные эмулировать IDE-дисководы. Как правило, эти модули очень компактны и не превышают по своим размерам обычных IDE-разъемов. Кроме того, в состав Linux входит драйвер электронного диска используемой для имитации дискового накопителя определенной части системной памяти. Такой диск может использоваться для хранения файлов, которые не потребуются после перезагрузки системы. Драйвер электронного диска применим и для обращений к файловой системе, реализованной в ПЗУ. Если во встроенной системе есть флэш-память, которая неспособна эмулировать IDE-дисковод, то для работы с этой памятью как с диском можно воспользоваться средствами файловой системы. Хорошая система управления хранящимися во флэш-памяти файлами обязана иметь механизм контроля износа, сводящий число операций стирания флэш-блоков к разумному минимуму.

Способна ли ОС работать в системах с ограниченной памятью?

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

Требования к памяти со стороны ОС Linux

По умолчанию Linux необходимы довольно значительные объемы памяти, что неприемлемо для большинства встраиваемых систем. Как правило, дистрибутив ОС Linux занимает несколько сотен мегабайтов. В несжатом состоянии стандартное Linux-ядро занимает около полутора мегабайтов, а требуемый этим ядром объем памяти составляет более 4 Мбайт. Кроме того, нужна еще и память для поддержания файловой системы, а если система работает в бездисковом режиме и память для электронных дисков.

Решение проблемы требуемой для операционной системы Linux памяти заключается в тщательной настройке ядра ОС. Ядро имеет модульную структуру, что позволяет манипулировать неиспользуемыми в конкретных приложениях функциональными возможностями. Кроме того, имеется возможность играть с некоторыми параметрами ядра, такими как максимальное число процессов или одновременно открытых файлов. Выбор соответствующих модулей и их конфигурирование позволяет значительно снизить потребность операционной системы в ОЗУ и ПЗУ. Можно, к примеру, построить вполне работоспособное Linux-ядро для архитектуры х86 объемом всего 259 Кбайт. Минимальный размер ПЗУ-диска, позволяющий поддерживать необходимую для такого ядра файловую систему, составляет 102 Кбайт; объем используемой при этом оперативной памяти может быть менее 4 Мбайт. ОС Linux с поддержкой TCP/IP требует больших ресурсов. Ядро с сетевыми средствами может занимать 370 Кбайт, а требуемый в этом случае объем ПЗУ-диска будет около 740 Кбайт (в несжатом состоянии). Потребность в ОЗУ не превышает для этой конфигурации 8 Мбайт. Конечно, это все еще достаточно далеко от тех сверхнизких показателей, которые способны обеспечить традиционные ОСРВ, но уже вполне приемлемо для многих встраиваемых устройств.

Имеются ли для встраиваемой ОС инструментальные средства? Совместима ли операционная система с другим необходимым программным обеспечением?

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

Как и в случае ОС для настольных компьютеров и серверов, при выборе встраиваемых операционных систем нередко решающую роль играют не предоставляемые ими функциональные возможности, а наличие готовых программных средств. Многие держат на своих персональных компьютерах операционные системы Windows лишь потому, что необходимые этим людям текстовые процессоры и электронные таблицы созданы именно для Windows. Действительно, помимо ОС проектировщикам встроенных систем требуются и другое ПО: стеки протоколов, связующее программное обеспечение, драйверы нестандартных устройств, а иногда и готовые прикладные программы. Наличие для встраиваемой операционной системы подобного ПО устраняет проблему переноса программных средств на другую платформу и может стать решающим аргументом при выборе той или иной ОС. Функциональные характеристики операционной системы приобретают особое значение в том случае, когда в связи с отсутствием готового прикладного ПО его необходимо создавать. Существование нужной функциональной возможности способно обеспечить сокращение как сроков разработки, так и портирования. Дело в том, что подлежащие переносу на другую платформу программы писались в расчете на наличие у целевой операционной системы определенного набора функций, в случае отсутствия которых портирование будет отнимать много сил и средств.

Инструментальные средства для ОС Linux

Большинство Linux-программ пишется, запускается и отлаживается в одной и той же Linux-системе. После того, как программа будет полностью отлажена, ее работоспособный исполняемый образ (или содержащий такой образ пакет) может быть скопирован в другие Linux-машины. Аналогичным образом можно создавать и программное обеспечение для встраиваемой системы при том условии, что в этой системе имеется оперативная и дисковая память достаточного для работы инструментальных средств объема. На практике, впрочем, такая ситуация довольно редка, и потому у программиста возникает необходимость использования средств кросс-разработки.

Для кросс-разработки вполне подойдут широкораспространенные GNU-компиляторы. Однако различие порядков адресации байтов в инструментальной и целевой системах (как это имеет место, например, в системах с процессорами типа х86 и PowerPC) может приводить к ошибкам. Необходимо также определить метод загрузки образа ядра из инструментальной системы в целевую. Если целевая система способна работать с каким-либо дисковым накопителем (и загружаться с этого диска), можно подключить этот диск к инструментальной машине, записать на него образ ядра и файловую систему, затем подключить его к целевой платформе и осуществить загрузку. В том случае, когда загрузка ОС в целевую систему может осуществляться по сети, на инструментальном компьютере достаточно запустить сервер загрузки и файловый сервер. Если же для загрузки целевой платформы должны использоваться только ПЗУ или флэш-память, может потребоваться применение специальной утилиты, создающей из Linux-ядра и файловой системы единый загрузочный образ.

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

Кросс-разработка предполагает поддержку и кросс-отладку. В среде кросс-разработки отладчик исполняется на инструментальной системе. В Linux-дистрибутивы входит GNU-отладчик GDB, который может использоваться для отладки программ, написанных как в кодах инструментальной платформы, так и в кодах целевого компьютера. В первом случае отладчик исполняет программу сам или подключается к работающей программе; при этом посредством интерфейса /proc осуществляется контроль структур данных и переменных приложения. Кроме того, отладчик может выполнять трассировку программы, перехватывать посылаемые исполняемой программе сигналы, а также генерировать собственные сигналы. Отладчик считывает из исполняемого файла символьную информацию и способен обеспечивать вывод исходного текста программы на экран. В среде кросс-разработки отладчик исполняется на инструментальной платформе, а прикладная программа на целевой. Исходный текст и таблицу символов отладчик читает из файлов инструментальной системы. Контроль имеющих отношение к отлаживаемой программе процессов, структур данных и значений переменных осуществляется посредством работающего на целевой машине агента. Последний представляет собой GDB-сервер и занимает гораздо меньше памяти, чем сам отладчик. Отладчик GDB взаимодействует со своим агентом по TCP/IP-каналу либо при помощи простого последовательного соединения.

Разумеется, отладка Linux-ядра и драйверов устройств не может осуществляться так же, как и отладка пользовательского приложения. Установка контрольной точки в ядре или иная остановка исполняющегося в ядре процесса способна привести к остановке и самого агента. Большая часть настольных дистрибутивов Linux не обеспечивает функций, необходимых для отладки ядра и драйверов. Однако рассчитанные на встраиваемые системы дистрибутивы такими функциями обладают. Обычно отладчик GDB взаимодействует с агентом отладки ядра по низкоуровневому последовательному соединению. Такое решение позволяет осуществлять пошаговое исполнение ядра или драйвера и даже ставить контрольные точки в процедурах обслуживания прерываний. Единственной вещью, которую не удается отлаживать подобным образом, является сам агент отладки.

Наличие для ОС Linux программ сторонних разработчиков

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

Бесплатно распространяются не только исходные Linux-коды, но и исполняемые образы. Для массового производства встраиваемых систем, предполагающего весьма жесткие ограничения на себестоимость продукта, отсутствие выплат за встроенную ОС является значительным преимуществом, позволяющим сэкономить деньги и устраняющим необходимость контроля числа поставленных копий.

С программной точки зрения Linux является UNIX-подобной операционной системой. Одно из основных объяснений большого числа Linux-программ такие же, как и в UNIX, API-интерфейсы, а также форматы объектных и исполняемых файлов. Значительная часть написанного за последние два десятка лет для ОС UNIX общедоступного программного обеспечения может без каких-либо изменений использоваться и в Linux. Кроме того, было создано немало программ и для других UNIX-версий: для AIX компании IBM, для Solaris компании Sun Microsystems, для HP/UX компании Hewlett-Packard. Модифицировать свое ПО для операционной системы Linux не составляет разработчикам данных программ никакого труда. Иными словами, огромный опыт, накопленный в процессе создания программного обеспечения для UNIX, без каких-либо оговорок может быть использован и при разработке Linux-программ.

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

Достаточно ли операционная система надежна и производительна?

Надежность и производительность две очень важные характеристики операционной системы, которые, как правило, невозможно улучшить ни прикладными, ни библиотечными программами. Надежная программа в ненадежной операционной системе сама становится ненадежной. Надежность ОС определяется лежащими в ее основе базовыми принципами, а также особенностями архитектуры и программирования. Многие встраиваемые приложения характеризуются гораздо более высокими требованиями к безотказности работы операционной системы, чем настольные компьютеры, и выбор действительно надежной ОС приобретает в этой связи огромное значение. Разумеется, каждый уважающий себя поставщик операционных систем заявляет о высочайшей степени стабильности своей продукции, и потому для получения объективной информации приходится проводить испытания ОС на надежность. Что касается производительности, то ее также можно тестировать. Как правило, проверить соответствие операционной системы требованиям того или иного встраиваемого приложения в плане производительности не составляет большого труда. Гораздо сложнее бывает установить то, насколько рассматриваемая в конкретном контексте ОС отвечает требованиям режима реального времени. Проблема заключается не в самом тестировании, а в определении этих требований. Кроме того, в зависимости от нагрузки оперативность реагирования работающей в реальных условиях операционной системы может меняться в весьма широких пределах. Бывает так, что ошибочность выбора ОС обнаруживается в самом конце периода разработки продукта, когда выявляются те связанные с режимом реального времени требования, которые не были определены на более ранних стадиях и которым данная операционная система не в состоянии удовлетворить.

Надежность и производительность ОС Linux

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

К существующей в Linux проблеме режима реального времени можно подойти несколькими различными способами: игнорировать ее, запускать приложения реального времени в ОСРВ, в которой сама Linux исполняется в качестве отдельной задачи (как это, например, имеет место в случае RT-Linux), или использовать вместо ядра Linux ядро какой-либо совместимой с Linux операционной системы реального времени. Наиболее распространенный подход это первый. Как правило, определение real-time-требований на ранних стадиях реализации проекта является довольно трудной задачей (такое определение может оказаться простым делом лишь в том случае, когда приложение предъявляет к режиму реального времени весьма слабые требования). Если в ходе соответствующих исследований будет обнаружено, что с точки зрения реального времени применение Linux является нецелесообразным, разработчики смогут воспользоваться другими методами.

Операционная система RT-Linux

ОС RT-Linux это система, в которой Linux-ядро является отдельной задачей, выполняемой под управлением небольшой управляющей программы-диспетчера, работающей в реальном времени. Приложения реального времени исполняются под управлением этой программы, остальные под управлением ядра Linux. Данный подход отнюдь не нов. Много лет назад он был опробован для коммерческой ОС UNIX; в качестве более свежих примеров можно назвать попытки организации исполнения задач реального времени в компьютерах с операционной системой Windows NT. Одним из преимуществ этого метода является то, что программа-диспетчер реального времени может иметь достаточно малые размеры и простую структуру, что облегчает проверку соответствия системы требованиям реального времени. Кроме того, та Linux, что исполняет обычные (не real-time) задачи, является в данном случае самой обыкновенной Linux, совместимой с другими версиями этой операционной системы и допускающей быстрое осуществление различных модификаций/модернизаций. Такое решение сочетает в себе открытость с поддержкой приложений жесткого реального времени, в которых времена реакции на события обязаны выдерживаться в абсолютном числе случаев.

Нет никаких сомнений, что метод, предлагаемый RT-Linux, может быть использован для целого класса приложений реального времени. Контрольно-измерительные системы, а также системы управления оборудованием и технологическими процессами, в которых программные средства реального времени являются лишь небольшой частью всего прикладного ПО, будут прекрасно себя чувствовать под управлением ОС RT-Linux. Во всяком случае, это решение гораздо лучше, чем простое игнорирование требований к работе в реальном времени.

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

Совместимое с Linux ядро реального времени

Еще одним решением проблемы запуска real-time-приложений в среде Linux является замена ядра Linux совместимым с ним ядром, обладающим характеристиками жесткого реального времени. Фактически, уже в случае RT-Linux мы имеем дело ни с чем иным, как с отказом от попыток исполнения задач реального времени под управлением обычного Linux-ядра. Кроме того, после появления Стандартной Базы Linux (LSB Linux Standard Base), представляющей собой стандарт двоичного интерфейса для операционной системы Linux, последняя превращается из просто технологии в полноценную платформу исполнения приложений. Любая ОС, удовлетворяющая требованиям этого стандарта, в состоянии поддерживать исполнение Linux-приложений. Ядро это лишь небольшая часть всей операционной системы. Если модернизируется только ядро Linux, библиотеки же, утилиты и файловая структура остаются без изменений, обеспечить соответствие этому стандарту и совместимость с другими Linux-версиями становится еще проще. Ядро реального времени обязано лишь поддерживать все функции ядра Linux, оставаясь при этом полностью вытесняемым и повторно входимым. Оно должно иметь планировщик процессов реального времени и гарантировать не превышающую некоторого фиксированного предела длительность задержек, связанных с обработкой прерываний.

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

Другие проблемы, связанные с использованием встраиваемой ОС Linux

Несмотря на весьма веские причины выбора Linux в качестве ОС для встраиваемой системы или встраиваемого устройства, в области лицензирования ей свойственны определенные проблемы. Операционная система Linux это не общедоступное ПО; ее лицензирование осуществляется согласно требованиям лицензии GPL (GNU Public License), устанавливающей строгий набор правил пользования.

Юридические вопросы

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

Что значит лицензия GPL для разработчика встраиваемых систем, имеющего дело с ОС Linux? Если разработчик каким-либо образом модифицирует Linux-ядро или утилиту, перенесет их на другую платформу или расширит набор их функциональных возможностей, он будет обязан опубликовать эти изменения в сети Интернет и предоставлять их бесплатно каждому, кто их запросит. При не вполне аккуратном поведении можно запросто лишиться прав на собственные программные средства, и потому по всем вопросам, касающимся охраны авторства в области открытых исходных текстов, имеет смысл советоваться с опытным юристом.

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

Заключение

Несмотря на то, что изначально ОС Linux не была рассчитана на использование во встраиваемых устройствах, продуманное конфигурирование и разработки некоторых поставщиков, предлагающих ее встраиваемые версии, делают эту операционную систему вполне применимой и в данном круге задач. Постепенно ОС Linux перерастает рамки просто технологии и превращается в мощную платформу для встраиваемых приложений. Использование этой операционной системы пока еще связано с определенными трудностями в таких областях, как лицензирование, ограничения на объемы занимаемой памяти, разработка программных средств, функционирование в безоператорном режиме и в бездисковых системах, поддержка встраиваемых процессоров и режим реального времени. ОС Linux не является общедоступным программным обеспечением и лицензируется в соответствии с требованиями лицензии GPL (GNU Public License), представляющей собой строгий набор правил пользования. При этом не вызывает сомнений, что популярность Linux будет стимулировать все более широкое применение во встраиваемых системах различных ее версий. С точки зрения используемых при выборе операционной системы основных критериев, таких как наличие аппаратных средств и готового программного обеспечения, Linux следует признать одним из главных кандидатов на роль ОС для встраиваемых приложений.