Особенности построения ОС Linux для процессоров R3000 без

ПРОГРАМНО-ТЕХНІЧНІ КОМПЛЕКСИ
УДК 004.518
В.В. КАЗИМИР, П.В. ТАРАСЕНКО, В.А. КУЛЕШОВ
СОЗДАНИЕ МОДИФИКАЦИИ ОС LINUX ДЛЯ ВСТРАИВАЕМЫХ СИСТЕМ НА БАЗЕ ПРОЦЕССОРОВ
СЕМЕЙСТВА R3000
Введение
В настоящее время значительно увеличился интерес к операционной системе Linux. Это обусловлено рядом
преимуществ, среди которых главным есть то, что Linux является полномасштабной операционной системой с
большим числом приложений. Также следует отметить и то, что она бесплатна и поставляется вместе с
исходными кодами самой операционной системы и исходными кодами большинства ее приложений. Это
позволяет развивать и модифицировать операционную систему, и, в частности, переносить ее на другие
аппаратные платформы для использования во встроенных системах. В настоящее время наметилась
тенденция переноса операционной сиcтемы Linux на такие аппаратные платформы, как MIPS, ARM, Motorola,
Intel i960 и другие микропроцессорные ряды [1]. Эта тенденция обусловлена постоянно увеличивающимся
спросом на компактные (встроенные) системы; при этом сложность решаемых ими задач постоянно растет и
наилучшим выходом есть использование в качестве базы одной из существующих операционных систем Linux. Поэтому задача переноса операционной системы Linux на другие аппаратные платформы является
актуальной.
1. Постановка задачи
В данной статье рассматривается задача переноса операционной системы Linux на заданную аппаратную
платформу. Для конкретизации последней примем платформу на базе процессора семейства R3000 [2] с
архитектурой построения MIPS [3].
Исходя из особенностей этой платформы, требуется переработать ядро Linux с учетом следующих
аппаратных ограничений:
1)
аппаратная платформа на базе процессора семейства R3000 без MMU (Memory Management Unit)
[4];
2)
объем ОЗУ 8Mb, из которого операционная система Linux может использовать не более 4Mb;
3)
объем ПЗУ 2Mb, из которого операционная система Linux может использовать не более 1,5Mb;
4)
обеспечить поддержку USB [5].
2. Технология модификации Linux
Как известно, общая архитектура операционной
системы Linux включает ядро,
набор системных
утилит и пользовательские программы (рис. 1).
Набор системных утилит и программы пользователя
Рис. 1. Общая архитектура операционной системы Linux
компилируются с помощью библиотеки LibC [6],
реализация которой зависит от аппаратных особенностей используемого процессора (в основном это зависит
от способа обращения задачи к ядру). Главная цель библиотеки LibC - это соответствие спецификации POSIX
 Литвинов В.В., Казимир В.В., Дяченко В.В. 2002
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
45
[7], что должно обеспечить совместимость программ для операционной системы Linux на уровне исходных
кодов на языках С/C++.
Спецификация POSIX – это набор стандартов [8], описывающих операционные системы семейства UNIX [9] (к
которому принадлежит и операционная система Linux). Базовая версия спецификации POSIX состоит из
следующих технических стандартов:
1)
основные понятия (XBD);
2)
оболочка и утилиты (XCU);
3)
системные интерфейсы (XHS);
4)
практические рекомендации (Informative).
Исходя из всего вышеперечисленного, становится очевидной главная цель, которую необходимо достигнуть
при переносе операционной системы Linux с одной аппаратной платформы на другую, – это максимальное
соответствие спецификации POSIX. Поэтому особое внимание следует определить библиотеке LibC, которая
должна соответствовать стандарту системных интерфейсов для операционных систем семейства UNIX (XHS).
Исходя из архитектуры операционной системы Linux, а также учитывая поставленные цели и практический
опыт, технология переноса ОС Linux на другие аппаратные платформы может быть представлена в виде
следующей последовательности шагов:
1)
выбор базового ядра;
2)
анализ структуры ядра и определение архитектурно зависимых частей требующих модификации;
3)
определение ограничений ядра в связи с отсутствием MMU;
4)
модификация ядра;
5)
модификация библиотеки программиста LibC;
6)
модификация системных утилит.
2.1. Выбор базового ядра ОС Linux для модификации
В настоящее время существует версия ОС Linux и для аппаратных платформ на базе процессора R3000.
Однако эти решения предусматривают использование аппаратного решения для преобразования виртуальных
адресов памяти в реальные – Memory Management Unit. Однако существует ряд решений, позволяющих
перестроить операционную систему Linux так, что необходимость в MMU отпадет. Среди всех этих решений
следует отметить как базовые решения для таких аппаратных платформ: Motorola M68EZ328, Motorola M68328,
Motorola M68EN322, ARM7TDMI, ETRAX, Intel i960, Atari 68k [10]. Как правило, каждое из таких решений
включает следующие компоненты:
1)
ядро операционной системы Linux;
2)
набор системных и файловых утилит, базовый набор программ;
3)
библиотека программиста LibC;
4)
вспомогательные утилиты (например, создание образа диска, сжатие бинарного образа ядра и
линкование к нему загрузчика и т.д.);
5)
компиляторы C и ассемблеры, линковщики для целевой аппаратной платформы.
Все эти решения отличаются от базовой версии операционной системы Linux следующими изменениями в ее
структуре исходных кодов:
1)
добавлены новые правила для программ компилятора и линковщика;
2)
в программу конфигурации ядра добавлены опции выбора новой аппаратной платформы и ее
доступной конфигурации;
3)
добавлены файлы с исходным кодом для аппаратно зависимых компонентов ядра, расположенных
в виде отдельного дерева каталогов в подкаталоге исходных кодов операционной системы Linux ./arch;
46
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
4)
часть архитектурно независимого кода на языке С, в которую вносятся изменения, располагается в
дополнительных каталогах (например, ./mm_nommu);
5)
библиотека программиста представляется в виде отдельной версии;
6)
бинарные утилиты представляются в виде отдельной версии.
Использование версии операционной системы Linux, отличной от базовой, позволяет уменьшить общее время
разработки. Это обусловлено тем, что в некоторых версиях операционной системы Linux уже реализовано
большинство компонентов для использования ядра во встраиваемых системах. В то же время выбор наиболее
подходящего ядра в качестве исходного есть одной из самых важных задач, поскольку он обуславливает
общее время разработки.
Среди всех существующих версий ядра операционной системы Linux, модифицированных для работы без
MMU, наиболее развита версия под названием uClinux [11]. К преимуществам этой версии следует отнести:
1)
наличие исходного кода для процессоров семейства R3000;
2)
реализацию ядра для работы без MMU;
3)
большое количество свободно доступных версий ядра, библиотек и утилит;
4)
реализацию последней версии ядра 2.4.
Исходя из необходимости поддержки USB, наилучшим решением будет выбор версии uClinux 2.4,
поскольку она базируется на наиболее новой на сегодняшний день версии ядра операционной системы Linux 2.4.
2.2. Анализ внутренней архитектуры ядра uCLinux 2.4
В связи со все возрастающим интересом к операционной системе
Linux, в частности, к архитектуре ее ядра, есть работы [12],
ориентированные на описание структуры ядра операционной
системы Linux, а также принципов работы и взаимодействия всех
ее
компонентов.
В
большинстве
источников
внутренняя
архитектура ядра операционной системы Linux представляется
четырьмя главными компонентами: менеджер задач, менеджер
памяти, файловая система и подсистема взаимодействия между
процессами. Все эти компоненты взаимосвязаны друг с другом, и
каждая из компонент выполняет свой круг задач. Ядро ядра
операционной системы uCLinux 2.4 имеет такую же структуру
(рис. 2.).
В
представленной
архитектуре
драйверы
условно
разделены на две группы: драйверы физических устройств и
драйверы
системных
устройств.
К
драйверам
физических
устройств относятся драйверы, которые содержат аппаратно
зависимые участки программного кода, остальные драйверы
Рис. 2. Внутренняя архитектура ядра
операционной системы uCLinux 2.4
относятся к группе системных устройств. Следовательно, все
драйверы физических устройств нуждаются в изменениях. Для
полного анализа внутренней структуры ядра операционной системы uClinux следует рассмотреть каждую из
его компонент более детально.
2.2.1. Менеджер задач
Процесс есть однократное выполнение процедуры. Это значит, что каждый процесс живет лишь временно;
есть момент, когда он «рождается», и есть момент, когда он «гибнет», завершив свою работу. В каждой
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
47
современной операционной системе есть понятие процесса или задачи [13]. Необходимость в этом понятии
возникает всякий раз, когда система должна отвечать на определенные запросы через определенные
промежутки времени.
Время ответа может быть различным – от нескольких секунд до нескольких
миллисекунд при регистрации данных или при управлении процессом. Поскольку момент поступления этих
запросов не предсказуем и не управляем системой, нельзя сказать, что последовательность операций
определяется только самой системой.
В больших вычислительных системах многочисленные процессы могут действовать одновременно. Всякая
попытка понять природу системы, рассматривая действие центрального процессора, обречена на провал, так
как процессор будет разделять свои ресурсы среди нескольких различных процессов. Напротив, если считать
процесс единицей действия и не уделять слишком большого внимания процессору, выполняющему это
действие, будет гораздо легче понять работу системы.
Следовательно, возникает необходимость во введении понятия «процесс». Введение понятия «процесс»
позволяет более просто и удобно описать систему как некоторое множество процессов. При этом
существенная разница между процессом и программой состоит в том, что процесс не является закрытой
системой; он может взаимодействовать с другими процессами либо явным образом, либо неявно, изменяя или
воспринимая часть среды, которую он разделяет с другими процессами.
При этом возникает необходимость в управлении процессами. Так, требуется разделять время процессора
(или нескольких процессоров в многопроцессорной системе) между процессами и управлять их состояниями.
Все эти функции в операционной системе Linux
выполняет менеджер задач (рис. 3.).
Менеджер задач в операционной системе
Linux выполняет следующие функции:
1)
передача
управления
процессу
с
наивысшим приоритетом;
2)
создание нового процесса;
3)
гибель процесса;
4)
изменение приоритетов процессов.
В
операционной
системе
Linux
есть
понятие контекста процесса. Под контекстом
процесса следует понимать всю совокупность
данных,
относящихся
к
процессу,
таких как
значения регистров процессора, стека, области
Рис. 3. Внутренняя архитектура менеджера задач
памяти
процесса,
используемых
ресурсов
системы, а также специальной информации о
процессе. Контекст процесса хранится в специальной структуре task_struct [12]. Передача управления от
одного процесса к следующему осуществляется переключением контекста процесса; при этом указатель на
текущий процесс current будет указывать на контекст текущего процесса.
Исходя из вышесказанного, перечислим компоненты в менеджере задач, которые содержат аппаратно
зависимые участки программного кода, а, значит, требуют изменения при переносе Linux на другую
аппаратную платформу:
1)
Порождение нового процесса. При этом требуется установить контекст процесса в начальное
состояние. Также возникает родственная задача загрузки программы в память - функция exec(). В этом
случае требуется создать загрузчик программы в формате ELF [14] (и других форматов, если это
требуется), реализация которого большей частью определяется аппаратной архитектурой выбранной
платформы.
48
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
2)
Переключение контекста задачи. Эта функция выполняется в функции scheduler(), которая
содержит аппаратно зависимый участок кода для переключения контекста процесса в виде макроса на
ассемблере switch_to().
3)
Инициализация нулевой задачи idle(). Требуется установить контекст процесса в начальное
состояние.
4)
Изменение структуры контекста процесса (а также последовательности его сохранения и
восстановления) с учетом аппаратной архитектуры.
2.2.2. Подсистема взаимодействия между процессами
Подсистема взаимодействия между процессами (IPC –
Inter
Process
Communication)
предназначена
для
решения следующего круга задач:
1)
синхронизация процесса выполнения задач,
реализованная с помощью семафоров;
2)
обмен
данными
между
задачами,
реализованный с помощью сообщений.
Внутренняя архитектура подсистемы взаимодействия
между процессами представлена на рис. 4.
IPC решает задачу обмена информацией и сигналами
между процессами. Включает такие возможности, как
Рис. 4. Внутренняя архитектура подсистемы
взаимодействия между процессами
семафоры, сообщения, программные каналы (pipes),
разделяемая память.
Все компоненты подсистемы взаимодействия между
процессами являются аппаратно независимыми
за исключением функций разделяемой памяти.
Их нельзя реализовать в связи с отсутствием
MMU. Поэтому эти функции переделываются
как заглушки: всегда возвращают ошибку.
2.2.3. Менеджер памяти
Менеджер
памяти
выполняет
функцию
управления памятью. Внутренняя архитектура
представлена
внутренней
на
рис.
архитектуры,
5.
Как
видно
менеджер
из
памяти
можно разделить на три логических уровня:
уровень
разделения
памяти
на
страницы,
уровень группировки страниц в области памяти
Рис. 5. Внутренняя архитектура менеджера памяти
и уровень областей памяти, принадлежащих
процессу. Учитывая аппаратные ограничения,
определим компоненты в менеджере памяти, которые содержат аппаратно зависимые участки программного
кода, а, значит, требуют изменения при переносе на другую аппаратную платформу:
1)
изменение уровня страничной адресации для работы с реальными адресами (без MMU);
2)
изменение уровня областей памяти, поскольку при реальной адресации памяти область памяти
следует выделять из страниц, которые непрерывно следуют друг за другом;
3)
удаление функции brk(), поскольку нет возможности менять размер области памяти после ее
выделения (так как область памяти должна состоять из непрерывно следующих друг за другом страниц).
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
49
2.2.4. Файловая система
Архитектура
файловой
системы
представлена на рис. 6. Традиционно для
операционных
систем
класса
Unix
файловая система состоит из Виртуальной
файловой системы (VSF) и из множества
драйверов для всех типов поддерживаемых
файловых систем. Виртуальная файловая
система
предоставляет
единообразный
доступ ко всем ресурсам системы (все
ресурсы системы представляются в виде
иерархического дерева с началом root,
которое
содержит
файлы
устройств,
виртуальные файлы системной статистики
– каталог /proc
присоединенных
Рис. 6. Внутренняя архитектура файловой системы
и файлы, и каталоги
файловых
систем
(mount)). Виртуальная файловая система
есть универсальный и аппаратно независимый механизм.
Файловая система содержит драйверы файловых систем, которые тоже являются аппаратно независимыми.
2.3. Ограничения функциональности ядра операционной системы uCLinux 2.4
Учитывая то, что ядро операционной системы uCLinux претерпевает изменения, возникают ограничения в
функциональности ядра операционной системы uCLinux по сравнению с функциональностью ядра
операционной системы Linux. Перечень основных ограничений определяется отсутствием виртуальной
адресации и приведен ниже:
1)
нет защиты памяти, и процессы могут адресовать всю память, включая память ядра;
2)
неэффективное использование памяти, поскольку при выделении блока памяти требуется
выделять последовательность страниц, непрерывно следующих друг за другом. Следовательно, память
не будет использоваться полностью;
3)
нет свопинга. Поскольку страницы памяти находятся в реальных адресах, то нельзя осуществлять
замену страниц между памятью и диском;
4)
отсутствие
функции
brk().
Поскольку
область
памяти
выделяется
как
непрерывная
последовательность страниц, нельзя изменить размер области памяти;
5)
замена функции fork() на vfork(). Нельзя создать копию процесса с теми же адресами (как в случае
с виртуальной адресацией), поэтому при порождении потомка копируется только стек, но не программа и
области данных.
2.4. Особенности переноса ядра операционной системы uCLinux 2.4
При переносе ядра операционной системы uClinux на платформу процессора R3000 возник ряд
дополнительных задач, обусловленный изменениями в архитектуре ядра:
1)
Разработка загрузчика ELF файлов. Это обусловлено тем, что бинарный образ программы в
памяти, ее стека, переменных окружения, способа передачи параметров, формата файлов программы
определяется аппаратной платформой. Следовательно, загрузчик ELF файлов для платформы x86 будет
отличаться от загрузчика для платформы R3000.
50
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
2)
Разработка библиотеки программиста LibC. Необходимость в разработке собственной версии
библиотеки программиста вытекает из особенностей целевой аппаратной платформы: способ вызова
ядра, способ передачи и получения параметров в/из ядра. Поэтому существует много версий библиотеки
программиста LibC.
3)
Разработка интерпретатора команд (shell). Создание собственного интерпретатора команд
обусловлено ограничениями в используемой памяти. Так, использование полноценного интерпретатора
команд повлекло бы за собой необходимость в 500 Кбайтах памяти для каждого интерпретатора. Поэтому
разработка упрощенного интерпретатора команд размером в 32 Кбайта позволяет более экономно
использовать память системы.
4)
Разработка набора командных файлов и программ для инициализации системы (каталог /rc.d, init,
login, и т.д.). Необходимость в разработке набора программ и командных файлов для инициализации
системы определяется общим принципом старта операционной системы Linux:
1.
распаковывание сжатого бинарного образа ядра операционной системы Linux в память;
2.
передача управления разжатому бинарному образу ядра операционной системы Linux;
3.
инициализация аппаратуры;
4.
инициализация системы;
5.
запуск нулевого (idle) и первого процесса (init);
6.
первый процесс запускает программу init с корневого диска;
7.
программа init проводит инициализацию системы в соответствии с файлом inittab –
запускаются
программы
login
на
указанные
консоли,
программы
конфигурации,
системные программы и т.д.
3. Полученные результаты
В результате проведенных исследований разработана операционная система Plinux. Операционная система
Plinux включает следующие компоненты:
1)
загрузчик ядра (разжимает сжатое ядро и загружает его в память);
2)
ядро;
3)
библиотеку программиста LibC;
4)
набор системных утилит;
5)
упрощенную версию интерпретатора команд shell;
6)
набор тестовых программ и командных файлов для тестирования функциональности ядра;
7)
образ корневого диска с набором командных файлов и программ для инициализации;
8)
командные файлы, создающие бинарный файл с сжатым образом диска для файловых систем
ROMFS и EXT2FS;
9)
командные файлы, создающие бинарный файл со сжатым ядром и дисками для ПЗУ.
Стандартная конфигурация ядра операционной системы Plinux включает следующую функциональность:
1)
файловые системы RAMFS, ROMFS, EXT2FS, CRAMFS, DEVFS, PROCFS;
2)
драйверы устройств символьного доступа SERIAL, CONSOLE, PTY, TTY, MISC, RANDOM, RAW,
WATCHDOG, PIPE;
3)
драйверы устройств блочного доступа RAMDISK, LOOP;
4)
форматы исполняемых фалов ELF no PIC, ELF PIC, SCRIPT;
5)
менеджер памяти, функционирующий без MMU;
6)
поддержка процессора семейства R3000;
ISSN 1028-9763. Математичні машини і системи, 2002, № 3
51
7)
симуляция ряда команд процессора, не реализованных в нем аппаратно – RIS (Reserved Instruction
Set) -умножения, деления, чтения / записи по невыровненному адресу.
Разработанная операционная система имеет следующие параметры:
8)
версия прототипа ядра – Linux 2.4;
9)
размер сжатого ядра с сжатыми дисками в ПЗУ – 520 Кбайт;
10) размер разжатого ядра после инициализации в ОЗУ – 1.5 Мбайт;
11) количество свободной памяти для пользовательских задач – 6.5 Мбайт.
Выводы
Разработанная версия операционной системы Linux позволит упростить и ускорить разработку программного
обеспечения для устройств на базе процессоров семейства R3000. Разработка программного обеспечения
для операционной системы Plinux может осуществляться на языке программирования C, причем с учетом
стандарта POSIX. Соблюдение стандарта POSIX в операционной системе Plinux позволяет вести разработку
и отлаживать программы на любой операционной системе семейства Linux, а затем без изменений
компилировать исходные коды на языке C совместно с разработанной библиотекой программиста LibC для
использования в операционной системе Plinux.
Использование усеченной функциональности процессора (отсутствие MMU и математического модуля)
снижает его стоимость. Поэтому цена целевого устройства будет ниже по сравнению с аналогами
полнофункционального процессора. Последнее увеличивает его конкурентоспособность.
СПИСОК ЛИТЕРАТУРЫ
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
52
http://www.uclinux.org/ports - uClinux -- Embedded Linux/Microcontroller -- uClinux: Ports!.-2002.
Farquhar E., Spatz M. The MIPS programmer’s hand book.- Morgan Kaufman Publisher Inc, 1994.
http://www.mips.com/ /MIPS technologies home page.-2002.
http://www.cknow.com/ckinfo/acro_m/mmu_1.shtml /MMU - Memory Management Unit.-2001.
http://www.usb.org/ /USB (Universal Serial Bus) home page.-2002.
http://www.gnu.org/software/libc/libc.html /GNU C Library.-2001.
http://std.dkuug.dk/JTC1/SC22/WG15/ /The official home of JTC1/SC22/WG15 - POSIX!.-2002.
http://www.unix-systems.org/version3/ /The Single UNIX Specification Version 3 - incorporating IEEE Std 1003.1-2001 and
integrating the industry's Open Systems standards.-2001.
http://www.unix.org/what_is_unix.html /The UNIX System.-2002.
http://www.uclinux.org/description/ /uClinux is a derivative of Linux 2.0 kernel intended for microcontrollers without Memory
Management Units (MMUs).-2002.
http://uclinux.org/ /uCLinux - Embedded Linux/Microcontroller Project.-2002.
Beck M., Bohme H., Kunitz U. Linux kernel internals (second edition).- Addisson-Wesley GmbH, 1999.
Введение в операционные системы / И.Х. Зусман / Под ред. В.В. Мартынюк: Пер.на русский.-М.: Мир, 1975. Colin A.J.T.
Introduction to operating systems.- MacDonald/American Elsevir Computer Monographs, 1971.
http://www.cs.ucdavis.edu/~haungs/paper/node10.html - The Executable and Linking Format (ELF).-1998.
ISSN 1028-9763. Математичні машини і системи, 2002, № 3