Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

• абстрагировать, абстрагировать и еще раз абстрагировать;

• развязывать, развязывать и еще раз развязывать.

Ключ в том, чтобы отказаться от использования конкретного «дескриптора», который «связывал» бы клиента с сервером, и не привязываться к конкретному механизму обнаружения сервера. Если вы абстрагируете операции обнаружения сервера и установления соединения в отдельный набор функций, то вы сможете производить условную компиляцию для любой платформы, на которую вы пожелаете перенести ваш код.

Аналогичные рассуждения применимы и к транспортировке сообщений — всегда абстрагируйте клиентский API от «понимания» того, как сообщение доставляются от клиента к серверу, в некоторый универсальный API, который уже бы базировался на конкретном транспортном API. Затем этот конкретный транспортный API можно будет условно откомпилировать для любой платформы.

Перенос сервера из QNX4 в QNX/Neutrino является более трудной задачей вследствие того, что QNX4-серверы были сделаны «вручную» и никогда не следовали четкой структуре подобно тому, как это принято в библиотеке администраторов ресурсов в QNX/Neutrino. Впрочем, в общем случае, если вы переносите что-то сильно аппаратно-зависимое (например, аудиодрайвер или блок-ориентированный дисковый драйвер), основная часть портируемого кода никак не связна с операционной системой, и ой как связана с собственно аппаратурой. Подход, который я обычно использовал для таких случаев, состоит в том, чтобы запрограммировать каркас «драйвера» и обеспечить набор четко определенных аппаратно-зависимых функций. Каркас будет отличаться для разных операционных систем, но аппаратно-зависимые функции получатся на удивление переносимыми.

Независимо от того, насколько вы хороший программист, иногда возникают моменты, когда вы:

• сталкиваетесь с проблемой, которую не можете решить;

• выявили ошибку и хотите сообщить о ней и/или найти обходной путь;

• сталкиваетесь с необходимостью консультации по реализации проекта.

В этой главе мы рассмотрим ресурсы, необходимые при разрешении подобных проблем.

Мы обсудим первые две проблемы вместе, потому что подчас бывает трудно определить, с которой из них имеешь дело.

Предположим, что что-то вдруг перестало работать или работает не так, как ожидается. Что делать?

Читайте документацию! (Оригинальный перевод аббревиатуры RTFM широко известен, поэтому приводить его здесь не будем; любопытные могут затянуть в словарь — например, http://www.instantweb.com/foldoc/ — прим. ред.) Несмотря на то, что это может показаться элементарным и очевидным первым шагом, число людей, которые этого не делают, просто поразительно!

Все нижеперечисленные справочные руководства по QNX/Neutrino доступны он-лайн:

• «Building Embedded Systems» («Построение встраиваемых систем»);

• «Development Tools» («Средства разработки»);

• «Library Reference» («Справочник по библиотекам»);

• «System Architecture» («Системная архитектура»);

• «Technotes» («Технические замечания»);

• «Utilities Reference» («Справочник по утилитам»).

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

Это справочник по различным средствам разработки, о которых упоминается в книге «Построение встраиваемых систем» — там есть документация по GNU-компилятору и сопутствующим инструментальным средствам, описания средств формирования образов, и т.д. Это прекрасный источник информации для тех случаев, когда инструмент ведет себя не так, как вы от него ожидаете, или когда нужно понять, как работает тот или иной инструмент.

Это руководство по вызовам Си-библиотеки QNX/Neutrino — от А до Z. Применительно к вызовам функций это — истина в высшей инстанции. Я часто ссылался на это издание в предыдущих главах (например, за более подробной информацией о конкретной функции — скажем, о ее редко используемых аргументах).

«Высокоуровневый» документ по системной архитектуре QNX/Neutrino, описывающий ее «сверху» и в то же время приводящий достаточно подробное описание реализации, из которого вы сможете понять, что из себя представляют компоненты системы, и как они связаны между собой.

Серия книг «Технические замечания» содержит описание специфических особенностей QNX/Neutrino и может меняться от версии к версии. Посмотрите онлайновую версию этих документов, чтобы узнать, что характерно для имеющейся у вас версии QNX/Neutrino. Например, для релиза QNX/Neutrino 2.00 BETA 5 в серии «Технические замечания» были рассмотрены следующие темы:

• Переход с Neutrino 1.X на версию 2.0;

• Интерфейс диспетчеризации в QNX/Neutrino 2.0.

Этом алфавитный справочник по доступным командно-строковым утилитам. Он описывает все утилиты, не относящиеся к средствам разработки, то есть те, которые не охвачены справочником «Средства разработки» — grep, саt, echo, и т.д.

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

Обращаться за помощью в группу технической поддержки QSSL можно двояко: либо по телефону, либо через телеконференции QUICS (еще раз отмечу: эта информация устарела, на настоящий момент QUICS упразднена в пользу QDN (http://qdn.qnx.com, nntp://inn.qnx.com) — прим. ред.).

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

Как правило, заказчики пытаются решить проблему самостоятельно, пробуя различные варианты, которые им приходят на ум. Это великолепно. Только, к сожалению, это часто приводит к тому, что заказчик приходит в уныние и вывешивает в телеконференцию сообщение типа:

«Я тут запустил TCP/IP, пытаюсь соединиться

с Windows-машиной, а оно не работает.

В чем дело?!?»

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

Что значит «не работает»? Вы имеете в виду TCP/IP на

стороне QNX или на стороне Windows? Какой модуль TCP/IP

не работает? Что вы пытаетесь сделать? Какие у вас

версии QNX и TCP/IP? Какая у вас версия Windows и какой

там TCP/IP?

Мораль сей басни такова: если у вас проблема, то вам, вероятно, надо ее решить быстро. Если вам нужен ответ на вопрос быстро, постарайтесь привести максимум информации о возникшей у вас проблеме в первом же запросе, чтобы специалисты технической поддержки QSSL сразу же смогли попробовать воспроизвести вашу проблемную ситуацию.

Существует ряд вещей, которые служба технической поддержки спрашивает всегда. К ним относятся:

• точное описание сбоя;

• версии программных продуктов;

• конфигурация системы;

• аппаратная платформа (x86, РРС, и т.д.)

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

Я пытаюсь подсоединиться по telnet из QNX/Neutrino 2.00A к Windows-машине и сразу же после приглашения login получаю сообщение «Connection closed by foreign host».

Следующее, что следует указать, — это информация о версиях различных модулей, которые вы используете. Ее можно взять от команд ls и cksum. В случае с нашим примером хорошо было бы бы сообщить службе техподдержки, какая у вас версия команды telnet, стека TCP/IP, и т.д.