6.2.1 Выбор стратегии переноса

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

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

Модель с одним процессом

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

Рисунок 6.3 Миграция в модель одним процессом.

Модель с несколькими процессами

Поделите задачи на не связанные, связанные и ключевые задачи.

▪Не связанные задачи: слабосвязанные задачи, использующие механизмы межпроцессного взаимодействия, предлагаемые RTOS для связи с другими задачами, или автономные задачи (* Например, DHCP клиент является автономной задачей. Он может быть легко перенесён в качестве отдельного процесса Linux.), которые не связаны с другими задачами, могут быть перенесены в виде отдельных процессов Linux.

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

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

Рисунок 6.4 иллюстрирует данный подход.

Рисунок 6.4 Миграция в модель с несколькими процессами.

Преимущества этой модели:

▪Достигается защита памяти для каждого процесса. Задача не может повредить адресное пространство другого процесса.

▪Она расширяема. Используя эту модель могут быть добавлены новые возможности.

▪Приложения могут в полной мере использовать преимущества модели программирования Linux.

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