‘истемнаЯ архитектура QNX4

---------------------------------------------------------------
     (‘) QNX Software Systems Ltd., 1996
     Ђвтор: QNX Software Systems Ltd.
     ђусское издание: SWD Software Ltd.
     WWW: http://www.swd.ru/qnx/support/literature/sysarch/
     E-mail: books.qnx@swd.ru
     Date: 04 Mar 2002
---------------------------------------------------------------

‚первые на русском Языке книга о QNX. ђоб Љертен "‚ведение в QNX/Neutrino 2". ЂннотациЯ, ‡аказ печатной версии(400 р.)

‘истемнаЯ архитектура QNX4

Љнига ‘истемнаЯ архитектура сопровождает операционную систему QNX и предназначена как длЯ разработчиков приложений, так и длЯ конечных пользователей.

‚ книге подробно рассматриваетсЯ структура и функции QNX. ‚ ней описаны микроЯдро, системные менеджеры, а также уникальный механизм свЯзи между процессами, основанный на передаче сообщений. Џрежде чем использовать QNX, рекомендуетсЯ сначала прочитать эту книгу.

‡а информацией об установке и использовании QNX, обратитесь к книге ђуководство пользователЯ Ћ‘ QNX

‘истемнаЯ архитектура содержит следующие главы:

ЉонцепциЯ QNX;
ЊикроЯдро;
Њенеджер процессов;
Џространство имен ввода/вывода;
Њенеджер файловой системы;
Њенеджер устройств;
Њенеджер сети;
ЋконнаЯ система Photon microGUI.

ЉонцепциЯ QNX

ќта глава охватывает следующие темы:

что такое QNX?;
архитектура микроЯдра;
свЯзь между процессами (IPC);
QNX как сеть.

—то такое QNX?

ѓлавнаЯ обЯзанность операционной системы состоит в управлении ресурсами компьютера. ‚се действиЯ в системе - диспетчеризациЯ прикладных программ, запись файлов на диск, пересылка данных по сети и т.п. - должны выполнЯтьсЯ совместно настолько слитно и прозрачно, насколько это возможно.

Ќекоторые области применениЯ предъЯвлЯют более жесткие требованиЯ к управлению ресурсами и диспетчеризации программ, чем другие. ЏриложениЯ реального времени, например, полагаютсЯ на способность операционной системы обрабатывать многочисленные событиЯ в пределах ограниченного интервала времени. —ем быстрее реагирует операционнаЯ система, тем большее пространство длЯ маневра имеет приложение реального времени в пределах жестких временных рамок.

ЋперационнаЯ система QNX идеальна длЯ приложений реального времени. Ћна обеспечивает все неотъемлемые составлЯющие системы реального времени: многозадачность, диспетчеризацию программ на основе приоритетов и быстрое переключение контекста.

QNX - удивительно гибкаЯ система. ђазработчики легко могут настроить операционную систему таким образом, чтобы она отвечала требованиЯм конкретных приложений. QNX позволЯет вам создать систему, использующую только необходимые длЯ решениЯ вашей задачи ресурсы. ЉонфигурациЯ системы может изменЯтьсЯ в широком диапазоне - от Ядра с несколькими небольшими модулЯми до полноценной сетевой системы, обслуживающей сотни пользователей.

QNX достигает своего уникального уровнЯ производительности, модульности и простоты благодарЯ двум фундаментальным принципам:

архитектура на основе микроЯдра;
свЯзь между процессами на основе сообщений.

Ђрхитектура микроЯдра системы QNX

QNX состоит из небольшого Ядра, координирующего работу взаимодействующих процессов. Љак показано на рисунке, структура больше напоминает не иерархию, а команду, в которой несколько игроков одного уровнЯ взаимодействуют между собой и со своим "защитником" - Ядром.

fig: i/modules.gif

ЊикроЯдро системы QNX координирует работу системных менеджеров.

ЌастоЯщее Ядро

џдро - это "сердце" любой операционной системы. ‚ некоторых операционных системах на него возлагаетсЯ так много функций, что Ядро, по сути, заменЯет всю операционную систему!

‚ QNX же ЊикроЯдро - это настоЯщее Ядро. ‚о-первых, как и следует Ядру реального времени, Ядро QNX имеет очень маленький размер. ‚о-вторых, оно выполнЯет две важнейшие функции:

передача сообщений - ЊикроЯдро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе;
диспетчеризациЯ - планировщик - это часть ЊикроЯдра, и он получает управление всЯкий раз, когда процесс изменЯет свое состоЯние в результате получениЯ сообщениЯ или прерываниЯ.

‚ отличие от всех остальных процессов, Ядро никогда не получает управлениЯ в результате диспетчеризации. ‚ходЯщий в состав Ядра код выполнЯетсЯ только в результате прЯмых вызовов из процесса или аппаратного прерываниЯ.

‘истемные процессы

‚се услуги операционной системы, за исключением тех, которые выполнЯютсЯ Ядром, в QNX предоставлЯютсЯ через стандартные процессы. ’ипичнаЯ конфигурациЯ QNX имеет следующие системные процессы:

Њенеджер процессов (Proc);
Њенеджер файловой системы (Fsys);
Њенеджер устройств (Dev);
Њенеджер сети (Net).

‘истемные и пользовательские процессы

‘истемные процессы практически ничем не отличаютсЯ от любых написанных пользователем программ - они не имеют какого-либо скрытого или особого интерфейса, недоступного пользовательским процессам.

€менно за счет такой системной архитектуры QNX обладает уникальной наращиваемостью. ’ак как большинство услуг операционной системы предоставлЯютсЯ стандартными процессами QNX, то расширение операционной системы требует всего лишь написаниЯ новой программы, обеспечивающей новую услугу!

”актически, граница между операционной системой и прикладной программой может быть очень размыта. …динственный критерий, по которому мы можем отличить прикладные процессы и системные сервисные процессы, состоит в том, что процесс операционной системы управлЯет каким-либо ресурсом в интересах прикладного процесса.

Џредположим, что вы написали сервер базы данных. Љак же должен быть классифицирован этот процесс?

’очно так же, как сервер файловой системы принимает запросы (в QNX реализованные через механизм сообщений) на открытие файлов и запись или чтение данных, это будет делать и сервер базы данных. •отЯ запросы к серверу базы данных могут быть и более сложными, сходство обоих серверов заключаетсЯ в том, что оба они обеспечивают доступ к ресурсу посредством запросов. Ћба они ЯвлЯютсЯ независимыми процессами, которые могут быть написаны пользователем и запускатьсЯ по мере необходимости.

‘ервер базы данных может рассматриватьсЯ как процесс в одном случае и как приложение в другом. ќто действительно не имеет значениЯ! ‚ажно то, что создание и выполнение таких процессов в QNX не требует абсолютно никаких изменений в стандартных компонентах операционной системы.

„райверы устройств

„райверы устройств - это процессы, которые ЯвлЯютсЯ посредниками между операционной системой и устройствами и избавлЯют операционную систему от необходимости иметь дело с особенностЯми конкретных устройств.

’ак как драйверы запускаютсЯ как обычные процессы, добавление нового драйвера в QNX не влиЯет на другие части операционной системы. ’аким образом, добавление нового драйвера в QNX не требует ничего, кроме непосредственно запуска этого драйвера.

Џосле запуска и завершениЯ процедуры инициализации, драйвер может выбрать один из двух вариантов поведениЯ:

стать расширением определенного системного процесса;
продолжать выполнение как независимый процесс.

‘вЯзь между процессами (IPC)

‚ типичной длЯ многозадачной системы реального времени ситуации, когда несколько процессов выполнЯютсЯ одновременно, операционнаЯ система должна предоставить механизмы, позволЯющие им общатьсЯ друг с другом.

‘вЯзь между процессами (Interprocess communication, сокращенно IPC) ЯвлЯетсЯ ключом к разработке приложений как совокупности процессов, в которых каждый процесс выполнЯет отведенную ему часть общей задачи.

QNX предоставлЯет простой, но мощный набор возможностей IPC, которые существенно облегчают разработку приложений, состоЯщих из взаимодействующих процессов.

Џередача сообщений

QNX была первой коммерческой операционной системой своего класса, котораЯ использовала передачу сообщений в качестве основного способа IPC. €менно последовательное воплощение метода передачи сообщениЯ в масштабах всей операционной системы обусловливает мощность, простоту и элегантность QNX.

‘ообщениЯ в QNX - это последовательность байт, передаваемых от одного процесса другому. ЋперационнаЯ система не пытаетсЯ анализировать содержание сообщениЯ - передаваемые данные имеют смысл только длЯ отправителЯ и получателЯ, и ни длЯ кого более.

Џередача сообщениЯ позволЯет не только обмениватьсЯ данными, но и ЯвлЯетсЯ способом синхронизации выполнениЯ нескольких процессов. Љогда они посылают, получают или отвечают на сообщениЯ, процессы претерпевают различные "изменениЯ состоЯниЯ", которые влиЯют на то, когда и как долго они могут выполнЯтьсЯ. ‡наЯ состоЯниЯ и приоритеты процессов, Ядро организует их диспетчеризацию таким образом, чтобы максимально эффективно использовать ресурсы центрального процессора (–Џ).

Џриложение реального времени и другие ответственные приложениЯ по праву нуждаютсЯ в надежном механизме передачи сообщений, т.к. входЯщие в состав этих приложений процессы тесно взаимосвЯзаны. ђеализованный в QNX механизм передачи сообщений способствует упорЯдочению и повышению надежности программ.

QNX как сеть

‚ простейшем случае локальнаЯ сеть обеспечивает разделЯемый доступ к файлам и периферийным устройствам длЯ нескольких соединенных между собой компьютеров. QNX идет гораздо дальше этого простейшего представлениЯ и объединЯет всю сеть в единый однородный набор ресурсов.

‹юбой процесс на любом компьютере в составе сети может непосредственно использовать любой ресурс на любом другом компьютере. ‘ точки зрениЯ приложений, не существует никакой разницы между местным или удаленным ресурсом, и использование удаленных ресурсов не требует каких-либо специальных средств. Ѓолее того, чтобы определить, находитсЯ ли такой ресурс как файл или устройство на локальном компьютере или на другом узле сети, в программу потребуетсЯ включить специальный дополнительный код!

Џользователи могут иметь доступ к файлам по всей сети, использовать любое периферийное устройство, запускать программы на любом компьютере сети (при условии, что они имеют надлежащие полномочиЯ). ‘вЯзь между процессами осуществлЯетсЯ единообразно, независимо от их местоположениЯ в сети. ‚ основе такой прозрачной поддержки сети в QNX лежит всеобъемлющаЯ концепциЯ IPC на основе передачи сообщений.

Њодель единого компьютера

QNX изначально проектировалсЯ как сетеваЯ операционнаЯ система. ‚ некоторых отношениЯх QNX сеть напоминает скорее большую ќ‚Њ, нежели набор мини-компьютеров. ЏользователЯм известно, что в распорЯжении любой из прикладных программ имеетсЯ большой набор ресурсов. Ќо в отличие от большой ќ‚Њ, QNX обеспечивает быструю реакцию системы, т.к. соответствующий объем вычислительных ресурсов может быть выделен на каждом узле в соответствии с потребностЯми каждого пользователЯ.

‚ условиЯх управлениЯ производством используютсЯ программируемые контроллеры и другие устройства ввода/вывода, а также комплексы программ, работающие в режиме реального времени, которым может потребоватьсЯ больше ресурсов, чем другим менее ответственным приложениЯм, таким как текстовый редактор. ‘еть QNX достаточно "отзывчива", чтобы поддерживать одновременно оба этих типа приложений, QNX позволЯет сфокусировать вычислительную мощность системы на производственном оборудовании (там, где это необходимо), в то же времЯ, не жертвуЯ интерфейсом пользователЯ.

ѓибкаЯ поддержка сети

QNX сеть может быть построена с использованием различного оборудованиЯ и стандартных промышленных протоколов. ‚ силу своей полной прозрачности длЯ прикладных программ и пользователей, новые сетевые архитектуры могут быть внедрены в любое времЯ, не разрушаЯ операционной системы.

‘писок поддерживаемого QNX сетевого оборудованиЯ пополнЯетсЯ со временем. „лЯ получениЯ подробной информации обратитесь к документации на сетевое оборудование, которое вы используете.

Љаждому узлу QNX сети присваиваетсЯ уникальный номер, который становитсЯ его идентификатором. ќтот номер также единственный видимый признак того, функционирует QNX как сеть или как однопроцессорнаЯ операционнаЯ система.

’акаЯ степень прозрачности ЯвлЯетсЯ еще одним примером больших возможностей архитектуры QNX, основанной на передаче сообщений. ‚о многих операционных системах такие важные функции как поддержка сети, IPC или даже передача сообщений выполнены в виде надстроек над операционной системой, а не интегрированы непосредственно в ее сердцевину. ђезультатом такого подхода ЯвлЯетсЯ неуклюжий и неэффективный интерфейс с "двойным стандартом", когда свЯзь между процессами - это одно дело, в то времЯ как проникновение в скрытый интерфейс таинственного монолитного Ядра - совершенно другое дело!

QNX, напротив, исходит из того, что эффективнаЯ свЯзь ЯвлЯетсЯ ключом к эффективной работе. Џередача сообщений ЯвлЯетсЯ, таким образом, краеугольным камнем архитектуры QNX, увеличивает эффективность всех без исключениЯ транзакций между процессами в системе, независимо от того, идет ли речь о передаче данных по внутренней шине персонального компьютера или по коаксиальному кабелю на расстоЯние нескольких миль.

’еперь давайте перейдем к более подробному рассмотрению структуры QNX.

ЊикроЯдро

ќта глава охватывает следующие темы:

введение;
свЯзь между процессами (IPC);
IPC посредством сообщений;
IPC посредством прокси;
IPC посредством сигналов;
IPC в сети;
IPC посредством семафоров;
диспетчеризациЯ процессов;
несколько слов о реальном времени.

‚ведение

ЊикроЯдро QNX отвечает за выполнение следующих функций:

свЯзь между процессами - ЊикроЯдро управлЯет маршрутизацией сообщений; оно также поддерживает две другие формы IPC - прокси и сигналы;
сетевой интерфейс низкого уровнЯ - ЊикроЯдро осуществлЯет доставку всех сообщений, предназначенных длЯ процессов на других узлах сети;
диспетчеризациЯ процессов - входЯщий в состав џдра планировщик решает, какому из запущенных процессов должно быть передано управление;
первичнаЯ обработка прерываний - все аппаратные прерываниЯ и исключениЯ сначала проходЯт через ЊикроЯдро, а затем передаютсЯ соответствующему драйверу или системному менеджеру.

fig: i/kernel.gif

‚нутри микроЯдра QNX.

‘вЯзь между процессами

ЊикроЯдро QNX поддерживает три важнейшие формы свЯзи между процессами: сообщениЯ, прокси и сигналы.

‘ообщениЯ - это основополагающаЯ форма IPC в QNX. Ћни обеспечивают синхронную свЯзь между взаимодействующими процессами, когда процессу, посылающему сообщение, требуетсЯ получить подтверждение того, что оно получено и, возможно, ответ.
Џрокси - это особый вид сообщениЯ. Ћни больше всего подходЯт длЯ извещениЯ о наступлении какого-либо событиЯ, когда процессу, посылающему сообщение, не требуетсЯ вступать в диалог с получателем.
‘игналы - это традиционнаЯ форма IPC. Ћни используютсЯ длЯ асинхронной свЯзи между процессами.

IPC посредством сообщений

‘ообщениЯ в QNX - это пакеты байт, которые синхронно передаютсЯ от одного процесса к другому. QNX при этом не анализирует содержание сообщениЯ. Џередаваемые данные понЯтны только отправителю и получателю и никому более.

Џримитивы передачи сообщений

„лЯ непосредственной свЯзи друг с другом взаимодействующие процессы используют следующие функции Языка программированиЯ ‘и:

”ункциЯ Языка ‘и: Ќазначение:
Send() посылка сообщений
Receive() получение сообщений
Reply() ответ процессу, пославшему сообщение

”ункциЯ Языка ‘и:	Ќазначение:
Send()	посылка сообщений
Receive()	получение сообщений
Reply()	ответ процессу, пославшему сообщение

ќти функции могут быть использованы как локально, т.е. длЯ свЯзи между процессами на одном компьютере, так и в пределах сети, т.е. длЯ свЯзи между процессами на разных узлах.

‘ледует заметить, однако, что далеко не всегда возникает необходимость использовать функции Send(), Receive() и Reply() в Явном виде. Ѓиблиотека функций Языка ‘и в QNX построена на основе использованиЯ сообщений - в результате, когда процесс использует стандартные механизмы передачи данных (такие, как, например, программный канал - pipe), он косвенным образом использует передачу сообщений.

fig: i/messpass.gif

Џроцесс A посылает сообщение процессу B, который получает его, обрабатывает и посылает ответ

Ќа рисунке изображена последовательность событий, имеющих место, когда два процесса, процесс A и процесс B, используют функции Send(), Receive() и Reply() длЯ свЯзи друг с другом:

Џроцесс A посылает сообщение процессу B, вызвав функцию Send(), котораЯ передает соответствующий запрос Ядру. ‚ этот момент времени процесс A переходит в SEND-блокированное состоЯние и остаетсЯ в этом состоЯнии до тех пор, пока процесс B не вызовет функцию Receive() длЯ получениЯ сообщениЯ.
Џроцесс B вызывает Receive() и получает сообщение от процесса A. Џри этом состоЯние процесса A изменЯетсЯ на REPLY-блокирован. Џроцесс B при вызове функции Receive() в данном случае не блокируетсЯ, т.к. к этому моменту его уже ожидало сообщение от процесса A.
‡аметьте, что если бы процесс B вызвал Receive() до того, как ему было послано сообщение, то он бы попал в состоЯние RECEIVE-блокирован до получениЯ сообщениЯ. ‚ этом случае процесс-отправитель сообщениЯ немедленно после посылки сообщениЯ попал бы в состоЯние REPLY-блокирован.
Џроцесс B выполнЯет обработку полученного от процесса A сообщениЯ и затем вызывает функцию Reply(). Ћтветное сообщение передаетсЯ процессу A, который переходит в состоЯние готовности к выполнению. ‚ызов Reply() не блокирует процесс B, который также готов к выполнению. Љакой из этих процессов будет выполнЯтьсЯ, зависит от их приоритетов.

‘инхронизациЯ процессов

Џередача сообщений не только позволЯет процессам обмениватьсЯ данными, но и предоставлЯет механизм синхронизации выполнениЯ нескольких взаимодействующих процессов.

„авайте снова рассмотрим приведенный выше рисунок. Џосле того как процесс A вызвал функцию Send(), он не может продолжать выполнение до тех пор, пока не получит ответ на посланное сообщение. ќто гарантирует, что выполнЯемаЯ процессом B по запросу процесса A обработка данных будет завершена прежде, чем процесс A продолжит выполнение. Ѓолее того, после вызова процессом B запроса на получение данных Receive(), он не может продолжать выполнение до тех пор, пока не получит следующее сообщение.

Ѓолее подробно диспетчеризациЯ процессов в QNX рассматриваетсЯ в разделе "„испетчеризациЯ процессов" далее в этой главе.

Ѓлокированные состоЯниЯ

Љогда процессу не разрешаетсЯ продолжать выполнение, т.к. он должен ожидать окончаниЯ определенной стадии протокола передачи сообщениЯ, - процесс называетсЯ блокированным.

‚озможные блокированные состоЯниЯ процессов приведены в следующей таблице:

…сли процесс выдал: ’о процесс:
‡апрос Send(), и отправленное им сообщение еще не получено процессом-получателем SEND-блокирован
‡апрос Send(), и отправленное им сообщение получено процессом-получателем, но ответ еще не выдан REPLY-блокирован
‡апрос Receive(), но еще не получил сообщение RECEIVE-блокирован

…сли процесс выдал:	’о процесс:
‡апрос Send(), и отправленное им сообщение еще не получено процессом-получателем	SEND-блокирован
‡апрос Send(), и отправленное им сообщение получено процессом-получателем, но ответ еще не выдан	REPLY-блокирован
‡апрос Receive(), но еще не получил сообщение	RECEIVE-блокирован

fig: i/states.gif

€зменение состоЯниЯ процессов в типичном случае передачи сообщениЯ.

„лЯ получениЯ информации обо всех возможных состоЯниЯх процесса смотри главу "Њенеджер процессов".

€спользование Send(), Receive() и Reply()

„авайте теперь более подробно рассмотрим вызовы функций Send(), Receive() и Reply(). ‚оспользуемсЯ рассмотренным выше примером передачи сообщениЯ от процесса A к процессу B.

”ункциЯ Send()

Џредположим, что процесс Ђ выдает запрос на передачу сообщениЯ процессу ‚. ќто выполнЯетсЯ посредством вызова функции Send():

Send( pid, smsg, rmsg, smsg_len, rmsg_len );

Џри вызове функции Send() используютсЯ следующие аргументы:

pid: идентификатор процесса (process ID), которому предназначаетсЯ сообщение (т.е. процесса B); этот идентификатор используетсЯ длЯ обращениЯ к процессу со стороны операционной системы и других процессов;
smsg: буфер сообщениЯ (т.е. сообщение, подлежащее посылке)
rmsg: буфер ответа (будет содержать ответ от процесса B)
smsg_len: длина посылаемого сообщениЯ в байтах
rmsg_len: максимальнаЯ длина ответа, который может принЯть процесс A, в байтах

Ћбратите внимание, что будет передано не более smsg_len байт и не более чем rmsg_len байт будет получено в качестве ответа - это гарантирует, что не произойдет случайного переполнениЯ буферов.

”ункциЯ Receive()

‚ызвав запрос Receive(), процесс B может получить сообщение, направленное ему процессом A:

pid = Receive( 0, msg, msg_len )

‚ызов функции Receive() содержит следующие аргументы:

pid: идентификатор процесса, который послал сообщение (т.е. процесс A)
0: (ноль) означает, что процесс B желает принЯть сообщение от любого процесса
msg: буфер, куда будет помещено принимаемое сообщение
msg_len: максимальный размер данных, которые будут помещены в буфер приема, в байтах

…сли значениЯ аргументов smsg_len в вызове функции Send() и msg_len в вызове функции Receive() отличаютсЯ, друг от друга, то наименьшее из них определЯет размер данных, которые будут переданы.

”ункциЯ Reply()

Џосле успешного получениЯ сообщениЯ от процесса A, процесс B должен ответить процессу A, вызвав функцию Reply():

Reply( pid, reply, reply_len );

‚ызов функции Reply() содержит следующие аргументы:

pid: идентификатор процесса, которому предназначаетсЯ ответ (т.е. процесс A)
reply: буфер, содержащий ответ
reply_len: длина данных, передаваемых в качестве ответа, в байтах

…сли значениЯ аргументов reply_len при вызове функции Reply() и rmsg_len при вызове функции Send() отличаютсЯ друг от друга, то наименьшее из них определЯет размер передаваемых данных.

Reply-управлЯемый обмен сообщениЯми

Џример обмена сообщениЯми, который мы только что рассмотрели, иллюстрирует наиболее распространенный случай использованиЯ сообщений - случай, когда длЯ процесса, выполнЯющего функции сервера, нормальным ЯвлЯетсЯ состоЯние RECEIVE-блокирован в ожидании каких-либо запросов клиента. ќто называетсЯ send-управлЯемый обмен сообщениЯми: процесс-клиент инициирует действие, посылаЯ сообщениЯ, ответ сервера на сообщение завершает действие.

‘уществует и другаЯ модель обмена сообщениЯми, не столь распространеннаЯ, как рассмотреннаЯ выше, хотЯ в некоторых ситуациЯх она даже более предпочтительна: reply-управлЯемый обмен сообщениЯми, при котором действие инициируетсЯ вызовом функции Reply(). ‚ этом случае процесс-"работник" посылает серверу сообщение, говорЯщее о том, что он готов к работе. ‘ервер не отвечает сразу, а "запоминает", что работник готов выполнить его задание. ‚ последствии сервер может инициировать действие, ответив ожидающему задание работнику. Џроцесс-работник выполнит задание и завершит действие, послав серверу сообщение, содержащее результаты своей работы.

„ополнительные сведениЯ

Џри разработке программ, использующих передачу сообщений, необходимо иметь в виду следующее:

сообщение сохранЯетсЯ в теле посылающего процесса до тех пор, пока принимающий процесс не будет готов получить его. ‘ообщение не копируетсЯ в ЊикроЯдро. ќто безопасно, т.к. посылающий процесс SEND-блокирован и не может неумышленно изменить содержимое сообщениЯ
при вызове функции Reply() данные копируютсЯ из отвечающего процесса в REPLY-блокированный процесс как одна неразрывнаЯ операциЯ. ‚ызов функции Reply() не блокирует процесс - REPLY-блокированный процесс перестает быть блокированным после того, как в него скопированы данные;
при посылке сообщениЯ процессу не требуетсЯ знать состоЯние того процесса, которому это сообщение адресовано. …сли получатель не готов к приему сообщениЯ в момент его отправки, то посылающий сообщение процесс просто становитсЯ SEND-блокирован;
если это необходимо, то процесс может посылать сообщение нулевой длины, ответ нулевой длины, либо и то и другое;
с точки зрениЯ разработчика, использование Send() длЯ передачи процессу-серверу запроса на получение какой-либо услуги равнозначно вызову библиотечной подпрограммы, предоставлЯющей ту же самую услугу. ‚ обоих случаЯх ваша программа сначала подготавливает определенные данные, а затем вызывает либо функцию Send(), либо библиотечную подпрограмму, после чего ожидает, когда они закончат выполнение. ‚ обоих случаЯх код, реализующий запрашиваемую услугу, выполнЯетсЯ между двумЯ четко определенными точками - Receive() и Reply() длЯ процесса-сервера, входом в подпрограмму и командой return длЯ вызова библиотечной подпрограммы. Љогда вызываемаЯ сервиснаЯ программа завершена, ваша программа "знает", куда помещены результаты, и может приступить к проверке возвращенного кода ошибки, обработке результатов и так далее.
ЌесмотрЯ на такую кажущуюсЯ простоту, вызов функции Send() делает гораздо больше, чем простой вызов библиотечной подпрограммы. ”ункциЯ Send() может прозрачно длЯ вызывающей программы передать запрос на другой узел сети, где и будет в действительности выполнЯтьсЯ обслуживающий запрос код. Џри этом также может быть задействована параллельнаЯ обработка данных без издержек на создание нового процесса. Џроцесс-сервер может сразу, как только станет возможным, вызвать функцию Reply(), позволЯЯ тем самым запрашивавшему процессу возобновить выполнение и, в то же времЯ, продолжить выполнение самому.
возможна ситуациЯ, когда сообщениЯ от многих процессов одновременно ожидают своей обработки одним и тем же принимающим процессом. Љак правило, принимающий процесс получает сообщение в том же порЯдке, в каком они были посланы другими процессами; однако принимающий процесс может установить очередность получениЯ сообщений на основе приоритетов посылающих процессов.

fig: i/blocproc.gif

‘ервер получил сообщение от клиента A и клиента B (но еще не ответил им). ‘ообщениЯ от клиентов C, D, E еще не получены.

„ополнительные возможности

QNX также предоставлЯет следующие дополнительные возможности по передаче сообщений:

условный прием сообщений;
чтение или запись части сообщений;
составные сообщениЯ (сообщениЯ, состоЯщие из нескольких частей).

“словный прием сообщений

Ћбычно, когда процесс хочет принЯть сообщение, он вызывает функцию Receive() длЯ ожиданиЯ прихода сообщениЯ. ќто обычный способ получениЯ сообщений, который пригоден в большинстве случаев.

Ћднако возможна ситуациЯ, когда процессу необходимо определить, имеютсЯ ли ожидающие приема сообщениЯ, не попадаЯ при этом в состоЯние RECEIVE-блокирован в случае их отсутствиЯ. Ќапример, процессу требуетсЯ опрашивать работающее с высокой скоростью устройство, которое не способно генерировать прерывание, и в то же времЯ он должен отвечать на сообщениЯ от других процессов. ‚ этом случае процесс может использовать функцию Creceive(), котораЯ либо прочитает ожидающее приема сообщение, либо немедленно вернет управление процессу в случае отсутствиЯ ожидающих приема сообщений.

‘ледует по возможности избегать использованиЯ функции Creceive(), т.к. она позволЯет процессу непрерывно выполнЯтьсЯ с неизменЯющимсЯ уровнем приоритета.

—тение или запись части сообщениЯ

€ногда желательно читать или записывать сообщениЯ по частЯм с тем, чтобы использовать уже выделенный длЯ сообщениЯ буфер вместо выделениЯ отдельного рабочего буфера.

Ќапример, менеджер ввода/вывода может принимать данные в виде сообщений, которые состоЯт из заголовка фиксированной длины и следующих за ним данных переменной длины. ‚ заголовке указываетсЯ размер данных (от 0 до 64 Љбайт). ‚ этом случае менеджер ввода/вывода может сначала принЯть только заголовок сообщениЯ, а затем использовать функцию Readmsg() длЯ чтениЯ данных переменной длины непосредственно в соответствующий буфер вывода. …сли размер данных превышает размер буфера, то менеджер может неоднократно вызывать функцию Readmsg() по мере освобождениЯ буфера вывода. Ђналогичным образом, функциЯ Writemsg() может быть использована длЯ поэтапного копированиЯ данных в выделенный длЯ ответного сообщениЯ буфер непосредственно в теле процесса, пославшего сообщение, уменьшаЯ, таким образом, потребность менеджера ввода/вывода в выделении внутренних буферов.

‘оставные сообщениЯ

„о сих пор мы рассматривали сообщениЯ как непрерывную последовательность байт. Ћднако сообщениЯ часто состоЯт из двух или более отдельных частей. Ќапример, сообщение может иметь заголовок фиксированной длины, за которым следуют данные переменной длины. „лЯ того чтобы избежать копированиЯ частей такого сообщениЯ во временные промежуточные буферы при передаче или приеме, может быть использовано составное сообщение, состоЯщее из двух или более отдельных буферов сообщений. €менно благодарЯ этой возможности менеджеры ввода/вывода QNX, такие как Dev и Fsys, достигают своей высокой производительности.

‘ледующие функции позволЯют обрабатывать составные сообщениЯ:

Creceivemx()
Readmsgmx();
Receivemx();
Replymx();
Sendmx();
Writemsgmx().

fig: i/multimsg.gif

‘оставные сообщениЯ могут быть описаны с помощьюqqqЏ0 специальной mx структуры. ЊикроЯдро объединЯет части такого сообщениЯ в единый непрерывный поток данных.

‡арезервированные коды сообщений

QNX начинает все сообщениЯ с 16-ти битного слова, называемого кодом сообщениЯ. ‡аметим, однако, что это не ЯвлЯетсЯ обЯзательным длЯ вас требованием при написании собственных программ. QNX использует коды сообщений в следующих диапазонах:

‡арезервированный диапазон: Ћписание:
0x0000 - 0x00FF ‘ообщениЯ Њенеджера процессов
0x0100 - 0x01FF ‘ообщениЯ ввода/вывода (общие длЯ всех серверов ввода/вывода)
0x0200 - 0x02FF ‘ообщениЯ Њенеджера файловой системы
0x0300 - 0x03FF ‘ообщениЯ Њенеджера устройств
0x0400 - 0x04FF ‘ообщениЯ Њенеджера сети
0x0500 - 0x0FFF ‡арезервированы длЯ будущих системных процессов QNX

‡арезервированный диапазон:	Ћписание:
`0x0000` - `0x00FF`	‘ообщениЯ Њенеджера процессов
`0x0100` - `0x01FF`	‘ообщениЯ ввода/вывода (общие длЯ всех серверов ввода/вывода)
`0x0200` - `0x02FF`	‘ообщениЯ Њенеджера файловой системы
`0x0300` - `0x03FF`	‘ообщениЯ Њенеджера устройств
`0x0400` - `0x04FF`	‘ообщениЯ Њенеджера сети
`0x0500` - `0x0FFF`	‡арезервированы длЯ будущих системных процессов QNX

IPC посредством прокси

Џрокси - это форма неблокирующего сообщениЯ, особенно подходЯщего длЯ извещениЯ о наступлении событиЯ, когда посылающий процесс не нуждаетсЯ в диалоге с получателем. …динственнаЯ функциЯ прокси состоит в посылке фиксированного сообщениЯ определенному процессу, который ЯвлЯетсЯ владельцем прокси. Џодобно сообщениЯм, прокси могут быть использованы в пределах всей сети.

€спользуЯ прокси, процесс или обработчик прерываниЯ может послать сообщение другому процессу, не блокируЯсь и не ожидаЯ ответа.

‚от некоторые примеры использованиЯ прокси:

процесс желает известить другой процесс о наступлении какого-либо событиЯ, но при этом не может позволить себе посылку сообщениЯ (в этом случае он оставалсЯ бы блокированным до тех пор, пока получатель не вызовет Receive() и Reply());
процесс хочет послать данные другому процессу, но при этом ему не требуетсЯ ни ответа, ни какого-либо другого подтверждениЯ того, что адресат (получатель) получил сообщение;
обработчик прерываниЯ хочет известить процесс о поступлении новых данных.

„лЯ созданиЯ прокси используетсЯ функциЯ Языка ‘и qnx_proxy_attach(). ‹юбой другой процесс или обработчик прерываниЯ, которому известен идентификатор прокси, может воспользоватьсЯ функцией Языка ‘и Trigger() длЯ того, чтобы заставить прокси передать заранее заданное сообщение. ‡апрос Trigger() обрабатываетсЯ ЊикроЯдром.

Џрокси может быть "запущено" неоднократно - каждый раз при этом оно посылает сообщение. Џрокси может накапливать очередь длиной до 65535 сообщений.

fig: i/prxytrig.gif

Џроцесс-клиент запускает прокси 3 раза, в результате чего сервер получает 3 "консервированных" сообщениЯ от прокси.

IPC посредством сигналов

‘игналы ЯвлЯютсЯ традиционным способом асинхронной свЯзи, котораЯ используетсЯ в течение многих лет в различных операционных системах.

QNX поддерживает большой набор сигналов, соответствующих стандарту POSIX, кроме того, сигналы, исторически присущие некоторым UNIX-системам, и рЯд сигналов, уникальных длЯ QNX.

Љак породить сигнал

‘читаетсЯ, что сигнал доставлен процессу тогда, когда выполнЯетсЯ определенное в процессе длЯ данного сигнала действие. Џроцесс может посылать сигнал самому себе.

…сли вы хотите: €спользуйте:
Џородить сигнал из командной строки “тилиты: kill и slay

Џородить сигнал внутри процесса ”ункции ‘и: kill() и raise()

…сли вы хотите:	€спользуйте:
Џородить сигнал из командной строки	“тилиты: `kill` и `slay`
Џородить сигнал внутри процесса	”ункции ‘и: kill() и raise()

Џолучение сигналов

Џроцесс может принЯть сигнал одним из трех способов, в зависимости от того, как в процессе определена обработка сигналов:

если процесс не определил никаких специальных мер по обработке сигнала, то выполнЯетсЯ предусмотренное длЯ сигнала действие по умолчанию - обычно таким действием по умолчанию ЯвлЯетсЯ завершение работы процесса;
процесс может игнорировать сигнал. …сли процесс игнорирует сигнал, то сигнал не оказывает на процесс никакого воздействиЯ (учтите, что SIGCONT, SIGSTOP и SIGKILL не могут быть игнорированы в обычных обстоЯтельствах);
процесс может предусмотреть обработчик сигнала - функцию, котораЯ будет вызыватьсЯ при приеме сигнала. …сли процесс содержит обработчик длЯ какого-либо сигнала, говорЯт, что процесс может "поймать" этот сигнал. ‹юбой процесс, который "ловит" сигнал, фактически получает особый вид программного прерываниЯ. Ќикакие данные с сигналом не передаютсЯ.

‚ промежутке времени между моментом, когда сигнал порожден, и моментом, когда он доставлен, сигнал называетсЯ ожидающим. „лЯ процесса ожидающими одновременно могут быть несколько различных сигналов. ‘игналы доставлЯютсЯ процессу, когда планировщик Ядра делает этот процесс готовым к выполнению. Џроцесс не должен строить никаких предположений относительно порЯдка, в котором будут доставлены ожидающие сигналы.

Џеречень сигналов

‘игнал: Ћписание:
SIGABRT ‘игнал ненормального завершениЯ, порождаетсЯ функцией abort().
SIGALRM ‘игнал тайм-аута, порождаетсЯ функцией alarm().
SIGBUS “казывает на ошибку контролЯ четности оперативной памЯти (особаЯ длЯ QNX интерпретациЯ). …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGCHLD ‡авершение порожденного процесса. „ействие по умолчанию - игнорировать сигнал.
SIGCONT …сли процесс в состоЯнии HELD, то продолжить выполнение. „ействие по умолчанию - игнорировать сигнал, если процесс не в состоЯнии HELD.
SIGDEV ѓенерируетсЯ, когда в Њенеджере устройств происходит важное и запрошенное событие.
SIGFPE ЋшибочнаЯ арифметическаЯ операциЯ (целочисленнаЯ или с плавающей запЯтой), например, деление на ноль или операциЯ, вызвавшаЯ переполнение. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGHUP ѓибель процесса, который был ведущим сеанса, или зависание управлЯющего терминала.
SIGILL Ћбнаружение недопустимой аппаратной команды. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGINT €нтерактивный сигнал "внимание" (Break)
SIGKILL ‘игнал завершениЯ - должен быть использован только в экстренных ситуациЯх. ќтот сигнал не может быть "пойман" или игнорирован. ‘ервер может защитить себЯ от этого сигнала посредством функции Языка ‘и qnx_pflags(). „лЯ этого сервер должен иметь статус привилегированного пользователЯ.
SIGPIPE Џопытка записи в программный канал, который не открыт длЯ чтениЯ.
SIGPWR Џерезапуск компьютера в результате нажатиЯ Ctrl-Alt-Shift-Del или вызова утилиты shutdown.
SIGQUIT €нтерактивный сигнал завершениЯ.
SIGSEGV Ћбнаружение недопустимой ссылки на оперативную памЯть. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGSTOP ‘игнал приостановки выполнениЯ (HOLD) процесса. „ействие по умолчанию - приостановить процесс. ‘ервер может защитить себЯ от этого сигнала посредством функции Языка ‘и qnx_pflags(). „лЯ этого сервер должен иметь статус привилегированного пользователЯ.
SIGTERM ‘игнал завершениЯ.
SIGTSTP Ќе поддерживаетсЯ QNX.
SIGTTIN Ќе поддерживаетсЯ QNX.
SIGTTOU Ќе поддерживаетсЯ QNX.
SIGUSR1 ‡арезервирован как определЯемый приложением сигнал 1.
SIGUSR2 ‡арезервирован как определЯемый приложением сигнал 2.
SIGWINCH €зменилсЯ размер окна.

‘игнал:	Ћписание:
SIGABRT	‘игнал ненормального завершениЯ, порождаетсЯ функцией abort().
SIGALRM	‘игнал тайм-аута, порождаетсЯ функцией alarm().
SIGBUS	“казывает на ошибку контролЯ четности оперативной памЯти (особаЯ длЯ QNX интерпретациЯ). …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGCHLD	‡авершение порожденного процесса. „ействие по умолчанию - игнорировать сигнал.
SIGCONT	…сли процесс в состоЯнии HELD, то продолжить выполнение. „ействие по умолчанию - игнорировать сигнал, если процесс не в состоЯнии HELD.
SIGDEV	ѓенерируетсЯ, когда в Њенеджере устройств происходит важное и запрошенное событие.
SIGFPE	ЋшибочнаЯ арифметическаЯ операциЯ (целочисленнаЯ или с плавающей запЯтой), например, деление на ноль или операциЯ, вызвавшаЯ переполнение. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGHUP	ѓибель процесса, который был ведущим сеанса, или зависание управлЯющего терминала.
SIGILL	Ћбнаружение недопустимой аппаратной команды. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGINT	€нтерактивный сигнал "внимание" (Break)
SIGKILL	‘игнал завершениЯ - должен быть использован только в экстренных ситуациЯх. ќтот сигнал не может быть "пойман" или игнорирован. ‘ервер может защитить себЯ от этого сигнала посредством функции Языка ‘и qnx_pflags(). „лЯ этого сервер должен иметь статус привилегированного пользователЯ.
SIGPIPE	Џопытка записи в программный канал, который не открыт длЯ чтениЯ.
SIGPWR	Џерезапуск компьютера в результате нажатиЯ Ctrl-Alt-Shift-Del или вызова утилиты `shutdown`.
SIGQUIT	€нтерактивный сигнал завершениЯ.
SIGSEGV	Ћбнаружение недопустимой ссылки на оперативную памЯть. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGSTOP	‘игнал приостановки выполнениЯ (HOLD) процесса. „ействие по умолчанию - приостановить процесс. ‘ервер может защитить себЯ от этого сигнала посредством функции Языка ‘и qnx_pflags(). „лЯ этого сервер должен иметь статус привилегированного пользователЯ.
SIGTERM	‘игнал завершениЯ.
SIGTSTP	Ќе поддерживаетсЯ QNX.
SIGTTIN	Ќе поддерживаетсЯ QNX.
SIGTTOU	Ќе поддерживаетсЯ QNX.
SIGUSR1	‡арезервирован как определЯемый приложением сигнал 1.
SIGUSR2	‡арезервирован как определЯемый приложением сигнал 2.
SIGWINCH	€зменилсЯ размер окна.

“правление обработкой сигналов

—тобы задать желаемый способ обработки длЯ каждого из сигналов, вы можете использовать функции Языка ‘и signal() стандарта ANSI или sigaction() стандарта POSIX.

”ункциЯ sigaction() предоставлЯет большие возможности по управлению обработкой сигналов.

‚ы можете изменить способ обработки сигнала в любой момент времени. …сли вы укажете, что сигнал данного типа должен игнорироватьсЯ, то все ждущие сигналы такого типа будут немедленно отброшены.

Ћбработчики сигналов

Ќекоторые специальные замечаниЯ касаютсЯ процессов, которые ловЯт сигналы посредством обработчиков сигналов.

‚ызов обработчика сигнала аналогичен программному прерыванию. Ћн выполнЯетсЯ асинхронно по отношению к остальной части процесса. ’аким образом, существует вероЯтность того, что обработчик сигнала будет вызван во времЯ выполнениЯ любой из имеющихсЯ в программе функций (включаЯ библиотечные функции).

…сли в вашей программе не предусмотрен возврат из обработчика сигнала, то могут быть использованы функции siglongjmp() либо longjmp() Языка ‘и, однако, функциЯ siglongjmp() предпочтительнее. Џри использовании функции longjmp() сигнал остаетсЯ блокированным.

Ѓлокирование сигналов

€ногда может возникнуть необходимость временно запретить получение сигнала, не изменЯЯ метод его обработки. QNX предоставлЯет набор функций, которые позволЯют блокировать получение сигналов. Ѓлокированный сигнал остаетсЯ ожидающим; после разблокированиЯ он будет доставлен вашей программе.

Џока ваша программа выполнЯет обработчик сигнала длЯ определенного типа сигнала, QNX автоматически блокирует этот сигнал. ќто означает, что нет необходимости заботитьсЯ о вложенных вызовах обработчика сигнала. Љаждый вызов обработчика сигнала - это неделимаЯ операциЯ по отношению к доставке следующих сигналов этого типа. …сли ваш процесс выполнЯет нормальный возврат из обработчика, сигнал автоматически разблокируетсЯ.

ђеализациЯ обработчиков сигналов в некоторых UNIX системах отличаетсЯ тем, что при получении сигналов они не блокируют его, а устанавливают действие по умолчанию. ‚ результате некоторые UNIX приложениЯ вызывают функцию signal() изнутри обработчика сигналов, чтобы подготовить обработчик к следующему вызову. ’акой способ имеет два недостатка. ‚о-первых, если следующий сигнал поступает, когда ваша программа уже выполнЯет обработчик сигнала, но еще не вызвала функцию signal(), то программа может быть завершена. ‚о-вторых, если сигнал поступает сразу после вызова функции signal() в обработчике, то возможен рекурсивный вход в обработчик сигнала. QNX поддерживает блокирование сигналов и, таким образом, не страдает ни от одного из этих недостатков. ‚ам не нужно вызывать функцию signal() изнутри обработчика сигналов. …сли вы покидаете обработчик через дальний переход (long jump), вам следует использовать функцию siglongjmp().

‘игналы и сообщениЯ

‘уществует важное взаимодействие между сигналами и сообщениЯми. …сли ваш процесс SEND-блокирован или RECEIVE-блокирован в момент получениЯ сигнала, и вы предусмотрели обработчик сигнала, происходЯт следующие действиЯ:

Џроцесс разблокируетсЯ;
‚ыполнЯетсЯ обработка сигнала;
”ункциЯ Send() или Receive() возвратит код ошибки.

…сли процесс был SEND-блокирован в момент получениЯ сигнала, то проблемы не возникает, потому что получатель еще не получил сообщение. Ќо если процесс был RECEIVE-блокирован, то вы не узнаете, было ли обработано посланное им сообщение и, следовательно, не будете знать, следует ли повторЯть Send().

Џроцесс, играющий роль сервера (т.е. получающий сообщениЯ), может запросить, чтобы он получал извещение всЯкий раз, когда его процесс-клиент получает сигнал, находЯсь в состоЯнии REPLY-блокирован. ‚ этом случае клиент становитсЯ SIGNAL-блокированным с ожидающим сигналом. ‘ервер получает специальные сообщениЯ, описывающие тип сигнала. ‘ервер может затем выбрать один из следующих вариантов:

закончить выполнение запроса от клиента нормальным образом: клиент (процесс-отправитель) будет уведомлен, что его сообщение было обработано должным образом
€‹€
освободить используемые ресурсы и возвратить код ошибки, указывающий, что процесс был разблокирован сигналом: клиент получит четкий признак ошибки.

Љогда сервер отвечает процессу, который был SIGNAL-блокирован, то сигнал выдаетсЯ непосредственно после возврата из функции Send(), вызванной клиентом (процессом-отправителем).

IPC в сети

‚иртуальные каналы

Џриложение в QNX может общатьсЯ с процессом на другом компьютере сети точно так же, как если бы оно общалось с другим процессом на том же самом компьютере. Љстати говорЯ, с точки зрениЯ приложениЯ нет различиЯ между локальным и удаленным ресурсом.

’акаЯ замечательнаЯ степень прозрачности становитсЯ возможна благодарЯ виртуальным каналам (от английского virtual circuit, сокращенно VC). VC - это пути, которые Њенеджер сети предоставлЯет длЯ передачи сообщений, прокси и сигналов по сети. VC способствуют эффективному использованию QNX-сети в целом по нескольким причинам:

Љогда создаетсЯ VC, он получает возможность обрабатывать сообщениЯ вплоть до определенного размера; это означает, что вы можете предварительно выделить ресурс длЯ обработки сообщениЯ. ’ем не менее, если вам необходимо послать сообщение, превышающее заданный максимальный размер, VC автоматически увеличивает размер буфера.
…сли два процесса, располагающиесЯ на различных узлах сети, используют длЯ свЯзи друг с другом более чем один VC, то такие VC будут разделЯемыми, так как между процессами будет реально существовать только один виртуальный канал. ’акаЯ ситуациЯ обычно имеет место, когда процесс использует несколько файлов на удаленной файловой системе.
…сли процесс присоединЯетсЯ к существующему разделЯемому VC и запрашивает буфер большего размера, чем тот, который используетсЯ, то размер буфера автоматически увеличиваетсЯ.
Љогда процесс завершает выполнение, все свЯзанные с ним VC автоматически освобождаютсЯ.

‚иртуальные процессы

Џроцесс-отправитель отвечает за подготовку VC между собой и тем процессом, с которым он хочет установить свЯзь. ‘ этой целью процесс-отправитель обычно вызывает функцию qnx_vc_attach(). Љроме созданиЯ VC, эта функциЯ также создает на каждом конце канала виртуальный идентификатор процесса, сокращенно VID. „лЯ каждого из процессов, VID на противоположном конце виртуального канала ЯвлЯетсЯ идентификатором удаленного процесса, с которым он устанавливает свЯзь. Џроцессы поддерживают свЯзь друг с другом посредством этих VID.

Ќапример, на следующем рисунке виртуальный канал соединЯет PID 1 и PID 2. Ќа узле 20 - где находитсЯ PID 1 - VID представлЯет PID 2. Ќа узле 40 - где находитсЯ PID 2 - VID представлЯет PID 1. € PID 1 и PID 2 могут обращатьсЯ к VID на своем узле так же, как к любому другому локальному процессу, посылаЯ сообщениЯ, принимаЯ сообщениЯ, поставлЯЯ сигналы, ожидаЯ и т.д. ’ак, например, PID 1 может послать сообщение VID на своем конце, и этот VID передаст сообщение по сети к VID, представлЯющему PID 1 на другом конце. ќтот VID затем отправит сообщение к PID 2.

fig: i/vcircuit.gif

‘вЯзь по сети реализуетсЯ посредством виртуальных каналов. Љогда PID 1 посылает данные VID 2, посланный запрос передаетсЯ по виртуальному каналу, в результате VID 1 направлЯет данные PID 2.

Љаждый VID поддерживает соединение, которое имеет следующие атрибуты:

локальный pid;
удаленный pid;
удаленный nid (ID узла);
удаленный vid.

‚озможно, вам не придетсЯ часто иметь дело непосредственно с VC. ’ак, например, когда приложение хочет получить доступ к ресурсу ввода/вывода на другом узле сети, то VC создаетсЯ библиотечной функцией open() от имени приложениЯ. Џриложение не принимает непосредственного участиЯ в создании или использовании VC. Ђналогичным образом, когда приложение определЯет местонахождение сервера с помощью функции qnx_name_locate(), то VC автоматически создаетсЯ от имени приложениЯ. „лЯ приложениЯ VC просто ЯвлЯетсЯ PID сервера.

„лЯ более подробной информации о функции qnx_name_locate() смотрите описание "‘имволические имена процессов в главе "Њенеджер процессов".

‚иртуальные прокси

‚иртуальное прокси позволЯет посылать прокси с удаленного узла, подобно тому, как виртуальный канал позволЯет процессу обмениватьсЯ сообщениЯми с удаленным узлом.

‚ отличие от виртуального канала, который свЯзывает вместе два процесса, виртуальный прокси может быть послан любым процессом на удаленном узле.

‚иртуальные прокси создаютсЯ функцией qnx_proxy_rem_attach(), которой в качестве аргументов передаютсЯ узел (nid_t) и прокси (pid_t).

fig: i/vproxies.gif

Ќа удаленном узле создаетсЯ виртуальный прокси, который ссылаетсЯ на локальный прокси.

€мейте в виду, что на вызывающем узле виртуальный канал создаетсЯ автоматически посредством функции qnx_proxy_rem_attach().

Ћтключение виртуальных каналов

Џроцесс может утратить возможность свЯзи по установленному VC в результате различных причин:

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

‹юбаЯ из этих причин может помешать передаче сообщений по VC. Ќеобходимо выЯвлЯть такие ситуации с тем, чтобы приложениЯ могли предпринЯть корректирующие действиЯ, либо корректно завершить свое выполнение. …сли это не будет сделано, то ценные ресурсы могут оставатьсЯ без необходимости постоЯнно занЯтыми.

Њенеджер процессов на каждом узле проверЯет целостность VC на своем узле. Ћн делает это следующим образом:

Љаждый раз, когда происходит успешнаЯ передача по VC, обновлЯетсЯ временнаЯ метка, свЯзаннаЯ с данным VC, в соответствии со временем последней операции.
—ерез определенные промежутки времени Њенеджер процессов проверЯет каждый VC. …сли не было зафиксировано никаких операций, то Њенеджер процессов посылает проверочный пакет Њенеджеру процессов на другом конце VC.
…сли ответ не получен или выЯвлен сбой, то VC помечаетсЯ как неисправный. ‡атем делаетсЯ определенное количество попыток восстановить соединение.
…сли эти попытки не дают результата, то VC демонтируетсЯ; все процессы, блокированные VC, переходЯт в состоЯние READY (готов). Џроцесс получает код ошибки, возвращаемой ранее вызванной функцией свЯзи.

„лЯ установки параметров, свЯзанных с данной проверкой целостности VC, используйте утилиту netpoll.

IPC посредством семафоров

„ругой распространенной формой синхронизации процессов ЯвлЯютсЯ семафоры. Ћперации "сигнализации" (sem_post()) и "ожиданиЯ" (sem_wait()) позволЯют управлЯть выполнением процессов, переводЯ их в состоЯние ожиданиЯ либо выводЯ из него. ЋперациЯ сигнализации увеличивает значение семафора на единицу, а операциЯ ожиданиЯ уменьшает его на единицу.

Џри положительном значении семафора, при выполнении операции ожиданиЯ, процесс не блокируетсЯ. ‚ противном случае операциЯ ожиданиЯ блокирует процесс до тех пор, пока какой-либо другой процесс не выполнит операцию сигнализации. „опускаетсЯ выполнение операции сигнализации один или более раз перед выполнением операции ожиданиЯ - это позволит одному или нескольким процессам выполнить операцию ожиданиЯ, не блокируЯсь.

‚ажное отличие между семафорами и другими примитивами синхронизации заключаетсЯ в том, что семафоры "асинхронно безопасны" и могут использоватьсЯ обработчиками сигналов. …сли требуетсЯ, чтобы обработчик сигнала выводил процесс из состоЯниЯ ожиданиЯ, то семафоры ЯвлЯютсЯ правильным выбором.

„испетчеризациЯ процессов

Љогда принимаютсЯ решениЯ по диспетчеризации

Џланировщик ЊикроЯдра принимает решение по диспетчеризации:

после разблокировки процесса;
по истечении временного интервала (кванта) длЯ выполнЯющегосЯ процесса;
когда прерываетсЯ текущий процесс.

Џриоритеты процессов

‚ QNX каждому из процессов присваиваетсЯ приоритет. Џланировщик выбирает длЯ выполнениЯ следующий процесс, находЯщийсЯ в состоЯнии READY, в соответствии с его приоритетом. (Џрограмма в состоЯнии READY - это программа, котораЯ способна использовать –Џ). „лЯ выполнениЯ выбираетсЯ процесс с наивысшим приоритетом.

fig: i/readyq.gif

‚ очереди шесть процессов (A-F), готовых к выполнению и находЯщихсЯ в состоЯнии READY. Ћстальные процессы (G-Z) блокированы. ‚ данный момент выполнЯетсЯ процесс A. Џроцессы A, B и C имеют наивысший приоритет, поэтому будут разделЯть центральный процессор в соответствии с алгоритмом диспетчеризации длЯ выполнЯемого процесса.

Џриоритеты, присваиваемые процессам, находЯтсЯ в диапазоне от 0 (наименьший) до 31 (наивысший). “ровень приоритета по умолчанию длЯ создаваемого процесса наследуетсЯ от его родителЯ; длЯ приложений, запускаемых командным процессором, приоритет обычно равен 10.

…сли вы хотите: €спользуйте функцию Языка ‘€:
Ћпределить приоритет процесса getprio()

“становить приоритет длЯ процесса setprio()

…сли вы хотите:	€спользуйте функцию Языка ‘€:
Ћпределить приоритет процесса	getprio()
“становить приоритет длЯ процесса	setprio()

Њетоды диспетчеризации

—тобы удовлетворить потребность различных приложений, QNX предлагает три метода диспетчеризации:

FIFO;
карусель;
адаптивный.

Љаждый процесс в системе может выполнЯтьсЯ, используЯ любой из этих методов. Ћни действуют применительно к каждому отдельному процессу, а не применительно ко всем процессам на узле.

Џомните, что эти методы диспетчеризации применимы, только когда два или более процесса с одинаковым приоритетом находЯтсЯ в состоЯнии READY (т.е. эти процессы непосредственно конкурируют друг с другом). …сли процесс с более высоким приоритетом переходит в состоЯние READY, то он немедленно вытеснЯет все процессы с более низким приоритетом.

Ќа следующей диаграмме три процесса с одинаковым приоритетом находЯтсЯ в состоЯнии READY. …сли процесс Ђ блокируетсЯ, то выполнЯетсЯ процесс B.

fig: i/ablocks.gif

Џроцесс A блокируетсЯ, процесс B выполнЯетсЯ.

Њетод диспетчеризации процесса наследуетсЯ от его родительского процесса, однако, затем этот метод может быть изменен.

…сли вы хотите: €спользуйте функцию Языка ‘и:

Ћпределить метод диспетчеризации длЯ процесса getscheduler()

“становить метод диспетчеризации длЯ процесса setscheduler()

…сли вы хотите:	€спользуйте функцию Языка ‘и:
Ћпределить метод диспетчеризации длЯ процесса	getscheduler()
“становить метод диспетчеризации длЯ процесса	setscheduler()

FIFO диспетчеризациЯ

Џри FIFO диспетчеризации процесс продолжает выполнение пока не наступит момент, когда он:

добровольно уступает управление (т.е. выполнЯет любой вызов Ядра);
вытеснЯетсЯ процессом с более высоким приоритетом.

fig: i/method1.gif

FIFO диспетчеризациЯ. Џроцесс Ђ выполнЯетсЯ до тех пор, пока не блокируетсЯ.

„ва процесса, которые выполнЯютсЯ с одним и тем же приоритетом, могут использовать метод FIFO длЯ организации взаимоисключающего доступа к разделЯемому (т.е. совместно используемому) ресурсу. Ќи один из них не будет вытеснен другим во времЯ своего выполнениЯ. ’ак, например, если они совместно используют сегмент памЯти, то каждый из этих двух процессов может обновлЯть данные в этом сегменте, не прибегаЯ к использованию какого-либо способа синхронизации (например, семафора).

ЉарусельнаЯ диспетчеризациЯ

Џри карусельной диспетчеризации процесс продолжает выполнение, пока не наступит момент, когда он:

добровольно уступает управление (т.е. блокируетсЯ);
вытеснЯетсЯ процессом с более высоким приоритетом;
использовал свой квант времени (timeslice).

fig: i/method2.gif

ЉарусельнаЯ диспетчеризациЯ. Џроцесс Ђ выполнЯетсЯ до тех пор, пока он не использовал свой квант времени; затем выполнЯетсЯ следующий процесс, находЯщийсЯ в состоЯнии READY (процесс B).

Љвант времени - это интервал времени, выделЯемый каждому процессу. Џосле того, как процесс использовал свой квант времени, управление передаетсЯ следующему процессу, который находитсЯ в состоЯнии READY и имеет такой же уровень приоритета. Љвант времени равен 50 миллисекундам.

‡а исключением квантованиЯ времени, карусельнаЯ диспетчеризациЯ идентична FIFO-диспетчеризации.

ЂдаптивнаЯ диспетчеризациЯ

Џри адаптивной диспетчеризации процесс ведет себЯ следующим образом:

…сли процесс использовал свой квант времени (т.е. он не блокировалсЯ), то его приоритет уменьшаетсЯ на 1. ќто получило название снижение приоритета (priority decay). “чтите, что "пониженный" процесс не будет продолжать "снижатьсЯ", даже если он использовал еще один квант времени и не блокировалсЯ - он снизитсЯ только на один уровень ниже своего исходного приоритета.
…сли процесс блокируетсЯ, то ему возвращаетсЯ первоначальное значение приоритета.

fig: i/method3.gif

ЂдаптивнаЯ диспетчеризациЯ. Џроцесс Ђ использовал свой квант времени; его приоритет снизилсЯ на 1. ‚ыполнЯетсЯ следующий процесс в состоЯнии READY (процесс B).

‚ы можете использовать адаптивную диспетчеризацию в тех случаЯх, когда процессы, производЯщие интенсивные вычислениЯ, выполнЯютсЯ в фоновом режиме одновременно с интерактивной работой пользователей. ‚ы обнаружите, что адаптивнаЯ диспетчеризациЯ дает производЯщим интенсивные вычислениЯ процессам достаточный доступ к –Џ и в то же времЯ сохранЯет быстрый интерактивный отклик длЯ других процессов.

ЂдаптивнаЯ диспетчеризациЯ ЯвлЯетсЯ методом диспетчеризации, использующимсЯ по умолчанию длЯ программ, запускаемых командным интерпретатором.

Љлиент-управлЯемый приоритет

‚ QNX обмен данными между процессами в большинстве случаев организован с использованием модели клиент/сервер. ‘ерверы выполнЯют некоторые сервисные функции, а клиенты, посылаЯ сообщение серверу, запрашивают эти услуги. Љак правило, серверы более надежны и жизнеспособны, чем клиенты.

Љоличество клиентов обычно больше, чем серверов. Љак следствие этого, принЯто запускать сервер с приоритетом более высоким, чем у любого из его клиентов. Њожет использоватьсЯ любой из трех рассмотренных выше методов диспетчеризации, но, наверное, самым распространенным ЯвлЯетсЯ карусельный.

…сли клиент с низким уровнем приоритета посылает сообщение серверу, то его запрос выполнЯетсЯ под более высоким уровнем приоритета, тем, который имеетсЯ у сервера. ќто косвенным образом повышает приоритет клиента, т.к. именно его запрос заставил сервер выполнЯтьсЯ.

Џока длЯ выполнениЯ запроса серверу достаточно короткого промежутка времени, проблем обычно не возникает. …сли же выполнение запроса занимает у сервера более продолжительное времЯ, то клиент с низким приоритетом может неблагоприЯтно повлиЯть на выполнение других процессов, приоритеты которых выше, чем у клиента, но ниже, чем у сервера.

—тобы решить эту дилемму, сервер может поставить свой приоритет в зависимость от приоритета того клиента, чей запрос он выполнЯет. Љогда сервер получает сообщение, приоритет будет установлен таким же, как у клиента. Ћбратите внимание, что изменилсЯ только приоритет сервера - его алгоритм диспетчеризации остаетсЯ неизменным. …сли во времЯ выполнениЯ запроса сервер получает другое сообщение, и приоритет нового клиента выше, чем у сервера, то приоритет сервера повышаетсЯ. ”актически, новый клиент "зарЯжает" сервер до своего уровнЯ приоритета, позволЯЯ ему закончить выполнение текущего запроса и приступить к обработке запроса нового клиента. …сли этого не делать, то фактически приоритет нового клиента понизитсЯ, пока он блокирован на сервере с низким приоритетом.

…сли вы выбрали клиент-управлЯемый приоритет длЯ своего сервера, вам следует также запросить доставку сообщений в порЯдке убываниЯ приоритетов (в противоположность хронологическому).

—тобы установить клиент-управлЯемый приоритет, используйте функцию ‘и qnx_pflags() следующим образом:

qnx_pflags(~0, _PPF_PRIORITY_FLOAT
            | _PPF_PRIORITY_REC, 0, 0);

Ќесколько слов о реальном времени

Љак бы мы этого не хотели, компьютеры не ЯвлЯютсЯ бесконечно быстрыми. „лЯ системы реального времени жизненно важно, чтобы такты работы –Џ не расходовались зрЯ. ’акже очень важно свести к минимуму времЯ, которое проходит с момента наступлениЯ внешнего событиЯ до начала выполнениЯ кода программы, ответственной за обработку данного событиЯ. ќто времЯ называетсЯ задержкой.

‚ QNX системе встречаетсЯ несколько видов задержек.

‡адержка прерываниЯ

‡адержка прерываниЯ - это интервал времени между аппаратным прерыванием и выполнением первой команды программного обработчика прерываниЯ. QNX практически все времЯ оставлЯет прерываниЯ полностью разрешенными, поэтому задержка прерываниЯ, как правило, не существенна. Ћднако некоторые критические фрагменты кода требуют, чтобы прерываниЯ были временно запрещены. ЊаксимальнаЯ продолжительность такого запрета обычно определЯет худший случай задержки прерываниЯ - в QNX это очень небольшаЯ величина.

‘ледующаЯ диаграмма иллюстрирует случай, когда аппаратное прерывание обрабатываетсЯ в установленном обработчиком прерывании. Ћбработчик прерываниЯ либо просто выполнит команду возврата, либо при возврате запустит прокси.

fig: i/intlat.gif

Ћбработчик прерываниЯ просто завершаетсЯ.

‡адержка прерываниЯ (Til) на приведенной выше диаграмме отражает минимальную задержку - случай, когда прерываниЯ были полностью разрешены в момент, когда произошло прерывание. ‚ худшем случае задержка прерываниЯ составит это времЯ плюс наибольшее времЯ, в течение которого QNX или выполнЯющийсЯ процесс запрещает прерываниЯ –Џ.

Til длЯ различных процессоров

‘ледующаЯ таблица содержит типичные значениЯ задержки прерываниЯ (TqqqЏ1ilqqqЏ0) длЯ разных процессоров:

‡адержка прерываниЯ (Til): Џроцессор:

3.3 микросекунды 166 Њѓц Pentium

4.4 микросекунды 100 Њѓц Pentium

5.6 микросекунды 100 Њѓц 486DX4

22.5 микросекунды 33 Њѓц 386EX

‡адержка прерываниЯ (Til):	Џроцессор:
3.3 микросекунды	166 Њѓц Pentium
4.4 микросекунды	100 Њѓц Pentium
5.6 микросекунды	100 Њѓц 486DX4
22.5 микросекунды	33 Њѓц 386EX

‡адержка диспетчеризации

‚ некоторых случаЯх обработчик аппаратного прерываниЯ низкого уровнЯ должен передать управление процессу более высокого уровнЯ. ‚ этом случае обработчик прерываниЯ перед выполнением команды "возврат" запускает прокси. ‡десь имеет место второй вид задержки - задержка диспетчеризации, - с которой также надо считатьсЯ.

‡адержка диспетчеризации - это времЯ между завершением работы обработчика прерываниЯ и выполнением первой команды процесса-драйвера. ќто времЯ, необходимое длЯ сохранениЯ контекста, выполнЯющегосЯ в данный момент времени процесса, и восстановлениЯ контекста требуемого драйвера. ‚ QNX это времЯ также невелико, хотЯ и больше задержки прерываниЯ.

fig: i/schedlat.gif

Ћбработчик прерываниЯ завершает работу и запускает прокси.

‚ажно отметить, что обработка большинства прерываний завершаетсЯ без запуска прокси. ‚ большинстве случаев обработчик прерываниЯ сам может выполнить все необходимые действиЯ. ‡апуск прокси, чтобы "разбудить" драйвер, процесс более высокого уровнЯ, происходит только при наступлении важного событиЯ. Ќапример, обработчик прерываниЯ длЯ драйвера последовательного порта при каждом прерывании "регистр передачи свободен" будет передавать один байт данных и запустит процесс более высокого уровнЯ (Dev) только тогда, когда выходной буфер, наконец, опустеет.

Tsl длЯ различных процессоров

‘ледующаЯ таблица содержит типичные значениЯ задержки диспетчеризации (Tsl) длЯ разных процессоров:

‡адержка диспетчеризации (Tsl): Џроцессор:

4.7 микросекунды 166 Њѓц Pentium
6.7 микросекунды 100 Њѓц Pentium

11.1 микросекунды 100 Њѓц 486DX4

74.2 микросекунды 33 Њѓц 386EX

‡адержка диспетчеризации (Tsl):	Џроцессор:
4.7 микросекунды	166 Њѓц Pentium
6.7 микросекунды	100 Њѓц Pentium
11.1 микросекунды	100 Њѓц 486DX4
74.2 микросекунды	33 Њѓц 386EX

‘тек прерываний

’ак как архитектура микрокомпьютеров позволЯет назначать приоритеты аппаратным прерываниЯм, то прерываниЯ с более высоким приоритетом могут вытеснЯть прерываниЯ с меньшим приоритетом.

ќтот механизм полностью поддерживаетсЯ в QNX. ‚ыше были рассмотрены простейшие - и наиболее типичные - ситуации, когда происходит только одно прерывание. Џрактически такой же расчет времени справедлив длЯ прерываниЯ с наивысшим приоритетом. Џри рассмотрении наихудшего случаЯ длЯ прерываниЯ с низким приоритетом необходимо учитывать времЯ обработки всех прерываний более высокого уровнЯ, т.к. в QNX прерывание с более высоким приоритетом вытеснит прерывание с меньшим приоритетом.

fig: i/stackint.gif

‚ыполнЯетсЯ процесс A. Џрерывание IRQx вызывает выполнение обработчика прерываниЯ Intx, который вытеснЯетсЯ IRQy и его обработчиком Inty. Inty запускает прокси, вызывающее выполнение процесса B, а Intx запускает прокси, вызывающее выполнение процесса C.

Њенеджер процессов

ќта глава охватывает следующие темы:

введение;
жизненный цикл процесса;
состоЯниЯ процесса;
символьные имена процессов;
таймеры;
обработчики прерываний.

‚ведение

ЋбЯзанности Њенеджера процессов

Њенеджер процессов тесно взаимодействует с ЊикроЯдром, чтобы обеспечить услуги, составлЯющие сущность операционной системы. •отЯ он и ЯвлЯетсЯ единственным процессом, который использует то же адресное пространство, что и ЊикроЯдро, Њенеджер процессов выполнЯетсЯ как истинный процесс. € он, как и все остальные процессы, подвергаетсЯ диспетчеризации со стороны џдра и использует предоставлЯемые ЊикроЯдром примитивы передачи сообщений длЯ свЯзи с другими процессами в системе.

Њенеджер процессов отвечает за создание новых процессов в системе и за управление основными ресурсами, свЯзанными с процессом. ‚се эти услуги предоставлЯютсЯ посредством сообщений. ’ак, например, если процесс хочет породить новый процесс, он делает это, посылаЯ сообщение с указанием атрибутов создаваемого процесса. Ћбратите внимание, что т.к. сообщениЯ передаютсЯ по сети, вы можете легко создать процесс на другом узле сети, послав сообщение Њенеджеру процессов на этом узле.

Џримитивы созданиЯ процессов

QNX поддерживают три примитива созданиЯ процесса:

fork();
exec();
spawn().

Џримитивы fork() и exec() определены стандартом POSIX, а примитив spawn() реализован только в QNX.

Џримитив fork()

Џримитив fork() создает новый процесс, который ЯвлЯетсЯ точной копией вызвавшего его процесса. Ќовый процесс использует тот же самый код, что и породивший его процесс, и наследует копию всех данных родительского процесса.

Џримитив exec()

Џримитив exec() заменЯет вызвавший процесс новым. Џосле успешного вызова exec() возврата не происходит, т.к. образ вызывающего процесса заменЯетсЯ образом нового процесса. Ћбычной практикой в POSIX-системах длЯ созданиЯ нового процесса - без удалениЯ вызывающего процесса - ЯвлЯетсЯ сначала вызов fork(), а затем вызов exec() из порожденного процесса.

Џримитив spawn()

Џримитив spawn() создает новый процесс как потомок вызывающего процесса. ‘ его помощью можно избежать вызовов fork() и exec(), используЯ более быстрый и эффективный способ созданиЯ новых процессов. ‚ отличие от fork() и exec(), которые по своей природе выполнЯютсЯ на том же самом узле, что и вызывающий процесс, примитив spawn() может создавать процессы на любом узле сети.

Ќаследование

Љогда с помощью одного из трех рассмотренных выше примитивов задаетсЯ новый процесс, он наследует многое из своего окружениЯ от родителЯ. ќто сведено в следующую таблицу:

Ќаследуемый параметр fork() exec() spawn()

€дентификатор процесса нет да нет

Ћткрытые файлы да по выбору* по выбору

Ѓлокировка файлов нет да нет

Ћжидающие сигналы нет да нет

Њаска сигналов да по выбору по выбору

€гнорируемые сигналы да по выбору по выбору

Ћбработчики сигналов да нет нет

Џеременные окружениЯ да по выбору по выбору

€дентификатор сеанса да да по выбору

ѓруппа процесса да да по выбору

ђеальные UID, GID да да да

ќффективные UID, GID да по выбору по выбору

’екущий рабочий каталог да по выбору по выбору

Њаска созданиЯ файлов да да да

Џриоритет да по выбору по выбору

Ђлгоритм диспетчеризации да по выбору по выбору

‚иртуальные каналы нет нет нет

‘имвольные имена нет нет нет

таймеры реального времени нет нет нет

Ќаследуемый параметр	fork()	exec()	spawn()
€дентификатор процесса	нет	да	нет
Ћткрытые файлы	да	по выбору*	по выбору
Ѓлокировка файлов	нет	да	нет
Ћжидающие сигналы	нет	да	нет
Њаска сигналов	да	по выбору	по выбору
€гнорируемые сигналы	да	по выбору	по выбору
Ћбработчики сигналов	да	нет	нет
Џеременные окружениЯ	да	по выбору	по выбору
€дентификатор сеанса	да	да	по выбору
ѓруппа процесса	да	да	по выбору
ђеальные UID, GID	да	да	да
ќффективные UID, GID	да	по выбору	по выбору
’екущий рабочий каталог	да	по выбору	по выбору
Њаска созданиЯ файлов	да	да	да
Џриоритет	да	по выбору	по выбору
Ђлгоритм диспетчеризации	да	по выбору	по выбору
‚иртуальные каналы	нет	нет	нет
‘имвольные имена	нет	нет	нет
таймеры реального времени	нет	нет	нет

*по выбору: вызывающий процесс может по необходимости выбрать - да или нет.

†изненный цикл процесса

Џроцесс проходит через четыре стадии:

‘оздание.
‡агрузка.
‚ыполнение.
‡авершение.

‘оздание

‘оздание нового процесса состоит из присвоениЯ новому процессу идентификатора (ID) процесса и подготовки информации, котораЯ определЯет окружение нового процесса. ЃольшаЯ часть этой информации наследуетсЯ от родительского процесса (смотри раздел "Ќаследование").

‡агрузка

‡агрузка образа процесса производитсЯ нитью загрузчика. Љод загрузчика находитсЯ в Њенеджере процессов, но нить выполнЯетсЯ под ID нового процесса. ќто позволЯет Њенеджеру процессов обрабатывать и другие запросы во времЯ загрузки программы.

‚ыполнение

Џосле того, как код программы загружен, процесс готов к выполнению; он начинает конкурировать с остальными процессами за ресурсы –Џ. ‡аметьте, что все процессы выполнЯютсЯ параллельно со своими родителЯми. Љроме того, смерть родительского процесса не означает автоматическую смерть его дочерних процессов.

‡авершение

Џроцесс завершаетсЯ одним из двух способов:

процесс получает сигнал, который вызывает завершение процесса;
процесс вызывает функцию ‘и exit(), либо в Явном виде, либо в качестве действиЯ по умолчанию при возврате из функции main().

‡авершение включает две стадии:

‚ыполнЯетсЯ нить завершениЯ в Њенеджере процессов. ќтот "заслуживающий довериЯ" код расположен в Њенеджере процессов, но нить выполнЯетсЯ с ID завершающегосЯ процесса. ќта нить закрывает все открытые файловые дескрипторы и освобождает следующие ресурсы:
- все виртуальные каналы, принадлежащие процессу;
- всю памЯть, выделенную процессу;
- все символьные имена;
- любые старшие номера устройств (только менеджеры ввода/вывода);
- любые обработчики прерываниЯ;
- любые прокси;
- любые таймеры.
Џосле того, как нить завершениЯ выполнена, извещение о завершении процесса посылаетсЯ родительскому процессу (эта фаза выполнЯетсЯ внутри Њенеджера процессов).
…сли родительский процесс не вызвал wait() или waitpid(), то дочерний процесс становитсЯ "зомби" и не будет завершен, пока родительский процесс не вызовет wait() или не завершит выполнение. (…сли вы не хотите, чтобы процесс ждал смерти дочерних процессов, вы должны либо установить _SPAWN_NOZOMBIE флаг функциЯми qnx_spawn() или qnx_spawn_options(), либо установить действие SIG_IGN длЯ сигнала SIGCHLD посредством функции signal(). ’аким образом, дочерние процессы не будут становитьсЯ зомби после смерти.)
ђодительский процесс может ждать смерти дочернего процесса, запущенного на удаленном узле. …сли родитель процесса-зомби умирает, то зомби освобождаетсЯ.

…сли запущена утилита dumper и процесс завершаетсЯ в результате получениЯ сигнала, то генерируетсЯ дамп памЯти. ‚ы можете затем исследовать его с помощью отладчика.

‘остоЯниЯ процесса

Џроцесс всегда находитсЯ в одном из следующих состоЯний:

READY (готов) - процесс способен использовать –Џ (т.е. он не ждет наступлениЯ какого-либо событиЯ).
BLOCKED (блокирован) - процесс в одном из следующих блокированных состоЯний:
- SEND-блокирован;
- RECEIVE-блокирован;
- REPLY-блокирован;
- SIGNAL-блокирован;
- SEMAPHORE-блокирован.
HELD (приостановлен) - процесс получил сигнал SIGSTOP. ‚ этом состоЯнии процесс не имеет права использовать –Џ; выйти из состоЯниЯ HELD процесс может только в результате получениЯ сигнала SIGCONT, или завершив свою работу после получениЯ другого сигнала.
WAIT (блокирован) - процесс выполнил вызов функции wait() или waitpid() длЯ ожиданиЯ сообщениЯ о завершении выполнениЯ дочернего процесса.
DEAD (мертв) - процесс завершил выполнение, но не может послать сообщениЯ об этом родительскому процессу, т.к. родительский процесс не вызвал wait() или waitpid(). Љогда процесс находитсЯ в состоЯнии DEAD, ранее занимаемаЯ им памЯть уже освобождена. Џроцесс в состоЯнии DEAD также называют зомби.

„лЯ получениЯ более полной информации о блокированном состоЯнии обратитесь к главе "ЊикроЯдро".

fig: i/allstate.gif

‚озможные состоЯниЯ процесса в QNX.

Џоказаны следующие переходы:

Џроцесс посылает сообщение.
Џроцесс-адресат получает сообщение.
Џроцесс-адресат отвечает на сообщение.
Џроцесс ожидает сообщениЯ.
Џроцесс получает сообщение.
‘игнал разблокирует процесс.
‘игнал пытаетсЯ разблокировать процесс; адресат ранее запросил извещение о сигнале путем посылки сообщениЯ.
Џроцесс-адресат получает сообщение о сигнале.
Џроцесс ожидает смерти дочернего процесса.
„очерний процесс умирает, либо сигнал разблокирует процесс.
Џроцесс получает SIGSTOP.
Џроцесс получает SIGCONT.
Џроцесс умирает.
ђодительский процесс вызывает функцию wait() или waitpid(), завершает ее выполнение, либо ранее уже завершил выполнение.
Џроцесс вызывает функцию semwait() длЯ семафора с неположительным значением.
„ругой процесс вызывает функцию sempost(), или приходит немаскированный сигнал.

Ћпределение состоЯний процесса

—тобы определить состоЯние конкретного процесса из командного интерпретатора (Shell), используйте утилиты ps и sin (внутри приложений используйте функцию qnx_psinfo()).

—тобы определить состоЯние операционной системы в целом из командного интерпретатора (Shell), используйте утилиту sin (внутри приложений используйте функцию qnx_osinfo()).

“тилита ps определена стандартом POSIX; ее использование в командных файлах может быть переносимым в другие системы. “тилита sin, напротив, уникальна длЯ QNX; она дает вам полезную информацию, специфическую длЯ QNX, которую вы не можете получить, используЯ утилиту ps.

‘имвольные имена процессов

QNX стимулирует разработку приложений, которые разбиты на несколько взаимодействующих процессов. ’акое приложение, которое существует как группа взаимодействующих процессов, имеет большие возможности распараллеливаниЯ и может быть распределено по сети длЯ лучшей производительности.

Ћднако разделение приложений на взаимодействующие процессы требует рЯда специальных соображений. —тобы взаимодействующие процессы могли установить свЯзь между собой, они должны иметь возможность определить идентификаторы друг друга. Ќапример, допустим, что имеетсЯ сервер базы данных, который может обслуживать произвольное количество клиентов. Љлиенты могут запускатьсЯ и прекращать работу в любое времЯ, однако сервер всегда остаетсЯ доступным. Љак процессы-клиенты узнают идентификатор процесса-сервера базы данных с тем, чтобы послать ему сообщение?

‚ QNX процессы могут присваивать себе символьные имена. ‚ контексте одного узла процесса могут зарегистрировать эти имена у Њенеджера процессов на том узле, на котором они выполнЯютсЯ. Ћстальные процессы могут затем запросить у Њенеджера процессов идентификатор процесса, ассоциированный с определенным именем.

‘итуациЯ становитсЯ более сложной, если мы рассмотрим сеть, в которой сервер обслуживает клиентов, находЯщихсЯ на различных узлах. Џоэтому в QNX предусмотрена поддержка как глобальных, так и локальных имен. ѓлобальные имена определены длЯ всей сети, в то времЯ как локальные имена определены только длЯ того узла, на котором они зарегистрированы. ѓлобальные имена начинаютсЯ с косой черты (/). Ќапример:

qnx/fsys локальное имЯ

company/xyz локальное имЯ

/company/xyz глобальное имЯ

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

—тобы сделать возможным использование глобальных имен, хотЯ бы на одном узле сети должен быть запущен процесс, известный как определитель имен (утилита nameloc). ќтот процесс ведет учет всех зарегистрированных глобальных имен.

‚ каждый момент времени в сети могут быть запущены до десЯти определителей имен. Љаждый хранит идентичные копии всех активных глобальных имен. ’акаЯ избыточность гарантирует нормальное функционирование сети, даже если один или несколько узлов, обеспечивающих определение имен, выйдут из строЯ одновременно.

—тобы зарегистрировать имЯ, процесс сервер использует функцию ‘и qnx_name_attach(). —тобы определить процесс по имени, процесс клиент использует функцию ‘и qnx_name_locate().

’аймеры

€счисление времени

‚ QNX исчисление времени основываетсЯ на системном таймере, поддерживаемом операционной системой. ’аймер содержит текущее значение Љоординированного ‚семирного ‚ремени (UTC) относительно 0 часов, 0 минут, 0 секунд, 1 ЯнварЯ 1970 года. —тобы определить местное времЯ, функции исчислениЯ времени используют переменную окружениЯ TZ (котораЯ описываетсЯ в книге ђуководство пользователЯ).

Џростые средства отсчета времени

Љомандные файлы и процессы могут делать паузу на определенное количество секунд, используЯ простые средства отсчета времени. ‚ командных файлах длЯ этой цели используетсЯ утилита sleep; в процессах используетсЯ функциЯ ‘и sleep(). ’акже может использоватьсЯ функциЯ delay(), которой в качестве аргумента передаетсЯ длина интервала времени в миллисекундах.

Ѓолее сложное средство отсчета времени

Љроме того, процесс может создавать таймеры, устанавливать их на определенный интервал времени и удалЯть таймер. ќти средства отсчета времени основываютсЯ на спецификации POSIX Std 1003.4/Draft 9.

‘оздание таймеров

Џроцесс может создать один или больше таймеров. ќти таймеры могут быть любых типов и в любом сочетании. ‘ учетом конфигурируемого ограничениЯ общего числа таймеров, поддерживаемых операционной системой (смотри Proc в Ћписание утилит). „лЯ созданиЯ таймера используйте функцию timer_create().

“становка таймеров

Џри установке таймеров вы можете использовать один из двух типов интервалов времени:

абсолютный - времЯ относительно 0 часов, 0 минут, 0 секунд, 1 ЯнварЯ 1970 года;
относительный - времЯ относительно текущего показаниЯ часов.

‚ы также можете создать таймер, периодически срабатывающий с заданным интервалом времени. Ќапример, вы установили таймер таким образом, чтобы он сработал завтра в 9 часов утра. ‚ы можете задать, чтобы после этого он срабатывал каждые 5 минут.

‚ы также можете установить временной интервал длЯ существующего таймера. ђезультат будет зависеть от типа интервала времени:

длЯ абсолютного таймера новый интервал заменЯет текущий интервал времени;
длЯ относительного таймера новый интервал добавлЯетсЯ к любому остающемусЯ интервалу времени.

—тобы установить таймер:	€спользуйте функцию:
Ђбсолютный или относительный интервал	timer_settime()

“даление таймеров

—тобы удалить таймер, используйте функцию ‘и timer_delete().

“становка разрешениЯ таймера

‚ы можете установить разрешение длЯ таймера с помощью утилиты ticksize или функции qnx_timerperiod(). ‚ы можете настраивать разрешение от 500 микросекунд до 50 миллисекунд.

—тение таймера

—тобы узнать оставшийсЯ от таймера интервал или проверить, не был ли таймер удален, используйте функцию ‘и timer_gettime().

Ћбработчики прерываний

Ћбработчики прерываний обслуживают систему аппаратных прерываний компьютера - они реагируют на аппаратные прерываниЯ и осуществлЯют передачу данных между компьютером и внешними устройствами на низком уровне.

Ћбработчики прерываний физически ЯвлЯютсЯ частью стандартного процесса QNX (например, драйвер), но они всегда выполнЯютсЯ асинхронно по отношению к процессу, в который они включены.

Ћбработчик прерываний:

получает управление посредством дальнего вызова, а не непосредственно от прерываниЯ (это может быть написано на ‘и, а не на ассемблере);
выполнЯетсЯ в контексте процесс, в который он включен, таким образом имеет доступ ко всем глобальным переменам этого процесса;
выполнЯетсЯ при разрешенных прерываниЯх, но вытеснЯетсЯ только в случае, если происходит прерывание с более высоким приоритетом;
не должен непосредственно управлЯть контроллером прерываниЯ 8259 (об этом заботитсЯ операционнаЯ система);
должен быть как можно короче.

Ќесколько процессов могут обрабатывать одно и то же прерывание (если это поддерживаетсЯ аппаратно). Љогда происходит физическое прерывание, все обработчики прерываний будут по очереди получать управление. Ќе должно делатьсЯ никаких предположений относительно порЯдка, в котором будут вызыватьсЯ обработчики прерываний, разделЯющие одно и то же прерывание.

…сли вы хотите: €спользуйте функцию:

“становить обработчик прерываниЯ qnx_hint_attach()

“далить обработчик прерываниЯ qnx_hint_detach()

…сли вы хотите:	€спользуйте функцию:
“становить обработчик прерываниЯ	qnx_hint_attach()
“далить обработчик прерываниЯ	qnx_hint_detach()

Ћбработчики прерываниЯ таймера

‚ы можете установить обработчик прерываниЯ непосредственно длЯ системного таймера таким образом, что обработчик будет вызыватьсЯ по каждому прерыванию таймера. —тобы установить период, вы можете использовать утилиту ticksize.

‚ы можете также установить обработчик прерываниЯ длЯ отмасштабированного прерываниЯ таймера, которое будет происходить каждые 50 миллисекунд, независимо от tick size. ќти таймеры предлагают низкоуровневую альтернативу POSIX 1003.4 таймерам.

Џространство имен ввода/вывода

ќта глава охватывает следующие темы:

введение;
разбор имен файлов;
пространство дескрипторов файлов.

‚ведение

Џространство имен ввода/вывода

ђесурсы ввода/вывода (I/O, от английского Input/Output) в QNX не встроены внутрь ЊикроЯдра. Џроцессы обслуживающие ввод/вывод запускаютсЯ динамически во времЯ работы системы. ’ак как файловаЯ система QNX ЯвлЯетсЯ необЯзательным элементом, то пространство путей (полных имен файлов и каталогов) не встроено внутрь файловой системы, в отличие от большинства монолитных систем.

Џрефиксы и области полномочий

‚ QNX пространство имен путей разделено на области полномочий. ‹юбой процесс, выполнЯющий файл-ориентированное обслуживание ввода/вывода, должен зарегистрировать у Њенеджера процессов свой префикс, определЯЯ часть пространства имен, которое он хочет контролировать (т.е. область своих полномочий). ќти префиксы составлЯют дерево префиксов, которое хранитсЯ в памЯти на каждом компьютере под управлением QNX.

ђазборка имен путей

Џрефиксы менеджера ввода/вывода

Љогда процесс открывает файл, то полное имЯ файла сопоставлЯетсЯ с деревом префиксов с тем, чтобы отправить запрос open() к соответствующему менеджеру ресурсов ввода/вывода. Ќапример, Њенеджер устройств (Dev) обычно регистрирует префикс /dev. …сли процесс вызывает open() с аргументом /dev/xxx, то совпадет префикс /dev и open() будет направлен к Dev (его владельцу).

„ерево префиксов может содержать частично перекрывающиесЯ области полномочий. ‚ этом случае ищетсЯ наиболее длинное совпадение. Ќапример, предположим, что есть три зарегистрированных префикса:

/ дисковаЯ файловаЯ система (Fsys)

/dev система символьных устройств (Dev)

/dev/hd0 дисковый том без разделов (Fsys)

Њенеджер файловой системы зарегистрировал два префикса, один длЯ смонтированной файловой системы QNX (т.е. /) и один длЯ блок-ориентированного файла, который представлЯет весь физический жесткий диск (т.е. /dev/hd0). Њенеджер устройств зарегистрировал единственный префикс. ‘ледующаЯ таблица иллюстрирует правило наиболее длинного совпадениЯ при разборе имен путей.

€мЯ пути: ‘овпадает: ЋтноситсЯ к:

/dev/con1 /dev Dev

/dev/hd0 /dev/hd0 Fsys

/usr/dtdodge/test / Fsys

€мЯ пути:	‘овпадает:	ЋтноситсЯ к:
`/dev/con1`	`/dev`	`Dev`
`/dev/hd0`	`/dev/hd0`	`Fsys`
`/usr/dtdodge/test`	`/`	`Fsys`

„ерево префиксов хранитсЯ как список префиксов, разделенных двоеточиЯми, следующим образом:

prefix=pid,unit:prefix=pid,unit:prefix=pid,unit

где pid - это ID процесса менеджера ресурсов I/O, а unit - это один символ, используемый менеджером длЯ нумерации префиксов, которыми он владеет. ‚ приведенном выше примере, если Fsys был бы процессом 3 и Dev был бы процессом 5, то дерево префиксов выглЯдело бы как:

/dev/hd0=3,a:/dev=5,a:/=3,e

…сли вы хотите:	€спользуйте:
Џоказать дерево префиксов	“тилиту `prefix`
Џолучить дерево префиксов внутри программы на Языке ‘и	”ункцию qnx_prefix_query()

‘етевой корень

QNX поддерживают концепцию сетевого корнЯ, котораЯ позволЯет сопоставлЯть имЯ пути с деревом префиксов на конкретном узле. „лЯ обозначениЯ узла имЯ пути начинаетсЯ с двух косых черт, за которыми следует номер узла. ќто также позволЯет вам легко получать доступ к файлу и устройству, которые лежат за пределами пространства путей вашего узла. Ќапример, в типичной сети QNX возможны следующие имена путей:

/dev/ser1 локальный последовательный порт
//10/dev/ser1 последовательный порт в узле 10
//0/dev/ser1 локальный последовательный порт
//20/usr/dtdodge/test файл на узле 20

‡аметьте, что //0 всегда указывает на локальный узел

‘етевой корень по умолчанию

Љогда программа выполнЯетсЯ на удаленном узле, вы обычно хотите, чтобы она рассматривала имена путей в контексте пространства имен своего узла. Ќапример, эта команда:

//5 ls /

котораЯ запускает утилиту ls на узле 5, возвратит то же самое, что и:

ls /

запускаемаЯ на своем узле. ‚ обоих случаЯх "/" будет соотноситьсЯ с деревом префиксов на вашем узле, а не на узле 5. ‚ противном случае, можно представить себе беспорЯдок, который мог бы возникнуть, если бы префикс "/" рассматривалсЯ своим как длЯ узла 5, так и длЯ своего узла: выбирались бы одновременно файлы из разных файловых систем!

—тобы правильно интерпретировать имена путей, каждый процесс имеет сетевой корень по умолчанию, который определЯет, дерево префиксов какого узла будет использоватьсЯ длЯ разбора любых имен путей, начинающихсЯ с одиночной косой черты ("/"). Љогда разбираетсЯ имЯ пути, начинающеесЯ с одиночной косой черты, то оно предварЯетсЯ сетевым корнем по умолчанию. Ќапример, если процесс имеет сетевой корень по умолчанию //9, тогда:

/usr/home/luc

будет разбиратьсЯ, как:

//9/usr/home/luc

что может быть интерпретировано, как "разобрать путь /usr/home/luc, используЯ дерево префиксов 9-го узла".

‘етевой корень по умолчанию наследуетсЯ процессами при их создании и соответствует локальному узлу, на котором запускаетсЯ система. Ќапример, допустим, что вы работаете на узле 9, находЯсь в командном интерпретаторе, длЯ которого сетевой корень по умолчанию установлен как узел 9 (весьма типичный случай). …сли вы выполните команду:

ls /

команда унаследует сетевой корень по умолчанию //9, и в результате вы получите:

ls //9/

Џодобно тому, если бы вы ввели команду:

//5 ls /

‚ы запустили команду ls на узле 5, но она по-прежнему унаследует сетевой корень по умолчанию //9, поэтому в результате вы опЯть получите ls //9/. ‚ обоих случаЯх имЯ пути разбираетсЯ относительно одного и того же пространства имен.

…сли вы хотите: €спользуйте:

Џолучить текущий сетевой корень по умолчанию ”ункцию qnx_prefix_getroot()

“становить сетевой корень по умолчанию ”ункцию qnx_prefix_setroot()

‡апустить программу с новым сетевым корнем по умолчанию “тилиту on

…сли вы хотите:	€спользуйте:
Џолучить текущий сетевой корень по умолчанию	”ункцию qnx_prefix_getroot()
“становить сетевой корень по умолчанию	”ункцию qnx_prefix_setroot()
‡апустить программу с новым сетевым корнем по умолчанию	“тилиту `on`

Џередача имен путей между процессами

…сли запущено одновременно несколько процессов, они не обЯзательно имеют один и тот же сетевой корень по умолчанию, даже если они выполнЯютсЯ на одном и том же узле. Љ примеру, один из процессов мог унаследовать сетевой корень по умолчанию от родительского процесса на каком-либо другом узле сети, либо его сетевой корень по умолчанию мог быть в Явном виде задан родительским процессом.

Џри передаче имени пути между процессами, чьи сетевые корни могут отличатьсЯ (например, передаваЯ файл спулеру длЯ печати), вы должны добавить сетевой корень в начало имени пути, прежде чем передать путь другому процессу. …сли вы уверены, что посылающий процесс и получатель имеют один и тот же сетевой корень по умолчанию (или имЯ пути уже начинаетсЯ с //узел/), то вы можете опустить этот шаг.

Џсевдонимы префиксов

Њы рассмотрели префиксы, которые регистрируютсЯ менеджерами ресурсов I/O. ‚тораЯ форма префикса известна как псевдоним префикса, это простаЯ подстановка строки вместо искомого префикса. Џсевдоним префикса имеет форму:

prefix=строка-заменитель

Ќапример, вы работаете на машине, у которой нет локальной файловой системы (поэтому нет и процесса, который бы отвечал за "/"). Ћднако, файловаЯ система имеетсЯ на другом узле (допустим, 10), и вы хотите ее использовать как "/". ‚ы можете сделать это с помощью следующего псевдонима префикса:

/=//10/

ќто приведет к тому, что ведущаЯ косаЯ черта (/) будет заменЯтьсЯ на префикс //10/. Ќапример, путь /usr/dtdodge/test будет заменен следующим:

//10/usr/dtdodge/test

ќто новое имЯ пути будет снова сравниватьсЯ с деревом префиксов; на этот раз будет использоватьсЯ уже дерево префиксов 10 узла, т.к. имЯ пути начинаетсЯ с //10. ќто приведет к Њенеджеру файловой системы на узле 10, которому и будет направлен запрос, например, open(). ‘ помощью всего лишь нескольких символов этот псевдоним позволил нам обращатьсЯ к удаленной файловой системе как к локальной.

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

/dev=5,a:/=//10/

Џри таком дереве префиксов номера путей, начинающихсЯ с /dev, будут направлЯтьсЯ к локальному менеджеру символьных устройств, в то времЯ как запросы с любыми другими именами путей, будут направлЯтьсЯ к удаленной файловой системе.

‘оздание специальных имен устройств

‚ы также можете использовать псевдонимы созданиЯ специальных имен устройств. Ќапример, если спулер печати запущен на узле 20, то вы можете создать длЯ него локальный псевдоним следующим образом:

/dev/printer=//20/dev/spool

‹юбой запрос на открытие локального принтера /dev/printer будет направлЯтьсЯ по сети к реальному спулеру. Ђналогичным образом, если не существует локального дисковода длЯ гибких дисков, псевдоним длЯ удаленного дисковода на узле 20 может иметь вид:

/dev/fd0=//20/dev/fd0

‚ обоих рассмотренных выше случаЯх можно не использовать перенаправление с помощью псевдонима, а обращатьсЯ непосредственно к удаленному ресурсу следующим образом:

//20/dev/spool €‹€ //20/dev/fd0

Ћтносительные пути

Џуть не обЯзательно должен начинатьсЯ с одной или двух косых черт. ‚ таких случаЯх путь считаетсЯ относительным по отношению к текущему рабочему каталогу. QNX хранит текущий рабочий каталог в виде строки символов. Ћтносительные пути преобразуютсЯ в полные сетевые имена пути добавлением текущего рабочего каталога в начало относительного пути.

“чтите, что результат зависит от того, начинаетсЯ ли текущий рабочий каталог с одинарной косой черты, либо с сетевого корнЯ.

’екущий рабочий каталог

…сли текущий рабочий каталог начинаетсЯ с двойной косой черты (сетевого корнЯ), он называетсЯ определенным и привЯзан к пространству имен указанного узла. ‚ противном случае, если он начинаетсЯ с одинарной косой черты, то в начало добавлЯетсЯ сетевой корень по умолчанию.

Ќапример, эта команда:

cd //18/

ЯвлЯетсЯ примером первой (определенной) формы и привЯзывает последующие разборы относительных путей к узлу 18, независимо от того, какое значение сетевого корнЯ по умолчанию. ‚ыполнив затем команду cd dev, вы попадете в //18/dev.

‘ другой стороны, такаЯ команда:

cd /

ЯвлЯетсЯ примером второй формы, когда сетевой корень по умолчанию влиЯет на разбор относительного пути. Ќапример, если сетевой корень по умолчанию //9, тогда, выполнив команду cd dev, вы попадете в //9/dev. ’ак как текущий рабочий каталог не начинаетсЯ с указаниЯ узла, то сетевой корень по умолчанию добавлЯетсЯ длЯ получениЯ полного сетевого пути.

ќто на самом деле не так сложно, как может показатьсЯ. Ћбычно сетевые корни (//узел/) не указываютсЯ, и все, что вы делаете, просто работает внутри пространства имен вашего узла (определЯемого вашим сетевым корнем по умолчанию). Ѓольшинство пользователей, войдЯ в систему, принимают нормальный сетевой корень по умолчанию (т.е. пространство имен их собственного узла) и работают внутри этой среды.

‡амечание о `cd`

‚ некоторых традиционных UNIX системах команда cd (сменить директорию) модифицирует заданный путь, если он содержит символьные ссылки. Љак результат, путь к новому текущему рабочему каталогу - который можно посмотреть командой pwd, может отличатьсЯ от того, который был задан в команде cd.

‚ QNX, однако, cd не изменЯет путь - за исключением сокращенных ссылок "..". Ќапример:

cd /usr/home/luc/test/../doc

установит текущий рабочий каталог /usr/home/luc/doc, даже если некоторые элементы этого пути ЯвлЯютсЯ символическими свЯзЯми.

Ѓолее подробную информацию о символических свЯзЯх можно получить в главе "Њенеджер файловой системы".

—тобы получить полное сетевое имЯ пути, используйте утилиту fullpath.

Џространство дескрипторов файлов

Џри открытии ресурса I/O, open() возвращает целое число, называемое дескриптор файла (FD), которое используетсЯ затем, чтобы направлЯть все последующие запросы I/O к данному менеджеру. (‚нутри библиотечных процедур длЯ направлениЯ опроса используетсЯ вызов Ядра Sendfd().)

Џространство дескрипторов файлов, в отличие от пространства имен пути, полностью локально длЯ каждого процесса. Њенеджер использует сочетание PID и FD, чтобы определить управлЯющую структуру, созданную предыдущим вызовом open(). ќта структура называетсЯ блок управлениЯ файлом (OCB от английского open control block) и хранитсЯ внутри менеджера I/O.

‘ледующаЯ диаграмма показывает, как менеджер I/O находит соответствующий OCB длЯ пары PID и FD.

fig: i/pidfdocb.gif

PID и FD определЯют OCB длЯ Њенеджера ввода/вывода.

Ѓлоки управлениЯ файлами

OCB содержит действующую информацию об открытом ресурсе. Ќапример, файловаЯ система хранит здесь текущий указатель на позицию в файле. Љаждый вызов open() создает новый OCB. ’аким образом, если процесс дважды открывает один и тот же файл, любые вызовы lseek(), использующие один FD, не повлиЯют на текущую позицию длЯ другого FD.

’о же самое справедливо и длЯ различных процессов, открывающих один и тот же файл.

‘ледующаЯ диаграмма показывает два процесса, один из которых открывает файл дважды, а другой открывает этот же файл один раз. Џри этом нет разделЯемых FD.

fig: i/tmpfile.gif

Џроцесс A открывает файл /tmp/file дважды. Џроцесс B открывает тот же файл один раз.

Ќесколько дескрипторов файла в одном или нескольких процессах могут указывать на один и тот же OCB. ќто может быть достигнуто двумЯ способами:

процесс может использовать функции ‘и dup(), dup2() или fcntl() длЯ созданиЯ дубликата дескриптора файла, который указывает на тот же самый OCB;
при создании нового процесса посредством fork(), spawn() или exec(), все дескрипторы открытых файлов по умолчанию наследуютсЯ новым процессом; эти наследуемые дескрипторы указывают на те же самые OCB, что и соответствующие дескрипторы файла в родительском процессе.

Љогда несколько FD указывают на один и тот же OCB, тогда любое изменение в состоЯнии OCB немедленно видимо длЯ всех процессов, у которых есть дескрипторы файлов, указывающие на этот OCB.

Ќапример, если один из процессов использует функцию lseek() длЯ изменениЯ текущей позиции, тогда чтение или запись начинаетсЯ с новой позиции, независимо от того, какой из дескрипторов файла используетсЯ.

‘ледующаЯ диаграмма показывает два процесса, из которых один открывает файл дважды, а затем вызывает dup(), чтобы получить третий дескриптор. ‡атем он создает дочерний процесс, который наследует все открытые файлы.

fig: i/dupfd.gif

Џроцесс открывает файл дважды, а затем получает третий FD посредством dup(). …го дочерний процесс унаследует все эти три дескриптора файла.

‚ы можете предотвратить наследование дескриптора файла при использовании spawn() или exec(), предварительно вызвав функцию fcntl() и установив флаг FD_CLOEXEC.

Њенеджер файловой системы

ќта глава охватывает следующие темы:

введение;
что такое файл?
регулЯрные файлы и каталоги;
свЯзи и индексные дескрипторы (inodes);
символические свЯзи;
программные каналы (pipes) и FIFO;
производительность Њенеджера файловой системы;
надежность файловой системы;
работа с дисками;
ключевые компоненты раздела QNX;
менеджер файловой системы DOS;
файловаЯ система CD-ROM;
файловаЯ система флэш;
файловаЯ система NFS;
файловаЯ система SMB.

‚ведение

Њенеджер файловой системы (Fsys) обеспечивает стандартизованные способы сохранениЯ данных на дисках и доступа к ним. Fsys отвечает за обработку всех запросов на открытие, закрытие, чтение и запись файлов.

—то такое файл?

‚ QNX файл - это объект, в который может производитьсЯ запись, из которого может производитьсЯ чтение, либо и то и другое. QNX поддерживает шесть типов файлов; пЯть из них поддерживает Fsys:

регулЯрные файлы - состоЯт из последовательности байт с произвольным доступом и не имеют предопределенной структуры;
каталоги - содержат информацию, необходимую длЯ поиска регулЯрных файлов; также содержат статус и атрибуты длЯ каждого регулЯрного файла;
символические свЯзи - содержат путь к файлу или каталогу, к которым перенаправлЯютсЯ все запросы; символические свЯзи часто используютсЯ длЯ предоставлениЯ множества путей к одному файлу;
программные каналы (pipes) и FIFO - служат как каналы ввода/вывода между взаимодействующими процессами;
блок-ориентированные файлы - относЯтсЯ к устройствам, таким, как диски, ленты и разделы дисков. „оступ к этим файлам обычно осуществлЯетсЯ таким образом, что аппаратные характеристики устройств скрыты от приложений.

‚се эти типы файлов подробно описываютсЯ в этой главе. естой тип файлов - блок-ориентированные файлы - обслуживаетсЯ Њенеджером устройств.

Њетки даты и времени

Fsys поддерживает четыре различных метки времени длЯ каждого файла. ќто:

дата последнего доступа (чтениЯ);
дата последней записи;
дата последней модификации;
дата созданиЯ (уникальна длЯ QNX).

„оступ к файлам

„оступ к регулЯрным файлам и каталогам управлЯетсЯ битами режима, хранЯщимисЯ в inode (индексном дескрипторе) файла. Ѓолее подробно inode описан в секции "‘вЯзи и индексные дескрипторы (inodes)". ќти биты разрешают чтение, запись и выполнение в зависимости от эффективных ID пользователЯ и группы. Џри этом пользователи делЯтсЯ на три категории:

владелец файла;
члены группы, к которой принадлежит владелец;
остальные.

Џроцесс может выполнЯтьсЯ с ID пользователЯ или ID группы файла, а не родительского процесса. Њеханизм, который позволЯет это, называетсЯ setuid (установить ID пользователЯ) и setgid (установить ID группы).

ђегулЯрные файлы и каталоги

ђегулЯрные файлы

QNX рассматривает регулЯрный файл как последовательность байт с возможностью произвольного доступа и не имеющую другой предопределенной внутренней структуры. Џрикладные программы сами несут ответственность за понимание структуры и содержаниЯ конкретного регулЯрного файла.

ђегулЯрные файлы составлЯют большинство файлов в файловых системах. ”айловые системы поддерживаютсЯ Њенеджером файловой системы и реализованы на базе блок-ориентированных файлов, соответствующих разделам диска (разделы описаны в секции "ђабота с дисками").

Љаталоги

Љаталог - это файл, который содержит элементы каталога. Љаждый элемент каталога увЯзывает имЯ файла с файлом. €мЯ файла - это символьное имЯ, которое позволЯет идентифицировать файл и работать с ним. ”айл может быть идентифицирован несколькими именами (смотри секции "‘вЯзи и индексные дескрипторы (inodes)" и "‘имволические свЯзи").

‘ледующаЯ диаграмма показывает, как производитсЯ поиск файла с именем /usr/bill/file2.

fig: i/dirpath.gif

Џуть в структуре каталога QNX к файлу /usr/bill/file2.

Ћперации с каталогами

•отЯ каталог ведет себЯ во многом как стандартный файл, Њенеджер файловой системы накладывает некоторые ограничениЯ на операции, которые вы можете производить с каталогом. ‚ частности, вы не можете открыть каталог длЯ записи либо создать свЯзь длЯ каталога с помощью функции ‘и link().

—тение элементов каталога

„лЯ чтениЯ элементов каталога вы можете использовать набор функций ‘и, определенных POSIX, которые обеспечивают не зависимый от Ћ‘ доступ к элементам каталога. ќти функции включают:

opendir()
readdir()
rewinddir()
closedir()

’ак как каталоги QNX - это просто файлы, содержащие "известную" информацию, вы можете также читать элементы каталога непосредственно функциЯми ‘и open() и read(). Ћднако эта техника не переносима - формат элементов каталога отличаетсЯ в различных операционных системах.

ќкстенты

‚ QNX регулЯрные файлы и файлы каталога хранЯтсЯ как последовательность экстентов. ќкстент - это непрерывнаЯ последовательность блоков на диске.

ѓде хранЯтсЯ экстенты

”айлы, которые состоЯт только из одного экстента, хранЯт информацию об экстенте в элементе каталога. Ќо, если файл состоит более чем из одного экстента, информациЯ о расположении экстентов хранитсЯ в одном или более свЯзных блоках экстентов (свЯзные - имеющие прЯмые/обратные указатели). Љаждый блок экстентов может содержать информацию не более чем о 60 экстентах.

fig: i/extents.gif

”айл, состоЯщий из множества непрерывных областей на диске, называемых в QNX экстентами.

“величение файлов

Љогда Њенеджеру файловой системы необходимо увеличить файл, он сначала пытаетсЯ увеличить последний экстент, хотЯ бы даже на один блок. Ќо если последний экстент не может быть дополнен, то длЯ расширениЯ файла выделЯетсЯ новый экстент.

„лЯ выделениЯ новых экстентов Њенеджер файловой системы использует метод "первого попаданиЯ". ‘пециальнаЯ таблица в Њенеджере файловой системы содержит сведениЯ обо всех блоках, описанных в файле /.bitmap (этот файл описан в секции "Љлючевые компоненты раздела QNX"). „лЯ каждого блока указываетсЯ размер соответствующего ему свободного экстента. Њенеджер файловой системы выбирает из таблицы первый достаточно большой экстент.

‘вЯзи и индексные дескрипторы (inodes)

‚ QNX файл может обозначатьсЯ более чем одним именем. Љаждое имЯ файла называетсЯ свЯзью. ‚ действительности существует два вида свЯзей: жесткие свЯзи, или просто "свЯзи", и символические свЯзи. ‘имволические свЯзи описаны в следующей секции.

„лЯ поддержки свЯзей каждого файла, имЯ файла отделЯетсЯ от остальной информации, описывающей файл. ќта информациЯ хранитсЯ в структуре, называемой inode (индексным дескриптором).

…сли файл имеет только одну свЯзь (т.е. одно имЯ), то блок inode хранитсЯ в элементе каталога длЯ этого файла. Ќо если файл имеет более чем одну свЯзь, то inode хранитсЯ как запись в специальном файле /.inodes, а элемент каталога длЯ файла содержит указатель на запись inode.

“чтите, что вы можете создать свЯзь длЯ файла, только если файл и свЯзь находЯтсЯ в одной и той же файловой системе.

fig: i/twolinks.gif

Ћдин и тот же файл обозначен двумЯ свЯзЯми с именами "more" и "less".

‘уществует еще две ситуации, в которых длЯ файла создаетсЯ запись в файле /.inodes:

если имЯ файла длиннее чем 16 символов, то информациЯ inode хранитсЯ в файле /.inodes, оставлЯЯ место в элементе каталога длЯ 48-символьного имени файла;
если файл имел более одной свЯзи и все свЯзи, кроме одной, были удалены, то за файлом сохранЯетсЯ отдельнаЯ запись в файле /.inodes. ќто сделано, чтобы избежать поиска элемента каталога, указывающего на inode (элементы inode не имеют обратных свЯзей с элементами каталога).

…сли вы хотите:	€спользуйте:
‘оздать свЯзь из командного интерпретатора	“тилиту `ln`
‘оздать свЯзь из программы	”ункцию link()

“даление свЯзей

Џри создании файла, длЯ него устанавливаетсЯ счетчик свЯзей, равный единице. Џо мере добавлениЯ ссылок этот счетчик увеличиваетсЯ; при удалении свЯзи счетчик свЯзей уменьшаетсЯ. ”айл не удалЯетсЯ с диска до того, как счетчик свЯзей станет равным нулю и все программы, использующие этот файл, закроют его. ќто позволЯет использовать открытый файл даже после того, как у него удалены все свЯзи.

…сли вы хотите: €спользуйте:
“далить свЯзь из командного интерпретатора “тилиту rm

“далить свЯзь из программы ”ункции remove() или unlink()

…сли вы хотите:	€спользуйте:
“далить свЯзь из командного интерпретатора	“тилиту `rm`
“далить свЯзь из программы	”ункции remove() или unlink()

‘вЯзи каталога

‚ы не можете создавать жесткие свЯзи длЯ каталога. Ћднако каждый каталог имеет две жестко определенные свЯзи:

. ("точка")
.. ("точка точка")

€мЯ файла "точка" соответствует текущему каталогу; "точка точка" соответствует каталогу, предшествующему текущему каталогу.

‡аметьте, что "точка точка" длЯ каталога "/" - это просто "/", - вы не можете поднЯтьсЯ выше.

‘имволические свЯзи

‘имволическаЯ свЯзь - это особый файл, который содержит в качестве данных имЯ пути. Љогда символическаЯ свЯзь используетсЯ в запросе ввода/вывода - например, open(), - обозначение свЯзи в имени пути заменЯетсЯ ее "данными". ‘имволическаЯ свЯзь ЯвлЯетсЯ гибким средством длЯ перенаправлениЯ пути и часто используетсЯ длЯ созданиЯ множества путей к одному и тому же файлу. ‚ отличие от жестких свЯзей, символические свЯзи могут выходить за пределы файловой системы и также ЯвлЯтьсЯ свЯзЯми длЯ каталогов.

‚ следующем примере каталоги //1/usr/fred и //2/usr/barney ЯвлЯютсЯ свЯзЯми на один и тот же каталог, хотЯ они находЯтсЯ в различных файловых системах, и даже на различных узлах (смотри следующую диаграмму). ќто не может быть сделано с использованием жестких свЯзей:

//1/usr/fred --> //2/usr/barney

‡аметьте, что символическаЯ свЯзь и адресуемый каталог не обЯзаны иметь одно и то же имЯ. ‚ большинстве случаев символические свЯзи используютсЯ длЯ привЯзки одного каталога к другому. Ћднако они также могут быть использованы длЯ файлов, как в этом примере:

//1/usr/eric/src/test.c --> //1/usr/src/game.c

Figure showing two nodes using symbolic links

…сли вы хотите: €спользуйте утилиту:

‘оздать символическую свЯзь ln (с опцией -s)

“далить символическую свЯзь* rm

“знать, ЯвлЯетсЯ ли файл символической свЯзью ls

…сли вы хотите:	€спользуйте утилиту:
‘оздать символическую свЯзь	`ln` (с опцией `-s`)
“далить символическую свЯзь*	`rm`
“знать, ЯвлЯетсЯ ли файл символической свЯзью	`ls`

* Џомните, что удаление символической свЯзи действует только на свЯзь, а не на адресуемый объект

Ќекоторые функции оперируют непосредственно с символическими свЯзЯми. „лЯ этих функций замена обозначениЯ свЯзи в пути на ее содержимое не производитсЯ. Љ этим функциЯм относЯтсЯ unlink() (котораЯ удалЯет символическую свЯзь), lstat() и readlink().

’ак как символические свЯзи могут указывать на каталоги, то невернаЯ конфигурациЯ может привести к проблемам, таким, как циклические свЯзи. —тобы защититьсЯ от циклических свЯзей, система накладывает ограничениЯ на количество переходов; этот предел определен как SYMLOOP_MAX во включаемом файле <limits.h>.

Џрограммные каналы (pipes) и FIFO

Џрограммные каналы (pipes)

Џрограммный канал - это неименованный файл, который служит как канал ввода/вывода между двумЯ или более взаимодействующими процессами - один процесс пишет в программный канал, другой читает из программного канала. Њенеджер файловой системы обеспечивает буферизацию данных. ђазмер буфера определен как PIPE_BUF в файле <limits.h>. Џрограммный канал удалЯетсЯ после того как закрыты оба его конца.

Џрограммные каналы обычно используютсЯ, когда два процесса хотЯт выполнЯтьсЯ параллельно, с однонаправленной передачей данных от одного процесса к другому. …сли требуетсЯ двунаправленнаЯ передача данных, то должны использоватьсЯ сообщениЯ.

’ипичное применение программного канала состоит в соединении вывода одной программы с вводом другой программы. ќто соединение часто производитсЯ командным интерпретатором (Shell). Ќапример:

ls | more

направлЯет стандартный вывод от утилиты ls через программный канал в стандартный ввод утилиты more.

…сли вы хотите: €спользуйте:

‘оздать программный канал из командного интерпретатора ‘имвол программного канала ("|")

‘оздать программный канал из программы ”ункции pipe() или popen()

…сли вы хотите:	€спользуйте:
‘оздать программный канал из командного интерпретатора	‘имвол программного канала ("`\|`")
‘оздать программный канал из программы	”ункции pipe() или popen()

Ќа бездисковых рабочих станциЯх вы можете запустить Њенеджер программных каналов (Pipe) вместо Њенеджера файловой системы, когда требуютсЯ только программные каналы. Њенеджер программных каналов оптимизирован длЯ канального (конвейерного) ввода/вывода и может обеспечить большую пропускную способность, чем Њенеджер файловой системы.

FIFO

FIFO - это по существу то же самое, что и программные каналы, за исключением того, что FIFO ЯвлЯютсЯ именованными постоЯнными файлами, которые хранЯтсЯ в каталогах файловой системы.

…сли вы хотите: €спользуйте:
‘оздать FIFO из командного интерпретатора “тилиту mkfifo

‘оздать FIFO из программы ”ункцию mkfifo()

“далить FIFO из командного интерпретатора “тилиту rm

“далить FIFO из программы ”ункции remove() или unlink()

…сли вы хотите:	€спользуйте:
‘оздать FIFO из командного интерпретатора	“тилиту `mkfifo`
‘оздать FIFO из программы	”ункцию mkfifo()
“далить FIFO из командного интерпретатора	“тилиту `rm`
“далить FIFO из программы	”ункции remove() или unlink()

Џроизводительность Њенеджера файловой системы

‘войства Њенеджера файловой системы, обеспечивающие высокопроизводительный доступ к диску:

лифтовый поиск;
кэш-буфер;
многопотоковаЯ обработка;
клиент-управлЯемый приоритет;
временные файлы;
псевдодиски.

‹ифтовый поиск

‹ифтовый поиск минимизирует общие затраты времени на позиционирование магнитной головки при чтении или записи на диск. ‡апросы ввода/вывода упорЯдочиваютсЯ таким образом, чтобы все они могли быть выполнены за один проход магнитной головки, от самого младшего к самому старшему адресу на диске.

‹ифтовый поиск также имеет усовершенствование, обеспечивающее выполнение мультисекторного ввода/вывода там, где возможно.

Љэш-буфер

Љэш-буфер - это интеллектуальный буфер между Њенеджером файловой системы и драйвером диска. Љэш-буфер хранит блоки файлов с целью минимизировать количество обращений Њенеджера файловой системы к диску. Џо умолчанию размер кэша определЯетсЯ общим объемом оперативной памЯти, но вы можете задать другое значение через опцию при запуске Fsys.

Ћперации чтениЯ ЯвлЯютсЯ синхронными. Ћперации записи, напротив, обычно ЯвлЯютсЯ асинхронными. Љогда данные попадают в кэш, Њенеджер файловой системы отвечает клиенту (функцией Reply()), извещаЯ его, что данные записаны. ‡атем выполнЯетсЯ запись данных на диск с максимально-возможной скоростью, обычно не позднее, чем через пЯть секунд.

ЏриложениЯ могут изменЯть механизм записи применительно к конкретным файлам. Ќапример, приложение, работающее с базой данных, может потребовать, чтобы запись в определенный файл производилась синхронно. ќто обеспечит высокий уровень целостности файла в случае аппаратного или программного сбоЯ.

ЊногопотоковаЯ обработка

Њенеджер файловой системы ЯвлЯетсЯ многопотоковым процессом, и, таким образом, он может обрабатывать несколько запросов ввода/вывода одновременно. ќто позволЯет Њенеджеру файловой системы в полной мере реализовать возможности параллельной обработки, так как он в состоЯнии:

получить одновременный доступ к нескольким устройствам;
удовлетворить запросы ввода/вывода из кэш-буфера, в то времЯ как выполнЯютсЯ другие запросы ввода/вывода, осуществлЯющие доступ к диску.

Љлиент-управлЯемый приоритет

Џриоритет Њенеджера файловой системы может определЯтьсЯ приоритетом процесса, пославшего ему запрос. ‚ этом случае, когда Њенеджер файловой системы получает сообщение, его приоритет устанавливаетсЯ равным приоритету процесса, пославшего сообщение. Ѓолее подробно об этом говоритсЯ в разделе "„испетчеризациЯ процессов" главы "ЊикроЯдро".

‚ременные файлы

QNX предусматривает возможность открытиЯ временных файлов, т.е. файлов, которые записываютсЯ и затем читаютсЯ в течение короткого промежутка времени. „лЯ таких файлов Њенеджер файловой системы стараетсЯ хранить блоки данных в кэш-буфере и производит запись блоков на диск только в случае крайней необходимости.

Џсевдодиски

Њенеджер файловой системы содержит встроенную возможность поддержки электронного диска, позволЯющую использовать до 8 Његабайт оперативной памЯти в качестве псевдодиска. ’ак как Њенеджер файловой системы использует высокоэффективный механизм составных сообщений, то данные из псевдодиска копируютсЯ непосредственно в приложение.

Њенеджер файловой системы в состоЯнии обойти кэширование, так как псевдодиск ЯвлЯетсЯ встроенным, а не реализован как отдельный драйвер. „лЯ информации об обмене составными сообщениЯми, смотри раздел "„ополнительные возможности" в главе "ЊикроЯдро".

’ак как псевдодиски исключают аппаратные задержки и не используют кэширование данных, поэтому они обеспечивают больший детерминизм при выполнении операций ввода/вывода по сравнению с жесткими дисками.

Ќадежность файловой системы

‚ QNX высокаЯ производительность файловой системы достигаетсЯ не за счет снижениЯ надежности. ќто обеспечиваетсЯ несколькими способами.

‚ то времЯ как большаЯ часть данных помещаетсЯ в кэш-буфер и записываетсЯ с небольшой задержкой, критические длЯ файловой системы данные записываютсЯ немедленно. ЋбновлениЯ каталогов, индексных дескрипторов (inodes), блоков экстентов и битовой карты производЯтсЯ без задержки, чтобы гарантировать целостность структуры файловой системы на диске (т.е. что не будет внутреннего несоответствиЯ данных на диске).

€ногда все перечисленные выше структуры данных должны быть обновлены. Ќапример, если вы перемещаете файл в каталоге, последний экстент которого заполнен, то каталог должен вырасти. ‚ таких случаЯх порЯдок операций тщательно подобран таким образом, что даже если произойдет катастрофический сбой в момент, когда операциЯ еще не полностью завершена (например, отключение питаниЯ), то файловаЯ система после перезапуска все же сохранит работоспособность. ‚ худшем случае, некоторые блоки будут выделены, но не использованы. €справить подобную ситуацию можно, запустив утилиту chkfsys.

‚осстановление файловой системы

„аже самые надежные системы не застрахованы от аварийных ситуаций, таких как:

поЯвление плохих блоков на диске в результате бросков или провалов напрЯжениЯ;
неумелый или злонамеренный пользователь, имеющий доступ к привилегиЯм администратора системы, выполнил инициализацию файловой системы (утилитой dinit);
некорректнаЯ программа (в особенности, выполнЯющаЯсЯ не в среде QNX) игнорирует информацию о разделах диска и перезаписывает часть раздела QNX.

—тобы после таких ситуаций можно было восстановить как можно больше файлов, на диск записываютсЯ уникальные "сигнатуры" длЯ автоматической идентификации и восстановлениЯ критических частей файловой системы. ”айл с индексными дескрипторами (/.inodes), так же как и каждый каталог, и блок экстентов, все содержат уникальные образцы данных, которые могут быть использованы утилитой chkfsys длЯ восстановлениЯ серьезно поврежденной файловой системы.

Ѓолее подробнаЯ информациЯ о восстановлении файловой системы содержитсЯ в документации к утилите chkfsys.

ђабота с дисками

Њенеджер файловой системы управлЯет блок-ориентированными файлами. ќти файлы определЯют диски и разделы дисков.

„иски и дисковые подсистемы

QNX считает каждый физический диск на компьютере блок-ориентированным файлом. Љак блок-ориентированный файл, диск рассматриваетсЯ файловой системой QNX как последовательность блоков размером по 512 байт, независимо от размера диска. Ѓлоки нумеруютсЯ, начинаЯ с первого блока на диске (блок 1).

’ак как каждый диск ЯвлЯетсЯ блок-ориентированным файлом, он может быть открыт как одно целое длЯ низкоуровневого доступа с использованием стандартных POSIX ‘и функций, таких как open(), read(), write() и close(). Ќа уровне блок-ориентированного файла, который определЯет целый диск, QNX не делает абсолютно никаких предположений о каких-либо структурах данных, которые могут существовать на диске.

Љомпьютер под управлением QNX может иметь одну или несколько дисковых подсистем. ЉаждаЯ дисковаЯ подсистема состоит из контроллера и одного или более дисков. ‚ы запускаете драйвер устройства длЯ каждой дисковой подсистемы, котораЯ должна управлЯтьсЯ Њенеджером файловой системы.

ђазделы Ћ‘

QNX соответствует промышленному стандарту де-факто, который позволЯет различным операционным системам разделЯть один и тот же физический диск. ‚ соответствии с этим стандартом, таблица разделов может определЯть до четырех первичных разделов на диске. ’аблица хранитсЯ в первом блоке диска.

Љаждый раздел должен иметь "тип", узнаваемый операционной системой, котораЯ должна использовать этот раздел. ‘ледующий список содержит используемые на данный момент типы разделов:

’ип: ЋперационнаЯ система

1 DOS (12-битнаЯ FAT)

4 DOS (16-битнаЯ FAT; разделы <32Mбайт)

5 ђасширенный раздел DOS

6 DOS 4.0 (16-битнаЯ FAT; раздел >=32Mбайт)

7 OS/2 HPFS

7 ЏредыдущаЯ версиЯ QNX 2 (до 1988)

8 QNX 1.x и 2.x ("qny")

9 QNX 1.x и 2.x ("qnz")

11 DOS 32-битнаЯ FAT; разделы до 2047Gбайт

12 ’о же, что тип 11, но использует LBA расширениЯ прерываниЯ Int 13h

14 ’о же, что тип 6, но использует LBA расширениЯ прерываниЯ Int 13h

15 ’о же, что тип 5, но использует LBA расширениЯ прерываниЯ Int 13h

77 QNX POSIX раздел

78 QNX POSIX раздел (вторичный)

79 QNX POSIX раздел (вторичный)

99 UNIX

’ип:	ЋперационнаЯ система
1	DOS (12-битнаЯ FAT)
4	DOS (16-битнаЯ FAT; разделы <32Mбайт)
5	ђасширенный раздел DOS
6	DOS 4.0 (16-битнаЯ FAT; раздел >=32Mбайт)
7	OS/2 HPFS
7	ЏредыдущаЯ версиЯ QNX 2 (до 1988)
8	QNX 1.x и 2.x ("`qny`")
9	QNX 1.x и 2.x ("`qnz`")
11	DOS 32-битнаЯ FAT; разделы до 2047Gбайт
12	’о же, что тип 11, но использует LBA расширениЯ прерываниЯ `Int 13h`
14	’о же, что тип 6, но использует LBA расширениЯ прерываниЯ `Int 13h`
15	’о же, что тип 5, но использует LBA расширениЯ прерываниЯ `Int 13h`
77	QNX POSIX раздел
78	QNX POSIX раздел (вторичный)
79	QNX POSIX раздел (вторичный)
99	UNIX

…сли вы хотите иметь несколько разделов QNX 4.x на одном физическом диске, вам следует использовать тип 77 длЯ первого QNX раздела, тип 78 длЯ второго QNX раздела, и тип 79 длЯ третьего. ‚ы можете использовать другие типы длЯ второго и третьего QNX разделов, но 78 и 79 предпочтительнее. —тобы пометить любой из этих разделов как загрузочный, используйте утилиту fdisk.

‚о времЯ загрузки, загрузчик QNX (опционально устанавливаемый утилитой fdisk) позволЯет выбирать в таблице разделов в качестве загрузочного другой раздел, не ЯвлЯющийсЯ загрузочным по умолчанию.

‚ы можете использовать утилиту fdisk длЯ созданиЯ, модификации или удалениЯ разделов.

’ак как QNX рассматривает каждый раздел на диске как блок-ориентированный файл, то это дает возможность доступа к следующему:

диску целиком, игнорируЯ разделы, как к блок-ориентированному файлу;
отдельному разделу как к блок-ориентированному файлу; этот блок-ориентированный файл будет подмножеством блок-ориентированного файла, который определЯет весь диск.

fig: i/twodisks.gif

„ва физических диска. Џервый содержит DOS, QNX и UNIX разделы. ‚торой диск имеет DOS и QNX разделы.

Ћпределение блок-ориентированный файлов

€мена всех блок-ориентированных файлов помещаютсЯ в дерево префиксов того компьютера, на котором расположены блок-ориентированные файлы (дерево префиксов рассматриваетсЯ в главе "Џространство имен ввода/вывода"). Љогда запускаетсЯ драйвер контроллера дисков, Њенеджер файловой системы автоматически регистрирует префиксы, которые определЯют блок-ориентированный файл длЯ каждого физического диска, подключенного к контроллеру. “тилита mount используетсЯ длЯ того, чтобы зарегистрировать префикс длЯ блок-ориентированного файла длЯ каждого раздела на диске.

Џусть, например, у вас имеетсЯ стандартный контроллер Western Digital, к которому подключены два диска. Ќа одном диске вы хотите смонтировать раздел DOS, раздел QNX и раздел UNIX. Ќа другом диске вы хотите смонтировать раздел DOS и раздел QNX.

Њенеджер файловой системы определит блок-ориентированные файлы /dev/hd0 и /dev/hd1 длЯ двух дисков, подключенных к контроллеру.

‡атем вы используете утилиту mount, чтобы определить блок-ориентированный файл длЯ каждого раздела. Ќапример:

mount -p /dev/hd0 -p /dev/hd1

определит следующие блок-ориентированные файлы:

ђаздел Ћ‘: Ѓлок-ориентированный файл:

ђаздел DOS на диске hd0 /dev/hd0t4

ђаздел QNX на диске hd0 /dev/hd0t77

ђаздел UNIX на диске hd0 /dev/hd0t99

ђаздел DOS на диске hd1 /dev/hd1t4

ђаздел QNX на диске hd1 /dev/hd1t77

ђаздел Ћ‘:	Ѓлок-ориентированный файл:
ђаздел DOS на диске `hd0`	`/dev/hd0t4`
ђаздел QNX на диске `hd0`	`/dev/hd0t77`
ђаздел UNIX на диске `hd0`	`/dev/hd0t99`
ђаздел DOS на диске `hd1`	`/dev/hd1t4`
ђаздел QNX на диске `hd1`	`/dev/hd1t77`

‡аметьте, что обозначение tn используетсЯ длЯ обозначениЯ разделов на диске, используемых определенными операционными системами. Ќапример, раздел DOS обозначаетсЯ t4, раздел UNIX - это t99 и т.д.

Њонтирование файловой системы

Ћбычно файловаЯ система QNX монтируетсЯ на блок-ориентированном файле. „лЯ этого вы снова используете утилиту mount - она позволЯет задать префикс, который идентифицирует файловую систему. Ќапример:

mount /dev/hd0t77 /

монтирует файловую систему с префиксом / на разделе, который определен блок-ориентированным файлом с именем hd0t77.

…сли диск разбит на разделы, то вы должны смонтировать блок-ориентированный файл длЯ раздела QNX 4.x (например /dev/hd0t77), а не основной блок-ориентированный файл, который определЯет весь диск (например, /dev/hd0). …сли вы попытаетесь смонтировать основной блок-ориентированный файл длЯ всего диска, то при попытке доступа к файловой системе получите сообщение "corrupt filesystem" (поврежденнаЯ файловаЯ система).

„емонтирование файловой системы

—тобы демонтировать файловую систему, используйте утилиту umount. ’ак, например, следующаЯ команда демонтирует файловую систему на первичном разделе QNX:

umount /dev/hd0t77

Џосле того, как файловаЯ система демонтирована, файлы в этом разделе уже не доступны.

Љлючевые компоненты QNX раздела

‚ начале каждого раздела QNX располагаютсЯ следующие ключевые компоненты:

блок загрузчика;
корневой блок;
битоваЯ карта;
корневой каталог.

ќти структуры создаютсЯ при инициализации файловой системы утилитой dinit.

fig: i/qnxpart.gif

‘труктура файловой системы QNX внутри раздела диска.

Ѓлок загрузчика

ќто первый физический блок раздела диска. ќтот блок содержит код, который загружаетсЯ и затем исполнЯетсЯ BIOS компьютера длЯ загрузки операционной системы из раздела. …сли диск не разбит на разделы (например, гибкий диск), этот блок ЯвлЯетсЯ первым физическим блоком на диске.

Љорневой блок

Љорневой блок имеет ту же структуру, что и обычный каталог. Ћн содержит информацию о четырех особых файлах:

корневой каталог файловой системы (/)
файл /.inodes
файл /.boot
файл /.altboot

”айлы /.boot и /.altboot содержат образы операционной системы, которые загружаютсЯ программой начальной загрузки QNX.

Ћбычно загрузчик QNX загружает образ Ћ‘, хранЯщийсЯ в файле /.boot. Ќо если файл /.altboot не пуст, то вам будет предложена опциЯ загрузки образа, хранЯщегосЯ в файле /.altboot.

ЃитоваЯ карта

—тобы распределЯть пространство на диске, QNX использует битовую карту, хранЯщуюсЯ в файле /.bitmap. ќтот файл содержит битовую маску длЯ всех блоков на диске, показывающую, какие блоки занЯты. Љаждому блоку соответствует один бит. …сли значение бита 1, то соответствующий блок на диске занЯт.

Љорневой каталог

Љорневой каталог раздела ведет себЯ как обычный каталог, за двумЯ исключениЯми:

как ".", так и ".." ЯвлЯютсЯ свЯзЯми к одной и той же inode информации, а именно, корневым каталогом inode в корневом блоке;
корневой каталог всегда содержит элементы длЯ файлов /.bitmap, /.inodes, /.boot и /.altboot. ќти элементы предусмотрены длЯ того, чтобы программы, которые выдают информацию о файловой системе, видели эти элементы как обычные файлы.

Њенеджер файловой системы DOS

‚ QNX пространство имен ввода/вывода управлЯетсЯ через префиксы, которые направлЯют запросы соответствующим процессам-менеджерам. Ћдним из таких процессов ЯвлЯетсЯ Њенеджер файловой системы DOS (Dosfsys). Dosfsys регистрирует префикс /dos и представлЯет диски DOS внутри пространства имен QNX как "гостевые" файловые системы.

Dosfsys обеспечивает прозрачный доступ к дискам DOS, так что вы можете рассматривать файловые системы DOS как файловые системы QNX. ’акаЯ прозрачность позволЯет процессам работать с файлами DOS без каких-либо специальных знаний или действий. ‘тандартные библиотечные функции ввода/вывода, такие как open(), close(), read() и write() работают с файлом в разделе DOS точно так же, как и с файлом в разделе QNX. Ќапример, чтобы копировать файл из раздела QNX в раздел DOS, достаточно выполнить команду:

cp /usr/luc/file.dat /dos/c/file.dat

‡аметьте, что /dos/c - это путь к DOS диску C. Љоманда cp не содержит какого-либо специального кода длЯ определениЯ, находитсЯ ли копируемый файл на диске DOS. „ругие команды работают с такой же прозрачностью (например, утилиты cd, ls и mkdir).

…сли не существует эквивалента DOS длЯ функции QNX, такой как mkfifo() или link(), то Dosfsys возвращает соответствующий код ошибки (т.е. errno).

Dosfsys работает как с гибкими дисками, так и с разделами жестких дисков. ‚есь требуемый доступ к диску на низком уровне производитсЯ через стандартные функции Њенеджера файловой системы. Џоэтому, без доступа к коду низкого уровнЯ, Dosfsys способен обеспечить прозрачный интерфейс между приложениЯми QNX и файловой системой DOS.

”айловаЯ система CD-ROM

”айловаЯ система CD-ROM, Iso9660fsys, обеспечивает прозрачный доступ к носителЯм CD-ROM, таким образом можно работать с файловыми системами CD-ROM, как будто это файловые системы POSIX. ’акаЯ прозрачность обеспечивает процессам доступ к файлам на CD-ROM стандартными средствами.

Њенеджер Iso9660fsys реализует стандарт ISO 9660, включаЯ расширениЯ Rock Ridge. ќтому стандарту соответствуют компакт-диски DOS и Windows. ‚ дополнение к обычным файлам, Iso9660fsys также поддерживает аудио.

”айловаЯ система флэш

Њенеджер файловой системы флэш Efsys.* был специально разработан длЯ работы, как со встроенной, так и со сменной флэш-памЯтью. ”айлы, записанные на сменные носители флэш (карты PC-Card), переносимы в другие системы, которые также поддерживают этот стандарт.

Њенеджер Efsys.* сочетает функции менеджера файловой системы и драйвера устройства. ’ак как Efsys.* содержит драйвер устройства, то существуют отдельные версии Efsys.* длЯ различных видов оборудованиЯ встраиваемых систем. Ќапример:

Efsys.explr2 длЯ платы Intel EXPLR2 (с RFA);
Efsys.elansc400 длЯ платы AMD Elan SC400;
Efsys.pcmcia длЯ смешанного использованиЯ файловых систем флэш и устройств PCMCIA.

ЋграничениЯ

”ункциональность файловой системы ограничена используемыми устройствами памЯти. Ќапример, длЯ устройств ROM файловаЯ система доступна только длЯ чтениЯ.

„лЯ устройств флэш-памЯти существуют ограничениЯ на запись файлов. ‚ы можете только дозаписывать файл. Љроме того, не обновлЯетсЯ времЯ последнего доступа к файлу. ‚ настоЯщий момент эти ограничениЯ распространЯютсЯ даже на SRAM устройства.

‚осстановление свободного пространства

Њенеджер Efsys.* хранит каталоги и файлы, используЯ свЯзные (свЯзные - имеющие прЯмые/обратные указатели) списки структур данных, а не блоки фиксированного размера, как на диске, используемые в традиционных файловых системах с вращающимсЯ носителем. Џри удалении каталога или файла, принадлежащие ему структуры данных помечаютсЯ как удаленные, но не стираютсЯ, чтобы избежать непрерывного стираниЯ и перезаписи (и тем самым потерь времени на эти операции).

‘о временем свободное место закончитсЯ, и менеджеру файловой системы придетсЯ выполнить восстановление свободного пространства (иногда эту операцию называют еще "уборка мусора"). ‚о времЯ этой процедуры Efsys.* восстанавливает свободное место, занимаемое удаленными файлами и каталогами. „лЯ проведениЯ этой операции менеджеру файловой системы требуетсЯ хотЯ бы один свободный блок. “тилита mkffs автоматически резервирует длЯ этой цели один блок при создании файловой системы.

‘жатие и распаковка

Њенеджер Efsys.* поддерживает распаковку, что увеличивает объем данных, который может хранитьсЯ на носителе. ђаспаковка выполнЯетсЯ менеджером файловой системы длЯ приложений прозрачно.

„лЯ этого файлы должны быть, перед запуском утилиты mkffs, предварительно сжаты с помощью утилиты bpe. …сли же копировать сжатый файл в уже созданную файловую систему флэш, то он останетсЯ сжатым и при чтении.

„оступ к файлам

…сли запретить расширениЯ POSIX, то владельцем файлов всегда будет считатьсЯ root, а биты режима всегда будут установлены в rwx. Љоманды chgrp, chmod и chown в этом случае не будут работать.

Њонтирование

Њожет производитьсЯ только при инициализации разделов или при запуске менеджера файловой системы.

„оступ на низком уровне

Џри запуске Efsys.*, он создает длЯ каждого устройства памЯти специальный файл в каталоге /dev. ‚ системе с двумЯ устройствами памЯти Efsys.* создаст файлы /dev/skt1 и /dev/skt2. ‘пециальные устройства игнорируют разбиение на разделы, позволЯЯ доступ к носителЯм на низком уровне.

„оступ к разделу, содержащему образ файловой системы, возможен только на низком уровне (как к "сырому" устройству). „лЯ каждого такого раздела Efsys.* создает специальный файл вида /dev/sktXimgY, где X - это номер гнезда (socket), а Y - номер раздела на этом носителе.

”айловаЯ система NFS

Џервоначально разработаннаЯ компанией Sun Microsystems, NFS (Network File System - ‘етеваЯ ”айловаЯ ‘истема) ЯвлЯетсЯ TCP/IP приложением, которое с тех пор было реализовано на большинстве DOS и UNIX систем. …го реализациЯ в QNX не заменима длЯ прозрачного доступа к файловым системам других Ћ‘, поддерживающих NFS.

QNX изначально поддерживает сетевые файловые системы. €спользовать NFS необходимо только длЯ доступа к не-QNX NFS файловым системам, либо если вы хотите открыть NFS-клиентам доступ к файлам QNX.

NFS позволЯет отображать удаленные файловые системы - полностью или частично - в локальное пространство имен. Љаталоги на удаленной системе выглЯдЯт как часть локальной файловой системы, и все утилиты работы с файлами (ls, cp и mv) работают с удаленными файлами так же, как и с локальными.

‚ QNX 4 длЯ NFS требуетсЯ менеджер Socket, который поддерживает сетевые протоколы TCP/IP. ‡аметьте, что его "облегченный" вариант, Socklet, может использоватьсЯ, если не нужна NFS.

”айловаЯ система SMB

SMBfsys реализует протокол SMB (Server Message Block) совместного использованиЯ файлов, который используетсЯ различными серверами, такими как Windows NT, Windows 95, Windows for Workgroups, LAN Manager, Samba. SMBfsys обеспечивает QNX-клиенту прозрачный доступ к удаленным дискам таких серверов.

SMBfsys реализует этот протокол, используЯ только NetBIOS поверх TCP/IP, не NetBEUI. ‘оответственно, необходимо, чтобы TCP/IP был установлен, как на QNX-машине, так и на удаленном сервере. Џосле того, как запущен SMBfsys и смонтирован удаленный сервер, файловаЯ система сервера поЯвлЯетсЯ в локальном дереве каталог.

Њенеджер устройств

ќта глава охватывает следующие темы:

введение;
обслуживание устройств;
режим редактируемого ввода;
режим необрабатываемого ввода;
драйверы устройств;
консоль QNX;
последовательные устройства;
параллельные устройства;
производительность подсистемы устройств.

‚ведение

Њенеджер устройств QNX (Dev) ЯвлЯетсЯ интерфейсом между процессами и терминальными устройствами. ќти терминальные устройства располагаютсЯ в пространстве имен ввода/вывода с именами, начинающимисЯ с /dev. Ќапример, консольное устройство в QNX будет иметь имЯ:

/dev/con1

Ћбслуживание устройств

Џрограммы в QNX получают доступ к терминальным устройствам, используЯ стандартные функции open(), close(), read() и write(). „лЯ процесса QNX терминальное (оконечное) устройство представлЯетсЯ двунаправленным потоком байт, который может считыватьсЯ и записыватьсЯ процессом.

Њенеджер устройств регулирует поток данных между приложением и устройством. Dev выполнЯет некоторую обработку этих данных в соответствии с параметрами управлЯющей структуры терминала (называемой termios), котораЯ существует длЯ каждого устройства. Џользователи могут запрашивать и/или изменЯть эти параметры с помощью утилиты stty; программы могут использовать функции tcgetattr() и tcsetattr().

Џараметры структуры termios управлЯют функциональностью низкого уровнЯ, такой как:

параметры линии (включаЯ скорость передачи, контроль четности, стоп-биты, биты данных);
эхо-вывод символов;
редактирование строки ввода;
распознавание и реакциЯ на команду "Break" и зависаниЯ;
программное и аппаратное управление потоком данных;
преобразование выводимых символов.

Њенеджер устройств также предоставлЯет набор дополнительных услуг, доступных процессам длЯ работы с терминальным устройством. ‚ следующей таблице приведены некоторые из этих услуг.

Џроцесс может: ”ункциЯ ‘и:

‚ыполнЯть операции чтениЯ с контролем времени dev_read() или read() и tcsetattr()
Џолучать асинхронное извещение о доступных данных dev_arm()

Ќа одном или более устройствах ввода ждать полного завершениЯ операции вывода tcdrain()

Џосылать команду Break по каналу свЯзи tcsendbreak()

ђазорвать соединение tcdropline()

‚ставить входные данные dev_insert_chars()

‚ыполнЯть неблокирующиесЯ чтение и запись open() и fcntl() (O_NONBLOCK mode)

Џроцесс может:	”ункциЯ ‘и:
‚ыполнЯть операции чтениЯ с контролем времени	dev_read() или read() и tcsetattr()
Џолучать асинхронное извещение о доступных данных	dev_arm()
Ќа одном или более устройствах ввода ждать полного завершениЯ операции вывода	tcdrain()
Џосылать команду Break по каналу свЯзи	tcsendbreak()
ђазорвать соединение	tcdropline()
‚ставить входные данные	dev_insert_chars()
‚ыполнЯть неблокирующиесЯ чтение и запись	open() и fcntl() (O_NONBLOCK mode)

ђежим редактируемого ввода

Ќаиболее важный режим работы устройства управлЯетсЯ битом ICANON в управлЯющей структуре termios. …сли этот управлЯющий бит установлен, то Њенеджер устройств выполнЯет функции редактированиЯ строки длЯ принимаемых символов. ’аким образом, только когда строка "введена" - обычно, когда получен символ перевода каретки (CR), - данные станут доступны длЯ прикладных процессов. ’акой режим работы называетсЯ редактируемым - от английского edited. ќтот режим еще называют canonical (каноническим) и иногда cooked (приготовительным).

Ѓольшинство неполноэкранных приложений выполнЯютсЯ в редактируемом режиме. ’ипичным примером ЯвлЯетсЯ командный интерпретатор (Shell).

‘ледующаЯ таблица показывает, как Dev обрабатывает некоторые специальные управлЯющие символы, если соответствующие параметры установлены в структуре termios.

Dev выполнит: Љогда получит символ:

‘двиг курсора на один символ влево LEFT

‘двиг курсора на один символ вправо RIGHT

‘двиг курсора в начало строки HOME
‘двиг курсора в конец строки END

“даление символа слева от курсора ERASE

“даление символа в текущей позиции курсора DEL

“даление всей строки ввода KILL

‘тирание текущей строки и восстановление предыдущей UP

‘тирание текущей строки и восстановление следующей DOWN

Џереключение между режимами вставки и замены INS

`Dev` выполнит:	Љогда получит символ:
‘двиг курсора на один символ влево	LEFT
‘двиг курсора на один символ вправо	RIGHT
‘двиг курсора в начало строки	HOME
‘двиг курсора в конец строки	END
“даление символа слева от курсора	ERASE
“даление символа в текущей позиции курсора	DEL
“даление всей строки ввода	KILL
‘тирание текущей строки и восстановление предыдущей	UP
‘тирание текущей строки и восстановление следующей	DOWN
Џереключение между режимами вставки и замены	INS

‘имволы редактированиЯ строки отличаютсЯ длЯ различных терминалов. Џри запуске консоли QNX всегда определен полный набор редактирующих символов.

…сли терминал подключен к QNX через последовательный канал, необходимо установить редактирующие символы, которые будут использоватьсЯ длЯ данного конкретного терминала. „лЯ этого вы можете использовать утилиту stty. Ќапример, если терминал VT100 подключен к последовательному порту (/dev/ser1), то следующаЯ команда извлечет соответствующие редактирующие символы из базы данных terminfo и применит их к /dev/ser1:

stty term=vt100 </dev/ser1

…сли же к этому последовательному порту подключен модем, длЯ свЯзи с другой QNX системой с помощью утилиты qtalk, редактирующие символы следует установить так:

stty term=qnx </dev/ser1

ђежим необрабатываемого ввода

Љогда бит ICANON не установлен, то говорЯт, что устройство находитсЯ в необрабатываемом ("сыром", английский термин raw) режиме. ‚ этом режиме не производитсЯ никакое редактирование ввода, а все получаемые данные немедленно становЯтсЯ доступными длЯ QNX-процессов.

Џолноэкранные программы и коммуникационные программы ЯвлЯютсЯ примерами приложений, которые переводЯт устройство в сырой режим.

Џри чтении из сырого устройства приложение может задать условиЯ, при которых будет удовлетворен запрос на ввод данных. Љритерии, используемые при приеме сырых данных, базируютсЯ на двух параметрах структуры termios: MIN и TIME. Џриложение может определить еще один дополнительный параметр при вызове функции dev_read(). ќтот параметр, TIMEOUT, используетсЯ при написании протоколов или приложений реального времени. “чтите, что длЯ функции read() TIMEOUT всегда 0.

Љогда процесс запрашивает ввод n байт данных, эти три параметра определЯют, когда должен быть удовлетворен запрос:

MIN TIME TIMEOUT Ћписание:
0 0 0 ‚ернуть немедленно столько байт, сколько доступно в данный момент (но не более n байт)

M 0 0 ‚ернуть не более n байт только тогда, когда доступны, по меньшей мере, M байт

0 T 0 ‚ернуть не более n байт только тогда, когда доступен хотЯ бы один байт либо истекло T x .1 секунд.

M T 0 ‚ернуть не более n байт только тогда, либо когда будут доступны M байт, либо будет принЯт хотЯ бы один байт и интервал между любыми последовательно принЯтыми символами превысил T x .1 секунд.

0 0 t ‡арезервировано.

M 0 t ‚ернуть не более n байт только тогда, когда доступны M байт либо истекло t x .1 секунд.

0 T t ‡арезервировано.
M T t ‚ернуть не более n байт только тогда, когда доступны M байт, либо истекло t x .1 секунд и не был получен ни один символ, либо был принЯт хотЯ бы один байт и интервал между любыми последовательно принЯтыми символами превысил T x .1 секунд.

MIN	TIME	TIMEOUT	Ћписание:
`0`	`0`	`0`	‚ернуть немедленно столько байт, сколько доступно в данный момент (но не более n байт)
`M`	`0`	`0`	‚ернуть не более n байт только тогда, когда доступны, по меньшей мере, `M` байт
`0`	`T`	`0`	‚ернуть не более n байт только тогда, когда доступен хотЯ бы один байт либо истекло `T` x .1 секунд.
`M`	`T`	`0`	‚ернуть не более n байт только тогда, либо когда будут доступны `M` байт, либо будет принЯт хотЯ бы один байт и интервал между любыми последовательно принЯтыми символами превысил `T` x .1 секунд.
`0`	`0`	`t`	‡арезервировано.
`M`	`0`	`t`	‚ернуть не более n байт только тогда, когда доступны `M` байт либо истекло `t` x .1 секунд.
`0`	`T`	`t`	‡арезервировано.
`M`	`T`	`t`	‚ернуть не более n байт только тогда, когда доступны `M` байт, либо истекло `t` x .1 секунд и не был получен ни один символ, либо был принЯт хотЯ бы один байт и интервал между любыми последовательно принЯтыми символами превысил `T` x .1 секунд.

„райверы устройств

Ќа рисунке показана типичнаЯ подсистема устройств в QNX.

Figure showing a typical QNX device subsystem

Њенеджер устройств (Dev) организует обмен данными между устройствами и прикладными программами. Ђппаратный интерфейс управлЯетсЯ индивидуальными процессами драйверами. Dev, длЯ каждого из устройств, обмениваетсЯ данными с драйверами через очереди в разделЯемой памЯти.

€спользование разделЯемой памЯти требует, чтобы Dev и драйверы находились на одном и том же физическом компьютере, преимуществом же ЯвлЯетсЯ повышеннаЯ производительность.

„лЯ каждого терминального устройства используютсЯ три очереди. ЉаждаЯ очередь реализована на основе механизма "первый вошел - первый вышел". Љаждой очереди также соответствует своЯ управлЯющаЯ структура.

Џринимаемые данные помещаютсЯ драйвером в очередь сырого ввода, и Dev извлекает их, только когда прикладные программы запрашивают данные. Ћбработчики прерываний внутри драйверов обычно вызывают проверенную библиотечную процедуру внутри Dev длЯ добавлениЯ данных в эту очередь - это обеспечивает единообразный порЯдок ввода и существенно минимизирует ответственность драйвера.

Dev помещает выводимые данные в очередь вывода; данные извлекаютсЯ драйвером по мере того, как символы физически передаютсЯ устройству. Dev вызывает проверенную процедуру внутри драйвера каждый раз, когда добавлЯютсЯ новые данные, таким образом он "подталкивает" драйвер к работе (в случае, если он не был занЯт). ЃлагодарЯ использованию очередей вывода Dev реализует буферизованную запись (write-behind) длЯ всех терминальных устройств. ’олько когда буферы вывода заполнены, Dev вызывает блокирование процесса при записи.

ђедактируемаЯ очередь полностью управлЯетсЯ Dev и используетсЯ при вводе данных в редактируемом режиме. ђазмер этой очереди определЯет максимальный размер строки редактируемого ввода длЯ конкретного устройства.

ђазмеры всех этих очередей могут конфигурироватьсЯ системным администратором; единственное ограничение состоит в том, что общий суммарный размер всех трех очередей не может превышать 64K. ‡начений по умолчанию обычно более чем достаточно длЯ большинства аппаратных конфигураций, но вы можете "настраивать" их, либо длЯ уменьшениЯ общей потребности системы в памЯти, либо в случае нестандартных аппаратных конфигураций.

“правление устройствами

„райверы устройств просто добавлЯют получаемые данные в очередь сырого ввода или извлекают и передают данные из очереди вывода. Dev решает, когда вывод должен быть приостановлен, должно ли быть "эхо" принимаемых данных и т.д.

—тобы обеспечить хорошую реакцию на входные событиЯ, Dev должен выполнЯтьсЯ с достаточно высоким приоритетом. Dev обычно мало загружен работой, поэтому он редко снижает общую производительность системы. ‘ами драйверы, как и любые другие процессы в QNX, могут выполнЯтьсЯ с различными приоритетами в зависимости от характера обслуживаемых устройств.

‘ами драйверы, как и любые другие процессы в QNX, могут выполнЯтьсЯ с различными приоритетами в зависимости от характера обслуживаемых устройств.

“правление устройствами на низком уровне выполнЯетсЯ через дальний вызов входной точки ioctl внутри каждого драйвера. Ћбщий набор ioctl команд поддерживаетсЯ непосредственно Dev. ‘пецифические длЯ устройства ioctl команды могут быть посланы QNX процессами драйверу через функцию ‘и qnx_ioctl().

Љонсоль QNX

‘истемные консоли поддерживаютсЯ драйвером Dev.con. ќкран, адаптер дисплеЯ и системнаЯ клавиатура - вместе называютсЯ консолью.

QNX позволЯет параллельное выполнение множества сессий на консолЯх посредством виртуальных консолей. „райвер Dev.con обычно поддерживает более одного набора очередей ввода/вывода к Dev, которые доступны пользовательским процессам как множество терминальных устройств с именами вида /dev/con1, /dev/con2 и т.д. ‘ точки зрениЯ приложениЯ, это "настоЯщие" доступные консоли.

Љонечно, существует только один физический экран и клавиатура, и поэтому только одна из этих виртуальных консолей действительно показываетсЯ в каждый момент времени. Љлавиатура "подключена" к той виртуальной консоли, котораЯ видима в текущий момент.

”ункции, специфичные длЯ консоли

‚ дополнение к реализации стандартного терминала QNX (описан в ђуководстве пользователЯ), драйвер консоли также обеспечивает набор специфических длЯ консоли функций, которые позволЯют приложениЯм непосредственно взаимодействовать с драйвером консоли путем обмена сообщениЯми. ‘вЯзь устанавливаетсЯ вызовом функции ‘и console_open(). Џосле того как свЯзь установлена, процесс имеет доступ к следующим возможностЯм:

Џроцесс может: —ерез функцию ‘и:
—итать непосредственно с экрана консоли console_read()

Џисать непосредственно на экран консоли console_write()

Џолучать асинхронное извещение о важных событиЯх (например, изменение положениЯ курсора, размера дисплеЯ, переключение консоли и т.д.) console_arm()

“правлЯть размерами консоли console_size()

Џереключать видимую консоль console_active()

Џроцесс может:	—ерез функцию ‘и:
—итать непосредственно с экрана консоли	console_read()
Џисать непосредственно на экран консоли	console_write()
Џолучать асинхронное извещение о важных событиЯх (например, изменение положениЯ курсора, размера дисплеЯ, переключение консоли и т.д.)	console_arm()
“правлЯть размерами консоли	console_size()
Џереключать видимую консоль	console_active()

„райвер консоли QNX выполнЯетсЯ как нормальный процесс QNX. ‚водимые с клавиатуры символы помещаютсЯ обработчиком прерываниЯ клавиатуры непосредственно в очередь ввода. ‚ыводимые данные отображаютсЯ Dev.con в то времЯ, когда он выполнЯетсЯ как процесс.

Џоследовательные устройства

Џоследовательные каналы свЯзи обслуживаютсЯ драйвером Dev.ser. ќтот драйвер может обслуживать более одного физического канала; он обеспечивает терминальные устройства с именами вида /dev/ser1, /dev/ser2 и т.д.

Џри запуске Dev.ser вы можете задать аргументы командной строки, которые определЯют, какие - и сколько - последовательные порты установлены. —тобы увидеть доступные последовательные порты, используйте утилиту ls:

ls /dev/ser*

Dev.ser ЯвлЯетсЯ примером управлЯемого прерываниЯми сервера ввода/вывода. Џосле инициализации оборудованиЯ сам процесс переходит в состоЯние ожиданиЯ ("засыпает"). ЏрерываниЯ помещают входные данные непосредственно в очередь ввода. Џервый выводимый символ передаетсЯ устройству, когда Dev "подталкивает" драйвер. Џоследующие символы передаютсЯ при обработке соответствующего прерываниЯ.

Џараллельные устройства

Џараллельные порты принтера обслуживаютсЯ драйвером Dev.par. Џри запуске Dev.par вы можете задать аргумент командной строки, который определЯет, какой последовательный порт установлен. —тобы увидеть, доступен ли последовательный порт, используйте утилиту ls:

ls /dev/par*

Dev.par ЯвлЯетсЯ только выводЯщим драйвером, поэтому у него нет очередей ввода. ‚ы можете конфигурировать размер буфера вывода с помощью аргументов командной строки при запуске Dev.par. Ѓуфер вывода может быть сделан очень большим, если вы хотите обеспечить программный буфер печати.

Dev.par ЯвлЯетсЯ примером сервера ввода/вывода, не использующим прерываниЯ. ќтот процесс нормально находитсЯ в состоЯнии RECEIVE-блокирован, ожидаЯ поЯвлениЯ данных в очереди вывода и "толчка" от Dev. Љогда доступны данные длЯ вывода на печать, Dev.par выполнЯетсЯ в цикле работа-ожидание (с относительно низким адаптивным приоритетом), ожидаЯ, когда символы будут принЯты принтером. ’акой низкоприоритетный цикл работа-ожидание не влиЯет на общую производительность системы и, в то же времЯ, достигает максимально возможную пропускную способность к параллельному устройству.

Џроизводительность подсистемы устройств

Џоток событий внутри подсистемы устройств сконструирован так, чтобы минимизировать избыточность и достичь максимальной пропускной способности, когда устройство работает в сыром режиме. ‘ этой целью используютсЯ следующие правила:

Ћбработчики прерываний помещают принЯтые данные непосредственно в очереди в памЯти. ’олько при наличии ждущего запроса на чтение и при условии, что этот запрос может быть удовлетворен, обработчик прерываниЯ инициирует выполнение Dev. ‚о всех остальных случаЯх выполнЯетсЯ просто возврат из прерываниЯ. Ѓолее того, если Dev уже выполнЯетсЯ, то никакой диспетчеризации не производитсЯ.
Љогда запрос на чтение удовлетворен, Dev копирует данные в приложение непосредственно из буфера сырого ввода. Љак результат, данные копируютсЯ только один раз.

ќти правила - в сочетании с исключительно маленькими задержками прерываниЯ и диспетчеризации в QNX - обеспечивают очень эффективную модель ввода.

Њенеджер сети

ќта глава охватывает следующие темы:

введение;
обЯзанности Њенеджера сети;
интерфейс ЊикроЯдро/Њенеджер сети;
сетевые драйверы;
идентификаторы узла и сети;
выбор сети;
сеть TCP/IP.

‚ведение

Њенеджер сети (Net) дает пользователЯм QNX прозрачное расширение мощных возможностей механизма передачи сообщений. ‚заимодействуЯ непосредственно с ЊикроЯдром, Њенеджер сети усиливает механизм IPC на основе обмена сообщениЯми, передаваЯ сообщениЯ на удаленные компьютеры. Љроме того, Њенеджер сети обеспечивает:

повышенную пропускную способность за счет балансировки нагрузки;
отказоустойчивость за счет резервированиЯ соединений;
функции моста между QNX сетЯми.

ЋбЯзанности Њенеджера сети

Њенеджер сети отвечает за распространение примитивов передачи сообщений QNX в пределах локальной сети. ‘тандартные примитивы передачи сообщений используютсЯ без изменениЯ длЯ свЯзи с удаленным компьютером. „ругими словами, не существует особых "сетевых" Send(), Receive() или Reply().

Ќезависимый модуль

Њенеджер сети не должен быть обЯзательно встроен в образ операционной системы. Ћн может быть запущен и остановлен в любое времЯ, чтобы обеспечить или удалить сетевые возможности передачи сообщений.

Џри запуске Њенеджер сети регистрируетсЯ у Њенеджера процессов и џдра. ќто активизирует код внутри последних, который взаимодействует с Њенеджером сети. ќто означает, что передача сообщений по сети и создание удаленных процессов - это не просто добавлЯемый поверх операционной системы слой. ‘етевые возможности интегрированы в самую сердцевину примитивов передачи сообщений и управлениЯ процессами.

’акаЯ глубокаЯ интеграциЯ на самом нижнем уровне обеспечивает QNX сетевую прозрачность и делает ее полностью распределенной операционной системой. Џоскольку приложениЯ запрашивают и получают доступ ко всем обслуживающим программам посредством сообщений и Њенеджер сети обеспечивает прозрачное прохождение сообщений по сети, то узлы QNX функционируют вместе как единый логический компьютер.

Џоскольку Њенеджер сети и ЊикроЯдро отделены друг от друга, ЊикроЯдро может достичь независимости от сетевого оборудованиЯ, а компьютеры, не подключенные к сети, могут выиграть за счет меньшего объема кода.

€нтерфейс ЊикроЯдро/Њенеджер сети

ЊикроЯдро и Њенеджер процессов взаимодействуют с Њенеджером сети через специальную неблокирующую очередь в памЯти. ќта очередь представлЯет собой список передач, которые должен выполнить Њенеджер сети. ќлементы очереди содержат всю информацию о конкретной операции (например, Send(), Reply(), создание виртуального канала (VC), передача удаленного сигнала и т.д.).

„ругим ресурсом операционной системы, используемым длЯ обеспечениЯ прозрачной передачи сообщений, ЯвлЯетсЯ буфер виртуального канала. ‚ыделЯемый при создании VC процессом, буфер виртуального канала хранит данные до завершениЯ операции передачи сообщениЯ на другой узел.

Ќиже приведены диаграммы, иллюстрирующие процесс посылки и приема удаленных сообщений.

Џосылка сообщениЯ на удаленный узел

fig: i/sendrmot.gif

Џроцесс вызывает Send() или Reply() к удаленному узлу.

‚ случае вызова Send() или Reply() к удаленному узлу, имеют место следующие событиЯ:

Џроцесс вызывает Send() или Reply(), и ЊикроЯдро копирует данные из области данных процесса в буфер виртуального канала.
ЊикроЯдро добавлЯет в очередь Њенеджера сети элемент, содержащий идентификаторы отправителЯ, удаленного получателЯ и указатель на данные в буфере виртуального канала. …сли перед этим очередь была пуста, то Њенеджер сети получает прокси, извещающее о том, что поЯвилась новаЯ работа.
Њенеджер сети извлекает элемент из очереди.
Њенеджер сети посылает элемент соответствующему сетевому драйверу.
Њенеджер сети начинает передачу данных по сети и отвечает за доставку.

‚ случае распространениЯ сигнала или созданиЯ VC, Њенеджер процессов, а не ЊикроЯдро, добавлЯет управлЯющий пакет в очередь . Љак и в предыдущем случае, Њенеджер сети передаст пакет по назначению.

Џолучение сообщениЯ с удаленного узла

fig: i/recvrmot.gif

Џроцесс получает удаленный Send() или Reply().

„опустим, что удаленный узел послал сообщение, как описано выше. ‚ этом случае на принимающем узле имеют место следующие событиЯ:

‘етевой драйвер помещает поступившие по сети данные в соответствующий буфер виртуального канала.
‘етевой драйвер информирует Њенеджер сети о том, что прием завершен.
Њенеджер сети использует частный вызов џдра, извещаЯ его о том, что прием завершен.
ЊикроЯдро копирует данные из буфера виртуального канала в буфер процесса (при условии, что он RECEIVE- или REPLY-блокирован на этом виртуальном канале).

‹юбые управлЯющие пакеты, которые получает Њенеджер сети, немедленно переправлЯютсЯ Њенеджеру процессов через стандартный примитив Send(). ќти управлЯющие пакеты используютсЯ длЯ распространениЯ сигналов и созданиЯ виртуальных каналов.

‘етевые драйверы

Џодобно Њенеджеру файловой системы и Њенеджеру устройств, Њенеджер сети не содержит аппаратно-зависимого кода. ќта функциональность обеспечиваетсЯ драйверами сетевых плат. Њенеджер сети может поддерживать одновременно несколько сетевых драйверов. Љаждый драйвер обычно обслуживает одну сетевую плату. ‚ы можете иметь драйверы/платы одного и того же типа или различных типов - например, два драйвера/платы Ethernet или, допустим, драйвер/плату Ethernet и драйвер/плату Arcnet.

€нтерфейс между Њенеджером сети и драйверами реализован через очереди в разделЯемой памЯти. ќтот интерфейс разработан таким образом, чтобы достичь максимально возможной производительности. „райвер определЯет протокол, подходЯщий длЯ данного сетевого носителЯ.

„райвер отвечает за формирование пакетов, организацию последовательности и в случае, когда требуетсЯ гарантированнаЯ доставка данных удаленному узлу, повторную передачу. ’акаЯ архитектура позволЯет QNX легко поддерживать новое сетевое оборудование и протоколы за счет написаниЯ или модификации только сетевого драйвера.

€дентификаторы узла и сети

Љаждый узел в локальной сети идентифицируетсЯ двумЯ числами:

физическим идентификатором (ID) узла (или идентификаторами, если узел имеет более одной сетевой платы);
комбинацией логического ID узла и логического ID сети.

”изический ID узла

”изический ID узла определЯетсЯ оборудованием. ‘етевые платы обмениваютсЯ данными друг с другом, указываЯ физический ID удаленного узла, с которым должна быть установлена свЯзь. ‚ случае сети Ethernet или Token Ring - это большое число, которым неудобно оперировать людЯм и утилитам. Ќапример, каждаЯ плата Ethernet или Token Ring имеет уникальный 48-битный физический ID узла в соответствии со стандартом IEEE 802. Џлаты Arcnet, напротив, имеют всего лишь 8-битный ID.

€спользование физического ID узла имеет существенный недостаток: при соединении некоторых сетей может возникнуть конфликт адресов (особенно в случае Arcnet), или формат адресов может радикально отличатьсЯ.

‹огический ID узла

—тобы обойти названные выше проблемы, возникающие при использовании физических ID узлов, каждому узлу QNX присваиваетсЯ логический ID узла. ‚се процессы QNX оперируют логическими ID узлов. ”изические ID узлов скрыты от процессов, выполнЯющихсЯ в QNX.

€спользование логических ID узлов упрощает лицензирование. ’акже они позволЯют утилитам, которые опрашивают сеть, использовать простой цикл, в котором логический ID узла изменЯетсЯ от 1 до количества узлов.

‘оответствие между логическими и физическими ID узлов устанавливаетсЯ Њенеджером сети. Њенеджер сети, когда поручает драйверу передать данные на другой узел, передает ему физический ID этого узла.

‹огические ID узлов обычно присваиваютсЯ по порЯдку, начинаЯ с 1. Ќапример, узел, имеющий плату Ethernet, может получить логический ID 2, который будет соответствовать физическому ID узла 00:00:c0:46:93:30.

‹огические ID узлов должны быть уникальны длЯ всех узлов во всех соединенных QNX-сетЯх, чтобы сделать возможным функционирование мостов.

‹огический ID сети

ID сети идентифицирует конкретную логическую сеть. ‹огическаЯ сеть - это любое оборудование, которое позволЯет сетевому драйверу непосредственно взаимодействовать с сетевым драйвером на другом узле. ќто может быть как просто последовательный порт, так и сложнаЯ сеть Ethernet с аппаратными мостами.

Ќа следующей диаграмме узел 7 имеет две сетевые платы, которые позволЯют ему иметь доступ к узлам в логических сетЯх 1 и 2. “злы 8 и 9 имеют по три платы, подключающие их к сетЯм 1, 2 и 3.

‡аметьте, что все логические ID узлов уникальны длЯ всех трех логических узлов.

‹огические ID узлов сети назначаютсЯ системным администратором. Ѓолее подробно см. в главе "“становка сети" в книге ђуководстве пользователЯ.

fig: i/multinet.gif

Ќесколько физических сетей сосуществуют посредством логических сетей.

‚ыбор сети

‚ случае, когда узлы соединены более чем одной логической сетью, Њенеджер сети может выбирать, какую из сетей использовать длЯ передачи к удаленному узлу. Ќапример, на приведенном выше рисунке узел 7 может передавать данному узлу 8, используЯ либо сеть 1, либо сеть 2.

ђаспределение нагрузки

ЏропускнаЯ способность сети определЯетсЯ совокупностью скорости компьютера и скорости сети. …сли компьютер может выдавать данные быстрее, чем сеть может их передавать, то сеть будет ограничивать пропускную способность.

Ќапример, два компьютера Pentium, соединенные сетью 10BASE-T Ethernet, будут ограничены 1.1 миллионом байт в секунду, то есть скоростью передачи данных, обеспечиваемой сетевым оборудованием. Ћднако если поместить по две платы Ethernet в каждый из компьютеров и соединить их отдельными кабелЯми, то Њенеджер сети сможет передавать данные по обеим сетЯм одновременно. Џри большой нагрузке это обеспечит увеличение пропускной способности в два раза по сравнению с одной сетью.

Њенеджер сети будет пытатьсЯ сбалансировать нагрузку, выбираЯ сетевой драйвер. ‚ рассмотренном выше примере, если производитсЯ передача с узла 7 на узел 8 по сети 1 и другаЯ передача на узел 8 инициируетсЯ на узле 7, то сеть 2 будет автоматически выбрана длЯ передачи данных.

Ћтказоустойчивость

Љогда узлы соединены двумЯ и более сетЯми, то существует больше чем один возможный путь длЯ свЯзи. ‚ случае отказа платы в одной из сетей, когда свЯзь по этой сети невозможна, Њенеджер сети автоматически перенаправит все данные через другую сеть. ќто происходит на лету без какого-либо вмешательства со стороны прикладных программ и обеспечивает прозрачную отказоустойчивость сети. …сли кабели различных сетей проложены раздельно, то вы также будете защищены от случайного обрыва кабелЯ.

‚ы также можете проектировать системы-"тандемы", в которых две машины соединены высокоскоростной сетью длЯ нормальной работы и другой, более дешевой и медленной сетью (например, по последовательному каналу), котораЯ служит резервом. ‚ случае отказа первой сети соединение не оборветсЯ, хотЯ пропускнаЯ способность, конечно же, снизитсЯ.

Њосты между сетЯми QNX

Њенеджер сети позволЯет любому узлу играть роль моста между двумЯ отдельными сетЯми QNX, базирующимисЯ на стандарте IEEE 802.

’ак как QNX использует одинаковый формат пакетов и протокол на всех IEEE 802 сетЯх, можно создавать мосты между сетЯми Ethernet, Token Ring и FDDI.

„лЯ сетей Arcnet нельзЯ создавать мосты.

ђассмотрим следующую диаграмму, где одной сети принадлежат узлы 17 и 18, а другой - узлы 18 и 19:

fig: i/relay.gif

Њост между двумЯ IEEE 802 QNX сетЯми.

“злы 17 и 18 находЯтсЯ в одной сети, поэтому они могут общатьсЯ друг с другом напрЯмую. ’о же справедливо длЯ узлов 18 и 19. Ќо как могут общатьсЯ узлы 17 и 19?

’ак как обе локальные сети базируютсЯ на IEEE 802, узел 18 автоматически перенаправлЯет пакеты, позволЯЯ узлам 17 и 18 создать виртуальный канал. •отЯ они и не подключены к одной и той же локальной сети, узлы 17 и 19, тем не менее, могут общатьсЯ друг с другом.

‘еть TCP/IP

ЏрисущаЯ QNX поддержка сети реализует локальную сеть на основе собственного частного протокола и оптимизирована длЯ организации интерфейса между QNX компьютерами. Ќо длЯ свЯзи с не-QNX системами, QNX использует ставший промышленным стандартом набор протоколов, называемый TCP/IP.

Џо мере того как €нтернет стал занимать все большее место в нашей повсеместной жизни, протокол, на котором он основан - IP (Internet Protocol) - приобретает все большее значение. „аже если вы не подключаетесь непосредственно к €нтернет как к таковому, IP протокол и свЯзанный с ним инструментарий поистине вездесущи, делаЯ IP стандартом "де-факто" длЯ многих частных сетей.

IP используетсЯ везде, начинаЯ от простых задач (например, удаленный вход в систему (login)) и до более сложных (например, отслеживание биржевых котировок в реальном времени). ‚се больше и больше компаний используют World Wide Web ("всемирную паутину"), основанную на IP, длЯ переписки с клиентами, рекламы и другой деловой активности.

Њенеджер TCP/IP

Њенеджер TCP/IP в QNX происходит из Berkley BSD 4.3, который ЯвлЯетсЯ наиболее распространенным стеком TCP/IP в €нтернет и использован как основа длЯ многих систем.

‘окет API

Ѓиблиотека BSD сокета API была очевидным выбором длЯ QNX 4. ‘окет API ЯвлЯетсЯ стандартным API длЯ программированиЯ TCP/IP в среде Unix. ‚ среде Windows, Winsock API базируетсЯ на BSD сокете API. ќто облегчает переход между ними.

€меютсЯ все процедуры, которые могут понадобитьсЯ прикладным программистам:

accept()
bind()
bindresvport()
connect()
dn_comp()
dn_expand()
endprotoent()
endservent()
gethostbyaddr()
gethostbyname()
getpeername()
getprotobyname()
getprotobynumber()
getprotoent()
getservbyname()
getservent()
getsockname()
getsockopt()
herror()
hstrerror()
htonl()
htons()
h_errlist()
h_errno()
h_nerr()
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
ioctl()
listen()
ntohl()
ntohs()
recv()
recvfrom()
res_init()
res_mkquery()
res_query()
res_querydomain()
res_search()
res_send()
select()
send()
sendto()
setprotoent()
setservent()
setsockopt()
shutdown()
socket()

ђаспространенные утилиты и демоны из €нтернет могут быть легко перенесены или просто перекомпилированы в такой среде. ќто облегчает использование имеющихсЯ готовых наработок.

‚озможность взаимодействиЯ сетей

Џри разработке Њенеджера TCP/IP в QNX в первую очередь принималась во внимание возможность взаимодействиЯ сетей. “читывались как требованиЯ RFC, так и реальные условиЯ. Њенеджер TCP/IP охватывает всю функциональность, предлагаемую RFC 1122. ’акже поддерживаютсЯ протоколы ARP, IP, ICMP, UDP и TCP.

NFS

Network File System (NFS) ЯвлЯетсЯ приложением TCP/IP, реализованным на большинстве DOS и Unix систем. NFS позволЯет отображать удаленные файловые системы - или их части - в локальное пространстве имен. ”айлы на удаленной системе показываютсЯ как часть локальной файловой системы QNX.

‚ QNX 4 длЯ поддержки NFS требуетсЯ менеджер Socket. “чтите, что "облегченнаЯ" версиЯ менеджера, Socklet, может быть использована, если нет необходимости в NFS.

SMB

Server Message Block (SMB), который используетсЯ многими различными серверами, такими как Windows NT, Windows 95, Windows for Workgroups, LAN Manager и Samba. SMBfsys позволЯет клиенту QNX прозрачный доступ к удаленным дискам на таких серверах.

ЋконнаЯ система Photon microGUI

ќта глава охватывает следующие темы:

графическое микроЯдро;
пространство событий;
графические драйверы;
масштабируемые шрифты;
многоЯзычнаЯ поддержка Unicode;
поддержка анимации;
поддержка печати;
менеджер окон Photon;
библиотека виджетов;
резюме.

ѓрафическое микроЯдро

Њногие встроенные системы нуждаютсЯ в пользовательском интерфейсе. „лЯ сложных приложений или длЯ максимальной простоты использованиЯ, естественным выбором ЯвлЯетсЯ графическаЯ оконнаЯ система. Ћднако оконные системы настольных ЏЉ требуют слишком много системных ресурсов длЯ практического применениЯ во встроенных системах, где памЯть и стоимость ограничены.

Џри создании оконной системы Photon microGUI была применена архитектура микроЯдра, успешно воплощеннаЯ в QNX длЯ созданиЯ POSIX Ћ‘ длЯ встроенных систем.

„лЯ успешной реализации Ћ‘ на основе микроЯдра в первую очередь было необходимо добитьсЯ максимальной эффективности IPC (так как от IPC зависит производительность всей Ћ‘). ЃлагодарЯ воплощенному в QNX механизму IPC с низкими издержками, стало возможным создание структуры GUI как графического "микроЯдра", окруженного командой взаимодействующих процессов, общающихсЯ через IPC.

•отЯ на первый взглЯд это может показатьсЯ похожим на построение графической системы по классической схеме клиент/сервер, используемой в X Window System, архитектура Photon отличаетсЯ за счет ограничениЯ функциональности, реализуемой внутри самого графического микроЯдра (или сервера), и распределениЯ большей части функций GUI между взаимодействующими процессами.

ЊикроЯдро Photon выполнЯетсЯ как маленький процесс (размер кода 45K), реализуЯ только несколько фундаментальных примитивов, которые внешние опциональные процессы используют длЯ построениЯ более высокого уровнЯ функциональности оконной системы. Џо иронии, длЯ самого микроЯдра Photon "окна" не существуют. ЊикроЯдро Photon не может также "рисовать" что-либо или управлЯть мышью либо клавиатурой.

„лЯ управлениЯ средой GUI, Photon создает 3-мерное "пространство событий" и ограничиваетсЯ только оперированием регионами и выполнением отсечениЯ и направлениЯ различных событий по мере их прохождениЯ сквозь регионы в этом пространстве событий.

ќта абстракциЯ напоминает концепцию микроЯдра Ћ‘, которое не поддерживает функции ввода/вывода длЯ устройств или файловой системы, а полагаетсЯ на внешние процессы, предоставлЯющие эти услуги высокого уровнЯ. ќто обеспечивает масштабируемость Ћ‘ и GUI, построенных на основе микроЯдра, по размеру и функциональности .

‚ основе "абстракции" микроЯдра Photon лежит воображаемое графическое пространство событий, в которое другие процессы могут помещать регионы. €спользуЯ QNX IPC длЯ свЯзи с микроЯдром Photon, эти процессы управлЯют своими регионами длЯ предоставлениЯ графических сервисных функций высокого уровнЯ или длЯ выполнениЯ функций пользовательских приложений. „лЯ систем с ограниченными ресурсами Photon может масштабироватьсЯ "вниз" за счет удалениЯ процессов, предоставлЯющих сервисные функции, а за счет добавлениЯ процессов, предоставлЯющих сервисные функции, Photon может масштабироватьсЯ "вверх" до полнофункциональной настольной системы.

Џространство событий Photon

"Џространство событий" можно представить как пустое трехмерное пространство с "корневым регионом" на заднем плане. Џользователи как будто "смотрЯт внутрь" этого пространства событий. ЏриложениЯ помещают регионы в трехмерное пространство между корневым регионом и пользователем; они используют эти регионы длЯ генерации и приема различных типов событий в этом пространстве.

Џроцессы, которые выполнЯющие обслуживание драйверов устройств, помещают регионы на передний план пространства событий. ‚ дополнение к управлению пространством событий и корневым регионом, микроЯдро Photon поддерживает экранный указатель (курсор), проецируемый как событиЯ рисованиЯ по направлению к пользователю.

fig: i/regions.gif

Photon использует последовательность регионов, начинаЯ от корневого региона на заднем плане пространства событий до графического региона спереди. ‘обытиЯ рисованиЯ двигаютсЯ от регионов приложений к графическому региону. ‘обытиЯ ввода возникают в регионе курсора/клавиатуры и двигаютсЯ по направлению к корневому региону.

„вигающиесЯ в пространстве событий событиЯ можно представить себе как "фотоны" (что и дало название оконной системе). ‘ами событиЯ состоЯт из набора прЯмоугольных областей и прикрепленных к ним данных. Џо мере движениЯ событий в пространстве событий их прЯмоугольники пересекают регионы, принадлежащие различным процессам (приложениЯм).

Џро событиЯ, которые двигаютсЯ от корневого региона, говорЯт, что они перемещаютсЯ наружу (по направлению к пользователю), в то времЯ как про событиЯ от пользователЯ говорЯт, что они двигаютсЯ внутрь, по направлению к корневому региону.

‚заимодействие между событиЯми и регионами лежит в основе ввода и вывода в Photon. ‘обытиЯ мыши, клавиатуры и светового пера двигаютсЯ от пользователЯ к корневому региону, с "прикрепленным" к ним положением курсора. ‘обытиЯ рисованиЯ возникают в регионах и двигаютсЯ по направлению к региону устройства и пользователю.

ђегионы

Љаждому региону соответствует прЯмоугольнаЯ область, определЯющаЯ его положение в 3-мерном пространстве событий. ђегион также имеет атрибуты, определЯющие, как он взаимодействует с различными классами событий при пересечении ими региона. ‚заимодействие региона с событиЯми определЯетсЯ двумЯ битовыми масками:

маска чувствительности;
маска непрозрачности.

Њаска чувствительности определЯет, должен ли процесс-владелец региона оповещатьсЯ о пересечении региона тем или иным событием. Љаждый бит маски чувствительности определЯет, чувствителен ли регион к определенному типу событий. Љогда событие пересекает регион, длЯ которого установлен бит (равен 1), копиЯ этого событиЯ помещаетсЯ в очередь процесса-владельца региона, извещаЯ приложение о прохождении событиЯ через регион. ’акое извещение никак не изменЯет само событие.

Њаска непрозрачности определЯет прозрачность региона длЯ тех или иных событий. Љаждый бит этой маски определЯет, ЯвлЯетсЯ ли регион прозрачным длЯ определенного типа событиЯ. Џри прохождении событиЯ сквозь "непрозрачный" регион, оно модифицируетсЯ.

ќти две битовые маски могут быть совместно использованы длЯ достижениЯ различных результатов. ‚озможны следующие четыре сочетаниЯ длЯ региона:

‘очетание битовых масок: Ћписание:
Ќечувствительный, прозрачный. Џри прохождении событиЯ через регион, оно не модифицируетсЯ, и владелец региона не извещаетсЯ. Џроцесс-владелец региона просто не интересуетсЯ событием.
Ќечувствительный, непрозрачный. Џри прохождении событиЯ через регион, оно отсекаетсЯ; владелец региона не извещаетсЯ. Ѓольшинство приложений используют такую комбинацию атрибутов длЯ отсечениЯ событий рисованиЯ, чтобы избежать перерисовки окна событиЯми рисованиЯ, исходЯщими от лежащих под ним окон.
—увствительный, прозрачный. ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие продолжит движение в пространстве событий, не изменЯЯсь. Џроцесс, желающий регистрировать прохождение всех событий, может использовать такую комбинацию.
—увствительный, непрозрачный. ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие отсекаетсЯ регионом. “становив такую комбинацию масок, событие может играть роль фильтра или преобразователЯ. Џриложение может обработать любое полученное событие, регенерировать его и при необходимости преобразовать его каким-либо образом при этом, возможно, изменив направление движениЯ или координаты. Ќапример, регион может поглощать событиЯ светового пера, выполнЯть распознавание почерка, а затем генерировать эквивалентные событиЯ нажатиЯ клавиш.

‘очетание битовых масок:	Ћписание:
Ќечувствительный, прозрачный.	Џри прохождении событиЯ через регион, оно не модифицируетсЯ, и владелец региона не извещаетсЯ. Џроцесс-владелец региона просто не интересуетсЯ событием.
Ќечувствительный, непрозрачный.	Џри прохождении событиЯ через регион, оно отсекаетсЯ; владелец региона не извещаетсЯ. Ѓольшинство приложений используют такую комбинацию атрибутов длЯ отсечениЯ событий рисованиЯ, чтобы избежать перерисовки окна событиЯми рисованиЯ, исходЯщими от лежащих под ним окон.
—увствительный, прозрачный.	ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие продолжит движение в пространстве событий, не изменЯЯсь. Џроцесс, желающий регистрировать прохождение всех событий, может использовать такую комбинацию.
—увствительный, непрозрачный.	ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие отсекаетсЯ регионом. “становив такую комбинацию масок, событие может играть роль фильтра или преобразователЯ. Џриложение может обработать любое полученное событие, регенерировать его и при необходимости преобразовать его каким-либо образом при этом, возможно, изменив направление движениЯ или координаты. Ќапример, регион может поглощать событиЯ светового пера, выполнЯть распознавание почерка, а затем генерировать эквивалентные событиЯ нажатиЯ клавиш.

‘обытиЯ

Џодобно регионам, событиЯ могут относитьсЯ к различным классам и иметь различные атрибуты, как, например:

регион происхождениЯ;
тип;
направление;
прикрепленный список прЯмоугольников;
специфические длЯ данного событиЯ данные.

‚ отличие от большинства оконных систем, Photon классифицирует не только ввод (перо, мышь, клавиатура т.д.), но и вывод (запросы рисованиЯ) как событиЯ. ‘обытиЯ могут генерироватьсЯ как регионами, которые процессы поместили в пространство событий, так и самим микроЯдром Photon. Ћпределены следующие типы событий:

нажатиЯ клавиш;
нажатиЯ пера и кнопок мыши;
перемещениЯ пера и мыши;
пересечение границ региона;
событиЯ экспозиции и перекрытиЯ;
событиЯ рисованиЯ;
событиЯ перетаскиваниЯ (drag).

ЏриложениЯ могут либо ждать наступлениЯ событий, и при этом блокироватьсЯ, либо получать асинхронные извещениЯ о приходе событиЯ.

‘писок прЯмоугольников, прикрепленный к событию, может определЯть одну или более прЯмоугольных областей, либо "исходную точку" - единственный прЯмоугольник, у которого координаты верхнего левого и нижнего правого углов совпадают.

Џри пересечении событием непрозрачного региона, прЯмоугольник региона "вырезаетсЯ" из списка прЯмоугольников событиЯ так, что список описывает теперь только видимую часть событиЯ.

‹учше всего иллюстрирует такое отсечение то, как изменЯетсЯ список прЯмоугольников событиЯ рисованиЯ по мере его прохождениЯ сквозь различные регионы. Љогда событие рисованиЯ генерируетсЯ, список прЯмоугольников содержит единственный прЯмоугольник, описывающий породивший событие регион.

…сли событие проходит через регион, который отсекает, например, верхний левый угол событиЯ рисованиЯ, то список прЯмоугольников модифицируетсЯ и будет содержать уже два прЯмоугольника, которые определЯют область, подлежащую отрисовке. ќти результирующие прЯмоугольники называютсЯ "плитки" (tiles).

Џодобным образом, каждый раз при пересечении событием рисованиЯ непрозрачного региона, список прЯмоугольников будет модифицироватьсЯ таким образом, чтобы описывать область, оставшуюсЯ видимой после "вырезаниЯ" непрозрачного региона. Љогда, наконец, событие рисованиЯ достигнет графического драйвера, то список прЯмоугольников будет точно описывать только его видимую часть.

fig: i/clipping.gif

Ќепрозрачные длЯ событиЯ рисованиЯ регионы вырезаютсЯ, в результате чего получаетсЯ область, состоЯщаЯ из прЯмоугольных "плиток".

‚ том случае, если событие рисованиЯ целиком отсекаетсЯ при пересечении с регионом, оно прекращает существование. ќтот механизм "непрозрачных" окон, изменЯющих список прЯмоугольников событиЯ рисованиЯ, обеспечивает правильное отсечение событий рисованиЯ по мере их продвижениЯ от исходного региона (и свЯзанного с ним процесса) к пользователю.

ѓрафические драйверы

ѓрафические драйверы реализованы как процессы, которые помещают регион на переднем плане пространства событий. ђегион графического драйвера чувствителен к событиЯм рисованиЯ, исходЯщим из пространства событий. ѓрафический драйвер получает событиЯ рисованиЯ, когда они пересекают его регион. Њожно представить себе, что регион покрыт "фосфором", который светитсЯ при попадании "фотонов".

’ак как API рисованиЯ Photon накапливает запросы рисованиЯ в пакеты, посылаемые как одно событие рисованиЯ, то каждое событие рисованиЯ, получаемое драйвером, содержит список графических примитивов, подлежащих отрисовке. Љ моменту пересечениЯ событием рисованиЯ региона драйвера, список прЯмоугольников будет содержать также "список отсечений", описывающий, какие именно части списка рисованиЯ должны отображатьсЯ на дисплее. ђабота драйвера заключаетсЯ в том, чтобы преобразовать результирующий список в визуальное отображение на контролируемом графическом оборудовании.

Ћдно из преимуществ использованиЯ списка прЯмоугольников внутри событиЯ состоит в том, что каждое передаваемое драйверу событие представлЯет собой фактически "пакет" запросов. Џо мере совершенствованиЯ графического оборудованиЯ, все больше и больше такой "пакетной" работы может передаватьсЯ непосредственно оборудованию. Њногие видеоадаптеры уже поддерживают аппаратно одну область отсечениЯ, а некоторые поддерживают и несколько областей.

•отЯ использование механизма QNX IPC длЯ передачи запросов рисованиЯ от приложений к графическому драйверу и может показатьсЯ неприемлемой избыточностью, тесты производительности показывают, что производительность в данном варианте не хуже, чем в случае, когда приложениЯ выполнЯют прЯмые вызовы драйвера. Ћдной из причин ЯвлЯетсЯ то, что при использовании событий многочисленные запросы рисованиЯ группируютсЯ, что уменьшает количество посылаемых сообщений по сравнению с количеством прЯмых вызовов драйвера.

Ќесколько графических драйверов

€з того, что графический драйвер просто помещает регион в пространство событий Photon, естественно следует, что одновременно могут быть запущены несколько графических драйверов длЯ нескольких видеоадаптеров, при этом каждый драйвер будет иметь свой, чувствительный к событиЯм рисованиЯ, регион.

ќти регионы могут быть расположены рЯдом, либо перекрывать друг друга произвольным образом. ’ак как Photon наследует от QNX сетевую прозрачность, то приложениЯ или драйверы Photon могут выполнЯтьсЯ на любом узле сети, позволЯЯ, таким образом, дополнительным графическим драйверам расширЯть графическое пространство Photon за счет физических дисплеев других компьютеров в сети. ‡а счет перекрытиЯ регионов графических драйверов, событиЯ рисованиЯ могут дублироватьсЯ на нескольких экранах.

Њногие интересные приложениЯ стали возможны благодарЯ этим свойствам Photon. Ќапример, на заводе оператор с портативным компьютером, имеющим беспроводное подключение к сети, может подойти к рабочей станции и "перетащить" панель управлениЯ с ее монитора на экран портативного компьютера, а затем перейти в цех и осуществлЯть управление.

‚ других приложениЯх встроеннаЯ система без пользовательского интерфейса может проецировать дисплей на любой из узлов сети. Љроме того, становитсЯ возможным коллективный режим работы - несколько человек, находЯсь за своими компьютерами, могут одновременно видеть одни и те же окна и работать с одним и тем же приложением.

‘ точки зрениЯ приложениЯ, это выглЯдит как одно единое графическое пространство. ‘ точки зрениЯ пользователЯ, это выглЯдит как группа соединенных компьютеров, где можно перетаскивать окна с одного физического экрана на другой.

–ветоваЯ модель

„лЯ представлениЯ цветов используетсЯ 24-битнаЯ RGB модель (по 8 бит длЯ красного, зеленого и синего), что обеспечивает 16,777,216 цветов. ‚ зависимости от используемого типа оборудованиЯ, драйвер либо непосредственно отображает 24-битный цвет, либо использует различные варианты смешиваниЯ цветов, чтобы отобразить требуемый цвет на оборудовании, поддерживающем меньшее число цветов.

’ак как графические драйверы используют аппаратно-независимое представление цветов, то приложениЯ могут работать без изменениЯ на различном оборудовании, независимо от того, какую цветовую модель оно поддерживает. ќто позволЯет "перетаскивать" приложениЯ с одного монитора на другой, не задумываЯсь о том, какаЯ цветоваЯ модель аппаратно реализована в каждом конкретном случае.

Њасштабируемые шрифты

‚ дополнение к поддержке растровых шрифтов, Photon также предлагает масштабируемые шрифты. ќти шрифты могут масштабироватьсЯ практически с любым размером точки и использовать технологию сглаживаниЯ (16 оттенков) длЯ четкого и Ясного отображениЯ на экране с любым разрешением.

Њасштабируемые шрифты в Photon поддерживаютсЯ быстродействующим сервером шрифтов, который загружает описаниЯ шрифтов, хранЯщиесЯ в сжатом виде в файлах *.pfr (Portable Font Resource, ресурсы переносимых шрифтов), и затем приводит вид символов в соответствие с любым размером точки и разрешением. ‘тоит отметить, что формат PFR обеспечивает более чем в два раза лучшее сжатие по сравнению с PostScript шрифтами.

Ќаборы шрифтов

Ћсновной латинский набор

Ћсновной латинский (Core Latin) набор шрифтов Photon (latin1.pfr), который охватывает два набора символов стандарта Unicode, Basic Latin (U+0000 - U+007F) и Latin-1 Supplement (U+0080 - U+00FF), включает следующие масштабируемые шрифты:

Dutch;
Dutch Bold;
Dutch Italic;
Dutch Bold Italic;
Swiss;
Swiss Bold;
Swiss Italic;
Swiss Bold Italic;
Courier;
Courier Bold;
Courier Italic;
Courier Bold Italic.

ђасширенный латинский набор

ђасширенный латинский (Extended Latin) набор (latinx.pfr) охватывает наборы символов Unicode Latin Extended-A (U+0100 - U+017F) и Latin Extended-B (U+0180 - U+0217) и включает следующие шрифты:

Dutch;
Dutch Bold;
Dutch Italic (генерируетсЯ алгоритмически);
Dutch Bold Italic (генерируетсЯ алгоритмически);
Swiss;
Swiss Bold;
Swiss Italic (генерируетсЯ алгоритмически);
Swiss Bold Italic (генерируетсЯ алгоритмически).

Џоддерживаемые Языки

€меЯ в своем распорЯжении Ћсновной латинский набор (latin1.pfr), разработчик может поддерживать множество Языков, включаЯ:

„атский;
ѓолландский;
Ђнглийский;
”инский;
”ламандский;
”ранцузский;
Ќемецкий;
ѓавайский;
€сландский;
€ндонезийский;
€рландский;
€тальЯнский;
Ќорвежский;
Џортугальский;
€спанский;
‘уахили;
ведский.

ђасширенный набор (latinx.pfr) позволЯет дополнительно поддерживать:

Ђфриканский;
Ѓаскский;
Љаталонский;
•орватский;
—ешский;
ќсперанто;
ќстонский;
ѓренландский;
‚енгерский;
‹атышский;
‹итовский;
Њальтийский;
Џольский;
ђумынский;
‘ловацкий;
’урецкий;
‚аллийский.

„ополнительные Языковые пакеты

„лЯ Photon предлагаютсЯ несколько дополнительных пакетов длЯ поддержки национальных Языков:

џпонский;
Љитайский;
Љорейский;
Љириллица.

ЊногоЯзычнаЯ поддержка Unicode

Photon разработан с учетом поддержки национальных символов. ‘ледуЯ стандарту Unicode (ISO/IEC 10646), Photon предоставлЯет разработчикам возможность создавать приложениЯ, поддерживающие основные мировые Языки.

Unicode основываетсЯ на наборе символов ASCII, но использует 16-битную кодировку длЯ полной поддержки многоЯзычного текста. Ќет никакой необходимости прибегать к escape-последовательностЯм или управлЯющим кодам длЯ заданиЯ любого символа любого Языка. ‡аметьте, что кодировка Unicode обрабатывает все символы - алфавитные, идеограммы, специальные символы - абсолютно одинаковым образом.

UTF-8 кодировка

€звестнаЯ раньше как UTF-2, UTF-8 (от "8-битнаЯ форма") кодировка определЯет использование символов Unicode в 8-битной среде UNIX.

‚от некоторые основные характеристики UTF-8:

Unicode-символы от U+0000 до U+007E (набор ASCII) отображаютсЯ в UTF-8-байты от 00 до 7E (ASCII-значениЯ);
ASCII-значениЯ не встречаютсЯ иным образом в UTF-8, обеспечиваЯ полную совместимость с файловыми системами, которые анализируют ASCII-байты;
UTF-8 упрощает преобразование в Unicode-текст и из него;
Џервый байт указывает количество байт в многобайтной последовательности, обеспечиваЯ эффективный разбор;
Њожно легко найти начало символа из любого места в потоке байт, так как длЯ этого необходимо перебрать не более четырех байт, а начальный байт легко определить. Ќапример:
```
isInitialByte = ((byte & 0xC0) != 0x80);
```
UTF-8 достаточно компактен, имеЯ в виду количество байт, используемых длЯ кодировки.

‘истемнаЯ библиотека включает рЯд функций преобразованиЯ:

”ункциЯ: Ћписание:

mblen() „лина многобайтной строки в символах

mbtowc() Џреобразовать многобайтный символ в двухбайтный символ

mbstowcs() Џреобразовать многобайтную строку в двухбайтную строку

wctomb() Џреобразовать двухбайтный символ в его многобайтное представление

wcstombs() Џреобразовать строку двухбайтных символов в многобайтную строку

”ункциЯ:	Ћписание:
mblen()	„лина многобайтной строки в символах
mbtowc()	Џреобразовать многобайтный символ в двухбайтный символ
mbstowcs()	Џреобразовать многобайтную строку в двухбайтную строку
wctomb()	Џреобразовать двухбайтный символ в его многобайтное представление
wcstombs()	Џреобразовать строку двухбайтных символов в многобайтную строку

‚ дополнение к перечисленным выше функциЯм, разработчики могут также воспользоватьсЯ собственной библиотекой Photon, функциЯми PxTranslate, которые выполнЯт различные преобразованиЯ наборов символов в/из UTF-8.

Џоддержка анимации

Photon обеспечивает немерцающую анимацию через специальный виджет-контейнер с "двойным буфером" (PtDBContainer), который создает специальный контекст в памЯти длЯ отрисовки изображений.

‚иджет PtDBContainer использует блок разделЯемой памЯти, достаточный длЯ хранениЯ изображениЯ соответствующего размера.

Џоддержка печати

Photon предусматривает встроенную поддержку печати с выводом на различные устройства, включаЯ:

файлы битовых карт;
PostScript;
Hewlett-Packard PCL;
Epson ESC/P2;

Canon;

Lexmark.

Photon также содержит виджет/диалог выбора принтера, облегчаЯ печать из приложений.

Њенеджер окон Photon

„обавление Њенеджера окон превращает Photon в полнофункциональный настольный графический интерфейс (GUI). Њенеджер окон не ЯвлЯетсЯ обЯзательным и может отсутствовать в большинстве встроенных систем. Њенеджер окон позволЯет пользователЯм манипулировать окнами приложений, изменЯЯ их размер, перемещаЯ и минимизируЯ.

Њенеджер окон использует концепцию фильтрации событий. Ћн помещает дополнительные регионы за регионами приложений, на которых "нарисованы" элементы управлениЯ окнами. ’ак как вид и поведение интерфейса определЯютсЯ заменЯемым Њенеджером окон, то можно реализовать различные виды пользовательских интерфейсов.

Ѓиблиотека виджетов

Photon предлагает библиотеку компонентов, называемых виджетами,- объектов, способных, в основном, автоматически управлЯть своим поведением без непосредственного программированиЯ. ‚ результате, завершенное приложение может быть быстро собрано из виджетов, с последующей привЯзкой C-кода к соответствующим callback-функциЯм виджетов. Photon Application Builder (PhAB), который ЯвлЯетсЯ частью системы разработки Photon, поддерживает широкую палитру виджетов в визуальной среде разработки.

Photon предлагает широкий спектр виджетов:

базовые виджеты (например, кнопка);
виджеты-контейнеры (например, окно);
сложные виджеты (например, HTML-виджет).

Ѓазовые виджеты

‚иджет џрлык (`PtLabel`)

fig: i/label.gif

„анный виджет используетсЯ в основном длЯ отображениЯ текстовой информации. ‚иджет PtLabel ЯвлЯетсЯ надклассовым длЯ всех текстовых виджетов, обеспечиваЯ многие настраиваемые атрибуты (например, шрифт, всплывающие баллоны, цвета, бордюр, выравнивание, полЯ и т.д.), которые наследуютсЯ всеми подклассами.

‚иджет Љнопка (`PtButton`)

Љнопки ЯвлЯютсЯ неотъемлемым компонентом любой оконной оболочки. Ћбычно они имеют выпуклый вид, который при нажатии сменЯетсЯ на утопленный, визуально отражаЯ выбор кнопки. ‚ дополнение к визуальному отражению состоЯниЯ, при выборе кнопки автоматически вызываетсЯ определеннаЯ приложением callback-функциЯ.

‚иджеты ’екстовый ввод (`PtText`, `PtMultiText`)

fig: i/text.gif

Photon предлагает два виджета текстового ввода:

простой однострочный (PtText), обычно используемый в формах;
многострочный, с мощными возможностЯми редактированиЯ виджет (PtMultiText), обеспечивающий все возможности редактированиЯ, автоматической прокрутки, поддержку множества шрифтов.

‚иджеты Љнопка с фиксацией (`PtToggleButton`, `PtOnOffButton`)

fig: i/toggle.gif

Љнопки с фиксацией отображают одно из двух возможных состоЯний - включено или выключено. Photon предлагает два различных типа кнопок с фиксацией с различным внешним видом. Љнопки с фиксацией используютсЯ длЯ отображениЯ или ввода информации о состоЯнии какой-либо команды или действиЯ.

ѓрафические виджеты (`PtArc`, `PtPixel`, `PtRectangle`, `PtLine`, `PtPolygon`, `PtEllipse`, `PtBezier`, `PtGrid`)

fig: i/graphic.gif

Photon не испытывает недостатка в графических виджетах. ‘уществуют виджеты длЯ всего, начинаЯ от простых линий и прЯмоугольников и до сложных многосегментных кривых Ѓезье. ѓрафические виджеты имеют атрибуты длЯ цветов, заполнениЯ, толщины линий и много другого.

‚иджет Џолоса прокрутки (`PtScrollbar`)

fig: i/scrollb.gif

„анный виджет используетсЯ длЯ прокрутки изображениЯ в видимой области. Џолоса прокрутки также используетсЯ в составе других виджетов (например, PtList, PtScrollArea) длЯ обеспечениЯ прокрутки.

‚иджет ђазделитель (`PtSeparator`)

fig: i/separate.gif

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

‚иджет „вижок (`PtSlider`)

fig: i/slider.gif

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

‚иджет ’аймер (`PtTimer`)

‚иджет ’аймер существенно упрощает использование таймера. ќтот виджет не отображаетсЯ визуально - он просто определЯет callback-функцию, вызываемую всЯкий раз при срабатывании таймера. Џриложение может устанавливать значение таймера и, по выбору, интервал повторениЯ.

‚иджеты ѓрафическое изображение (`PtBitmap`, `PtLabel`, `PtButton`)

fig: i/bitmap_cards.gif

Photon поддерживает все основные форматы графических файлов, что позволЯет импортировать изображениЯ и показывать их внутри виджетов. Њногие виджеты Photon непосредственно поддерживают отображение графики - наиболее используемыми ЯвлЯютсЯ PtButton, длЯ созданиЯ панелей кнопок, и PtLabel, длЯ показа изображений.

‚иджет €ндикатор хода процесса (`RtProgress`)

fig: i/progress.gif

…сли приложению необходимо выполнить какую-либо длительную операцию (например, загрузить файл), оно может использовать индикатор хода процесса, чтобы показать пользователю, что происходит и, что еще более важно, сколько еще времени займет этот процесс. €ндикатор хода процесса может быть горизонтальным или вертикальным и имеет много настраиваемых атрибутов.

‚иджет ‘ообщение (`PtMessage`)

fig: i/message.gif

‚сплывающие сообщениЯ и предупреждениЯ типичны длЯ оконной среды. Photon предусматривает очень удобный виджет диалога, который показывает сообщение, и до 3 кнопок длЯ ответа пользователЯ. €меетсЯ также полезнаЯ функциЯ вызова модального диалога (PtAskQuestion()), основаннаЯ на данном виджете.

—исловые виджеты (`PtNumericInteger`, `PtNumericFloat`)

fig: i/numericfloat.gif

PtNumericInteger позволЯет пользователю задать целочисленное значение в пределах между установленными минимальной и максимальной величинами. PtNumericFloat позволЯет ввести число с плавающей точкой.

‚иджет PtUpDown (стрелки вверх/вниз) позволЯет пользователю увеличивать или уменьшать число на заданную величину.

‚иджеты-контейнеры

‚иджеты Ћкно и Џиктограмма (`PtWindow`, `PtIcon`)

Ћкна ЯвлЯютсЯ основными контейнерами длЯ приложений. Ћсновные компоненты пользовательского интерфейса (линейки меню, линейки инструментов и т.д.) поЯвлЯютсЯ с виджетом Ћкно. ‚иджет автоматически выполнЯет все необходимые взаимодействиЯ с Њенеджером окон Photon (PWM) - вам требуетсЯ только задать требуемую функциональность.

‚иджеты Џиктограммы тесно свЯзаны с окнами и показываютсЯ в папках Photon Desktop Manager и на панели задач PWM.

‚иджет Џанель (`PtPane`)

fig: i/pane.gif

‚иджеты Џанель ЯвлЯютсЯ простыми виджетами-контейнерами, которые используютсЯ длЯ размещениЯ других виджетов. •отЯ он и ЯвлЯетсЯ родительским виджетом, панель никаким образом не управлЯет дочерними виджетами. Џанели очень удобны длЯ построениЯ форм, обычно встречающихсЯ в окнах диалога.

‚иджет ѓруппа (`PtGroup`)

fig: i/group.gif

‚иджет ѓруппа - это очень мощный виджет, который управлЯет геометрией всех своих дочерних виджетов. Ћн может выравнивать виджеты по горизонтали, по вертикали или в виде матрицы. ѓруппа может быть привЯзана к стороне любого другого контейнера (например, окна) таким образом, чтобы группа автоматически изменЯла размер при изменении размера окна. ‚иджет ѓруппа также предусматривает атрибуты, которые позволЯют задать необходимость растЯгиваниЯ дочерних виджетов при увеличении размеров группы.

‚иджет Ћбласть прокрутки (`PtScrollArea`)

fig: i/scrolla.gif

Ћбласть прокрутки обеспечивает "окно" просмотра содержимого контейнера потенциально большего размера. ‚ы можете поместить любое количество виджетов внутрь области прокрутки, и она автоматически создаст полосы прокрутки в случае, если виджеты выходЯт за границы видимой области. Ћбласти прокрутки могут быть использованы длЯ созданиЯ окна просмотра текстовых файлов, текстовых редакторов, просмотра списков и так далее.

„лЯ быстрой прокрутки дочерних виджетов область прокрутки использует аппаратный блиттер (при условии, что он поддерживаетсЯ графическим драйвером).

‚иджет ”он (`PtBkgd`)

fig: i/bkgd_earth.gif

„анный виджет позволЯет создавать любой фон, начинаЯ от простого перехода цветов до симметрично расположенных текстур. Џрактически любое требование к фону может быть удовлетворено этим виджетом.

‘ложные виджеты

‚иджеты Њеню (`PtMenu`, `PtMenuBar`, `PtMenuButton`)

Photon предусматривает все необходимое длЯ организации меню. ‚иджет PtMenuBar упрощает создание стандартной линейки меню. ‚иджет PtMenu обрабатывает отображение всплывающего меню, нажатие-перемещение-отпускание (мыши), указание и нажатие, ввод с клавиатуры и выбор пунктов меню. ‚иджет PtMenuButton используетсЯ длЯ созданиЯ отдельных пунктов меню.

‚иджет ‘писок (`PtList`)

fig: i/list.gif

„анный виджет управлЯет списком элементов. Ћн предусматривает много различных режимов выбора, включаЯ единичный выбор, множественный выбор и выбор диапазона. ‚иджет ‘писок также поддерживает многостолбцовые списки при использовании виджета PtDivider.

‚иджет ђазворачиваемый список (`PtComboBox`)

fig: i/combobox.gif

ђазворачиваемый список совмещает виджет PtText (длЯ ввода текста) с кнопкой длЯ отображениЯ виджета PtList. Џри выборе пользователем элемента списка, виджет ’екст автоматически обновлЯетсЯ в соответствии с текущим выбором. ђазворачиваемый список очень полезен в длЯ отображениЯ списка в ограниченном пространстве. „иалоги и контейнеры занимают значительно меньше места на экране, что особенно важно длЯ встроенных приложений.

‚иджет „ерево (`PtTree`)

fig: i/tree.gif

‚иджет „ерево напоминает виджет ‘писок - они имеют общих предшественников. Ћсновное отличие состоит в том, что виджет „ерево показывает элементы в виде иерархии. ќлементы, называемые ветвЯми, могут быть развернуты или сжаты; может быть создано любое количество ветвей. „лЯ каждой ветви можно определить свое уникальное графическое изображение.

‚ число приложений Photon, использующих деревьЯ, входЯт: ”айл-Њенеджер (показ каталога), PhAB (иерархиЯ виджетов), vsin (список процессов) и многие другие.

‚иджеты ’ерминал (`PtTty`, `PtTerminal`)

fig: i/ttyterm.gif

ЃлагодарЯ этому виджету есть возможность поместить текстовую консоль в свое приложение. ‚иджет ’ерминал создает текстовый терминал и управлЯет им.

Ѓолее того - он обеспечивает полную функциональность "cut-and-paste" и быстрый вызов справки путем выделениЯ текста внутри виджета.

‚иджет „елитель (`PtDivider`)

fig: i/divider.gif

ќтот виджет осуществлЯет управление дочерними виджетами уникальным образом. …сли поместить два или более виджета внутрь виджета PtDivider, то он автоматически создает небольшие разделители между дочерними виджетами. ЏередвигаЯ эти разделители, пользователь может изменЯть размеры дочерних виджетов. ќто очень удобно, в частности, длЯ созданиЯ списков со столбцами изменЯемой ширины. ”актически, если поместить виджет PtDivider внутрь PtList, это автоматически превратит простой список в список с множественными столбцами изменЯемой ширины.

‚итжеты „елители не ограничиваютсЯ только этикетками или кнопками. ‹юбой виджет может быть помещен внутрь, чтобы создавать рЯдом деревьЯ с изменЯемыми размерами, области прокрутки и так далее.

‚иджет ’ренд (`RtTrend`)

fig: i/trend_fixed.gif

‘истемы реального времени часто требуют отображениЯ графических трендов состоЯниЯ процесса. ‚иджет RtTrend поддерживает отображение нескольких трендов одновременно.

‚иджет €змерительный прибор (`RtMeter`)

fig: i/rtmeter.gif

‚иджет RtMeter имеет вид полукруга с рисками, отмечающими 1/3, 1/2 и 2/3 длины дуги. ‘трелка может перемещатьсЯ с помощью мыши или клавиатуры или программно. Ћднократное нажатие кнопки мыши перемещает стрелку в текущую позицию курсора; при нажатии и последующем перемещении мыши ("drag") стрелка следует за курсором.

„иалог выбора шрифта (`PtFontSel`)

fig: i/fontsel.gif

ќтот виджет читает стандартные файлы конфигурации шрифтов и показывает список доступных шрифтов. Ћн позволЯет выбрать шрифт и стиль (жирный, курсив т.д.) и также указать необходимость использованиЯ технологии сглаживаниЯ (anti-alias).

‚иджет ‚ыбор файла (`PtFileSel`)

fig: i/filesel.gif

‚иджет PtFileSel позволЯет отображать древовидную иерархию файлов, каталогов или произвольных элементов. ‘ помощью этого виджета пользователь может просматривать структуру файловой системы и выбирать требуемый файл или каталог.

„иалог настройки печати (`PtPrintSel`)

fig: i/printsel.gif

‚иджет PtPrintSel позволЯет пользователю выбрать принтер и произвести необходимую настройку параметров печати. Џользователь может задать диапазон страниц длЯ вывода на печать и количество копий.

‚иджет HTML (`PtHtml`)

fig: i/html.gif

€спользование данного виджета облегчает создание собственного средства просмотра документации формата HTML. ‚иджет сам выполнЯет форматирование стандартного HTML-файла и даже автоматически загружает картинки. Ћн обрабатывает прокрутку, изменение размера, практически все требуемые функции.

‘оздание новых виджетов

…сли стандартных виджетов Photon недостаточно, то вы можете легко создать свои собственные новые виджеты! ‚ состав среды разработки Photon входит полнаЯ документациЯ и примеры исходного кода длЯ созданиЯ собственных виджетов. ‚ы можете создавать подклассы существующих виджетов, чтобы обеспечить наследование их функциональности, или создать собственное дерево виджетов.

ђезюме

Photon олицетворЯет новый подход к созданию графического пользовательского интерфейса с использованием микроЯдра и "команды" взаимодействующих процессов, а не монолитный подход, характерный длЯ других оконных систем. ‚ результате Photon демонстрирует уникальные характеристики:

Ќизкие требованиЯ к объему памЯти позволЯют Photon обеспечивать высокий уровень функциональности оконной оболочки в условиЯх, где ранее было возможно только использование графической библиотеки.
Photon обладает очень гибкой, наращиваемой архитектурой, котораЯ позволЯет разработчикам расширЯть возможности графического интерфейса в необходимом длЯ своего приложениЯ направлении.
ЃлагодарЯ гибким возможностЯм кросс-платформенной свЯзи, приложениЯ Photon могут быть использованы практически в любой настольной среде.


Last-modified: Wed, 06 Mar 2002 08:50:13 GMT
Ћцените этот текст:

`qnx/fsys`	локальное имЯ
`company/xyz`	локальное имЯ
`/company/xyz`	глобальное имЯ

`/`	дисковаЯ файловаЯ система (`Fsys`)
`/dev`	система символьных устройств (`Dev`)
`/dev/hd0`	дисковый том без разделов (`Fsys`)

`/dev/ser1`	локальный последовательный порт
`//10/dev/ser1`	последовательный порт в узле 10
`//0/dev/ser1`	локальный последовательный порт
`//20/usr/dtdodge/test`	файл на узле 20