Перенос ПО из QNX 4 в QNX/Neutrino Прожогин Сергей SWD RTS Ltd. Конференция QNX Россия сентября, Санкт-Петербург

Перенос ПО с ОС QNX 4 в ОС Neutrino Перенос ПО с ОС QNX 4 в ОС Neutrino. Встречайте новую ОС Среда разработки Особенности программных реализаций Методология перехода Утилита mig4nto Библиотека перехода

Встречайте новую ОС Архитектура Схожесть с QNX 4 Открытое POSIX API Масштабируемое для широкого круга задач ядро Многоплатформенная ОС x86 MIPS PowerPC Поддержка многопроцессорных систем Поддержка до 4-х гигабайт физической оперативной памяти

Встречайте новую ОС Переносимость Большая совместимость Hовые POSIX компоненты Новый функции из UNIX 98 и других стандартов Совместимость с QNX 4 Одинаковая файловая система Одинаковая система загрузки -> замените файл /.boot (/.altboot) на загрузчик Neutrino и загрузитесь с новой ОС!

Среда разработки Компилятор и средства разработки Используя GNU компилятор можно разрабатывать из: Neutrino QNX 4 MS-Windows Для MS-Windows, можно использовать CodeWarrior фирмы Metrowerks.

Среда разработки Поддержка статических и динамических библиотек. Отладка gdb отладчик CodeWarrior Загрузочные образы Схожи с QNX 4, но отсутствует сценарий sysinit, а язык сценария загрузки сильно расширен. Построение загрузочного образа Осуществляется с помощью утилиты mkifs.

Особенности программных реализаций Планирование Планирование выполняется по нитям. Запускается нить имеющая наибольший приоритет исполнения. FIFO раунд-робин адаптивное планирование Третий алгоритм называется SCHED_OTHER в соответствии с POSIX. Уровни приоритетов Количество приоритетов расширено с 0 до 63 (в QNX 4 с 0 до 31) Функции sched_get_priority_min() и sched_get_priority_max() возвращают 0 и 63. Нить может сама менять свой приоритет, но только для себя.

Особенности программных реализаций Большее количество состояний Добавлены состояния: SIGSUSPEND - при вызове функции sigsuspend(). SIGWAITINFO - при вызове функции sigwaitinfo(). NANOSLEEP - пока не истечет промежуток времени вызванный ф-цией nanosleep(). Добавлены два метода синхронизации CONDVAR MUTEX Процессы Создание процессов происходит семейством функций spawn*() вместо qnx_spawn(). Все флаги ф-ций spawn*() описаны в файле.

Особенности программных реализаций Поддерживается вызов fork(), но для многонитевого процесса необходимо использовать vfork(). Флаги процессов _PPF_IMMORTAL - больше не поддерживается. _PPF_INFORM - больше не поддерживается. _PPF_PRIORITY_FLOAT - устанавливается по умолчанию. _PPF_PRIORITY_REC - указывает поведение процесса. Обязателен. _PPF_SIGCATCH - получает поведение процесса. _PPF_SERVER - больше не поддерживается. Менеджеры ввода/вывода и ресурсов Реализована концепция менеджеров ввода-вывода, но предпочтительней пользоваться менеджером ресурсов. В Neutrino менеджер ресурсов включен как постоянная часть стандартной библиотеки. При ее использовании вы можете указать и использовать в своем приложении то, что вам необходимо и то, чем будет пользоваться клиент.

Особенности программных реализаций Сообщения Новая ОС все еще использует send/receive/reply механизм. Он реализуется функиями: MsgReceive*() MsgSend*() MsgReply*() MsgRead*() MsgWrite*() Идентификаторы каналов и идентификаторов процессов В Neutrino любая нить может создать свой канал прием-передачи. Соответственно данные отсылаются на ID канала, а не процесса как в QNX 4. При создании канала функцией ConnectAttach(), можно пересылать данные по ID канала, не используя ф-цию MsgSend*().

Особенности программных реализаций Нахождение принимающего процесса. 1.При необходимости переписать приемную часть, выполнив ее в виде менеджера ввода-вывода. Ф-ция ChannelCreate() выполниться из библиотеки менеджера ресурсов и ConnectAttach() вызовется ф-цией open(). Т.е. посылающая сторона найдет принимающую посредством ф-ции open(): fd = open(_name_receive_registered,...);... MsgSend(fd,...); 2.В Neutrino 2.1 включены ф-ции name_attach() и name_open(), как qnx_name_attach() и qnx_name_locate() в QNX 4. 3.Если приемная часть родительский процесс, а принимающая часть дочерний, то ID канала может быть передан как аргумент ф-ции spawn*(). 4.Если процесс запускает два других процесса, то он может создать канал и передать его идентификатор дочерним процессам через аргументы командной строки. Дочернии процессы могут передать соответствующие ID своих каналов процессу-родителю и затребовать отдельный каналы для себя.

Особенности программных реализаций 5.Следует писать менеджер как менеджер имен (по аналогии с Proc/nameloc в QNX 4). Приемная часть программы с ID канала будет выполнятся ф-цией open() для нахождения менеджера имен и передавать ему имя и ID канала. Посылающая сторона также может выполнить open() для нахождения менеджера имен и передачи ему имени приемной стороны для дальнешей связи с ней. Соответственно менеджер имен должен вернуть ID канала для связи. 6. Можно использовать библиотеку перехода. Она включает процесс mig4nto-procmgr, который обеспечивает выполнение ф-ций qnx_name_locate() и qnx_name_attach(). Несколько путей получения сообщений в ресурс менеджере POSIX - ф-ция devctl().Ресурс-менеджер вызовет io_devctl обработчик для регистрации и обработки сообщения. Функция message_attach(). Используется для регистрации группы типов сообщений и обработчика вызовов. Использование ф-ции MsgSend*() поместив заголовок с типом сообщения io_msg_t в начало сообщения.

Особенности программных реализаций Приоритеты сообщений Прием сообщений в порядке поступления является автоматическим. Плавающий приоритет Установлен по умолчанию, если поведение системы надо изменить - используйте флаг _NTO_CHF_FIXED_PRIORITY в ф-ции ChannelCreate(). Получение данных по сети Четвертый параметр ф-ции MsgReceive*() структура struct _msg_info. Она содержит переменную msglen, в которой число байт переданных в сообщении. В переменной srcmsglen будет число байт посланное передающим процессом, но только при установленном флаге _NTO_CHF_SENDER_LEN в ф-ции ChannelCreate().

Особенности программных реализаций События Передающий событие процесс вызывает ф-цию MsgDeliverEvent(). Имеет ID принимающего процесса и структуру события struct sigevent содержащую несколько полей: sigev_notify - тип события sigev_prioroty - приоритет события sigev_code и sigev_value - код и значение полей в пульсе. sigev_signo - номер сигнала, если пришедшее событие сигнал. Прокси и пульсы В Neutrino нет прокси механизмов. Вместо них пульсы. Пульсы асинхронны, их передача между процессами не блокирует процессы. Данные передаваемые с помощью пульсов могут меняться в процессе передачи.Каждый пульс в Neutrino соединен с двумя пунктами информации: 8-битное значение называемое "код" 32-битное значение называемое "данные"

Особенности программных реализаций Пульсы обрабатываются ф-циями обработчиками пульсов, который регистрируются ф-цией pulse_attach(). При использовании пульсов не в ресурс-менеджере, их можно обрабатывать ф-циями MsgReceive*() и MsgReceivePulse*(). Возращаемое значение 0 или буфер в котором будет содержаться структура struct _pulse. Сигналы Новый набор пользовательских сигналов. От SIGRTMIN до SIGRTMAX (определены в ). В соответствии с POSIX передаются с помощью очереди. Остались UNIX-сигналы. Существуют как часть POSIX. Если сигнал передается процессу несколько раз пока он заблокирован, то разблокирование произойдет один раз. Получения информацию о наличии сигнала в очереди, можно установив флаг SA_SIGINFO в переменной sa_flags структуры struct sigaction, передаваемой ф-ции sigaction(). Сигналы могут передавать данные.

Особенности программных реализаций Появилось несколько новых ф-ций: sigblock() sigqueue() sigsetmask() sigtimedwait() sigunblock() sigwait() sigwaitinfo() Сигналы и нити Обработка сигнала поддерживается на уровне процесса. Первый раз, процессу передается специальный сигнал, ядро ищет процесс готовый принять этот сигнал. Если все нити не принимают этот сигнал, сигнал передается на уровневый процесс до тех пор, пока какая-нибудь нить не станет способной принимать сигнал. Если больше чем одна нить способна принять сигнал, то ядро выбирает нить, способную обработать сигнал.

Особенности программных реализаций Если только одна нить способна обработать сигнал, то именно ей этот сигнал и будет передан. Необходимо оставить одну нить как обработчик сигнала, заблокировав во всех остальных. Эта, сигнал-обрабатывающая нить, должна вызывать sigwaitinfo() таким образом, что-бы отнимать как можно меньше ресурсов процессора при ожидании прихода сигнала. Разделяемая память В отличии от QNX 4 вместо ltrunc() используется ftruncate(). Ф-ции qnx_segment*() более не поддерживаются. Семафоры Ф-ции sem_init(), sem_wait(), sem_trywait(), sem_post() и sem_destroy() - поддерживаются без изменений. Также появились также именованные семафоры. Можно создавать семафор только для определенного процесса.

Особенности программных реализаций Именованные семафоры Введена поддержка POSIX-именованных семафоров.Они доступны для использовании по имени и размещены в разделяемой памяти. Для работы с ними надо запустить процесс mqueue. Создаются и уничтожаются ф-циями sem_open(), sem_close() и sem_unlink(). Ф-ции sem_wait() и sem_post() с анонимными семафорами используют ф-ции ядра,а именованные семафоров используется ф-ции приема-передачи сообщений (процесс mqueue), что медленее. POSIX очередь сообщений POSIX очередь сообщений выполнена как в QNX 4, с минимальными различиями: Имя сервера очереди сообщений mqueue, а не Mqueue. Флаги MQ_ больше не поддерживаются. У события посылаемого ф-цией mq_notify() изменился формат. Нельзя использовать прокси.

Особенности программных реализаций Таймеры Ф-ция qnx_adj_time() поменялась на ClockAdjust(). clock_setres() и qnx_ticksize() на ClockPeriod(). timer_create() не возвращает ID таймера. Идентификатор находится в третьем параметре ф-ции, при успешном завершении. Задержки Могут быть получены с ф-циями: TimerTimeout() или timer_timeout(). Различие между ними только в типах и параметрах. Прерывания Вместо qnx_hint_attach() использeтся InterruptAttach(). В Neutrino обработчик прерывания будет использовать сегмент данных процесса обработчика. Обработчик может возвращать событие с пульсом или сигналом с уведомлением SIGEV_INTR. В последнем случае можно добавить нить блокировки ф-цией InterruptWait().

Особенности программных реализаций Для получения прямого доступа к портам ввода-вывода в надо вызвать ThreadCtl(_NTO_TPRIV_IO, NULL) и иметь права суперпользователя. Для маскирования и демаскирования прерываний: InterruptMask() и InterruptUnmask(). Аппаратный ввод/вывод Ввод/вывод в порты x86 -выполнен с использованием специальных инструкций процессора. На PowerPC и MIPS, это сделано с использованием отображаемой памяти. Запись/чтение в память Осуществляется ф-циями mmap_device_memory(), mmap(): ПДП Осуществляется ф-цией mmap().

Особенности программных реализаций PCI функции В Neutrino семейства ф-ций начинаются с pci_*(). Необходимо запустить сервер PCI-процессов(pci-bios). Для связи с PIC-сервером надо вызвать pci_attach(). Получение системной информации qnx_osinfo() больше не доступна. Информация получается из разных частей ОС. Исходный текст qnx_osinfo() ф-ции содержит всю информацию о системе. Получение информации о процессах Для получения информации о процессах используется вызов devctl() с дескрипторомнужного процесса. Терминальные функции term_() Терминальные ф-ции более не поддерживаются. Используйте curses.

Методология перехода 1. Знакомство с ОС Neutrino. - Установка - Ознакомление с утилитами и программами аналогичными QNX. 2. Перенос Shell-скриптов и простейших утилит. 3. Перенос ПО в ОС Neutrino - Составление полного списка ПО третьих фирм (или их эквивалентов) - Составление списка приложений для переноса. - Разбиение приложений на сетевые и несетевые (несетевые лучше перенести первыми)

Изменения программ Анализ Определение участков кода, необходимых для замены или переработки. (Утилита mig4nto). Вопросы архитектуры Определение целесообразности переноса программы при наличии большого кол-ва QNX-ориентированных кусков кода. Перенос заголовочных файлов Замена файловых имен Замена идентификаторов узла с QNX 4 на Neutrino. Перенос функций и т.п. Изменение функций, обьявлений и структур данных присущих Neutrino. (Утилита mig4nto).

Утилита mig4nto Данная утилита определяет участки кода в программах QNX4 требующие внимания. Синтаксис: mig4nto [-qsr] [-o output_directory] [file...] Опции: -q Не выводить информацию о работе. -s Строгая проверка; позволяет проверять только функции поддерживаемые стандартом ANSI/POSIX. -r Создание только отчета -o output_directory Директория, куда будут записаны обработанные исходные тексты. file имя файла содержащего исходный код С-программы или заголовочный файл.

Утилита mig4nto Описание Утилита mig4nto определяет области кода, которым потребуется уделить внимание при переносе. Утилита копирует исходный текст и вставляет комментарии в каждую строку содержащую имя функции или директивы препроцессора требующей внимания. Эти комментарии содержат краткие рекомендации по курсу действий. Коды завершения работы: 0 - Нет файлов требующих замены. 1 - Один или несколько файлов требуют внимания. >1 - Произошла ошибка.

Эмулятор менеджера и библиотека переноса. Библиотека переноса содержит набор функций обеспечивающих ряд возможностей более не поддерживаемых или отличающихся в новой ОС. Менеждер процесов переноса (mig4nto-procmgr) должен быть запущен для того, что-бы все функции из библиотеки были доступны и выполнялись. Эмулятор менеджера процессов QNX4 (mig4nto-procmgr) Обеспечивает ряд дополнительных возможностей библиотеки переноса. Синтаксис: mig4nto-procmgr [-ntv] Опции: -n задание сетевого идентификатора(nid) как в QNX 4 -t Количество нитей (threads) для передачи прокси-сообщений -v Вывод дополнительной информации.

Эмулятор менеджера и библиотека переноса. Описание Эмулятор менеджера процессов QNX4 предоставляет возможности Proc32, имеющиеся в QNX4, но не реализованные в procnto (или реализованные иначе). Это: регистрация обнаружение имен регистрация прокси и пересылка прокси сообщений предоставление сетевого идентификатора (nid). Для работы с эмулятором менеджера процессов необходимо вызывать функцию mig4nto_init() в самом начале программы.

Эмулятор менеджера и библиотека переноса. Список переносимых функций требующих запуска: mig4nto-procmgr dev_arm() getnid() mig4nto_init() qnx_name_*() Read*() Receive*() Reply*() Send*() Trigger() Writemsg*()