Сопоставление и передача путей между процессами.

             План лекции.

1. Пространство ввода - вывода

2. Префиксы управления вводом – выводом

3. Сетевой корень

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

5. Передача путей между процессами

 

1. Пространство ввода - вывода

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

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

 

2. Префиксы управления вводом – выводом

Когда процесс открывает файл, путь сопоставляется с префиксным деревом, чтобы направить 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

 

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

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

где pid – обрабатывающийся ID администратора ресурса ввода - вывода, и unit - одиночный символ, используется администратором, чтобы выбрать один из нескольких имеющихся префиксов. В слудующем примере, если Fsys обрабатывает 3, и Dev обрабатывает 5, то системное префиксное дерево могло бы выглядеть следующим образом:

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

 

Если вы хотите	используйте
Показать дерево префиксов	Prefix утилиту
Получить префиксное дерево в пределах программы C	qnx_prefix_query() функцию

3. Сетевой корень

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

/dev/ser1                 локальный последовательный порт

//10/dev/ser1           последовательный порт на узле 10

//0/dev/serl                локальный последовательный порт

//20/usr/dtdodge/test файл на узле 20

Обратите внимание, что //0 всегда относится к локальному узлу.

 

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

Когда программа выполняется дистанционно, вы обычно хотите, чтобы любые пути были получены в пределах контекста имени вашего собственного узла. Например, эта команда:

// 5 ls /,

которая вызывает 1s на узле 5, должен возвратить то же самое как:

ls /,

который вызывает 1s , находящийся на вашем узле.

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

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

/usr/home/luc

был бы определен как:

// 9/usr/horoe/luc,

который может интерпретироваться как " определить через префиксное дерево узла 9       

/usr/home/luc.

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

1s /

команда наследовала бы значение корня сети по умолчанию // 9, и Вы вернете эквивалент:

1s // 9/

Аналогично, если Вы должны были ввести команду:

// 5 1s /

Вы запустили бы команду 1s на узле 5, но еще наследуется корень сети значения по умолчанию // 9, так что вы снова должны использовать эквивалент - //9/. В обоих случаях путь определен решено согласно тому же самому пробелу имени пути.

 

Если Вы хотите	используйте
Получить ваш поток	qnx_prefix_getroot() функция C
Установить ваш сетевой корень по умолчанию	qnx_prefix_setroot() функция C
Выполнить программу с новым сетевым корнем по умолчанию	оn утилита

5. Передача путей между процессами

 Если Вы имеете несколько выполняющихся процессов, они могут не иметь сетевого корня по умолчанию - даже если они выполняются на том же самом узле. Например, один процесс, возможно, унаследовал корень сети по умолчанию от родительского процесса в другом месте на сети, или это корень сети по умолчанию, явно отмененный родительским процессом.

При прохождении пути между процессами, чьи сетевые корни могут отличаться (например при передаче файла к спулеру для печати), Вы должны привязать корень сети по умолчанию к пути перед его принятием процессом-получателем. Если вы уверены, что процесс посылающий и процесс получающий имеют один и тот же корень сети по умолчанию (или если путь уже имеет продвижение // node /), то Вы можете опустить этот шаг в процесс

 

Лекция № 11.

Условные префиксы для управления процессами ввода – вывода

     План лекции:

1. Условные префиксы

2. Относительные пути

3. Текущий рабочий каталог

4. Описатели файлов пространства

 

 

1. Условные префиксы

Мы обсудили префиксы, которые отображают управление ресурсами ввода - вывода. Вторая форма префикса, известная как условный префикс , является простой строкой подстановки для согласованного префикса. Префикс условного названия имеет форму:

prefix =replacement-string

 

Например, предположите, что вы работаете на машине, которая не имеет локальной файловой системы (не существует процессов управляющих "/"). Однако, имеется файловая система на другом узле (предположим на 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

2. Относительные пути

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

Обратите внимание, что различия кончаются, когда ваш текущий рабочий каталог начинается с единственной наклонной чертой вправо или стартует с сетевого корня.

 

3. Текущий рабочий каталог

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

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

сd // 18/

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

С другой стороны, эта команда:

сd /

могла бы иметь вторую форму, где корень сети по умолчанию затронет относительную разрешающую способность пути. Например, если ваш корень сети значения по умолчанию был // 9, то ввод cd dev поместит Вас в // 9/dev. Потому что текущий рабочий каталог не начинается с отмены узла, корень сети значения по умолчанию - связан, чтобы создать полностью указанный сетевой путь.

Это действительно не как сложно, как может казаться. Обычно, сетевые корни (//node/) не определены, и все, что вы будете делать будет работой в пределах вашего пространства (определенного вашим сетевым корнем). Большинство вошедших пользователей примут сетевой корень по умолчанию (то есть пространство их собственного узла) и будут работать в пределах той среды.

 

Примечание относительно cd

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

В QNX, однако, cd не изменяет имя пути — кроме свертывания, ссылки. Например:

сd /usr/home/luc/test/ . . / doc

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

Чтобы отобразить полностью определенный сетевой путь, Вы можете использовать fullpath утилиту.

 

4. Описатели файлов пространства

Как только ресурсs ввода - вывода открыт, различный пространства входят в игру. Open() возвращает целое число, упомянутое как дескриптор файла (FD), который используется, чтобы направить все дальнейшие запросы ввода - вывода к администратору.

Обратите внимание, что Sendfd() ядерный запрос используется в пределах библиотечных подпрограмм, чтобы направить запрос.

Описатели файлов пространства, в отличие от пути, является полностью локальным для каждого процесса. Администратор использует комбинацию PID и FD, чтобы идентифицировать управляющую структуру, связанную с предыдущим open(). Эта структура известна как открытый управляющий блок (OCB) и содержится в пределах администратора ввода - вывода.

Следующая диаграмма показывает администратор ввода - вывода, берущий некоторые PID, FD пары и отображающий их к OCB.

Открытый управляющий блок (OCB) содержит активную информацию относительно открытого ресурса. Например, файловая система сохраняет поток, ищут пункт(точку) в пределах файла здесь. Каждый open() создает новый OCB. Поэтому, если процесс открывает тот же самый файл дважды, любые запросы к lseek () использующий однин FD не будет затрагивать другого FD. Это справедливо для одних и тех же процессов, открывающих любой файл.

Следующая диаграмма показывает два процесса, в которых каждый открывает один и тот же самый файл дважды, а другой открывают однажды. Не имеется никакого общедоступного FDS.

Несколько описателей файла в одном или нескольких процессах могут обратиться к одному OCB. Это достигается двумя средствами:

· процесс может использовать dup(), dup2() или fcntl() функции C, чтобы дублировать описатель файла, который обращается к одному OCB.

· когда новый процесс создан с помощью fork(), spawn(), или exec(), все описатели открытого файла по умолчанию наследуются новым процессом;

Эти наследованные описатели относятся к тому же самому OCB как соответствующие описатели файла в родительском процессе.

Когда несколько FD относятся одному OCB, тогда любое изменение в состоянии OCB немедленно будет замечено всеми процессами, которые имеют описатели файла, связанные этим OCB.

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

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

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

 

 

Лекция №12

Аппаратное и программное обеспечение промышленных систем реального времени (ПСРВ)

 

План лекции:

Введение

1. Организация ПСРВ

2. Аппаратная архитектура

3. Стандарты шин

4. Технологии VME и PCI

5. Мезонинные технологии

6. Полевые системы

7. Программное обеспечение ПСРВ

8. Управление производством

 

Введение

 

В эпоху торжества Internet, мультимедиа и пакета BackOffice как-то неловко обращать внимание публики на промышленность. Но нужно. В мире, который не ограничен делопроизводством, торговлей, банковскими операциями, измерительные и управляющие системы живут, а где-то даже побеждают. Эти системы не видны, но именно они обеспечивают движение самолетов на авиалиниях, на них основана работа атомных электростанций, телефонных сетей, автопилотов поточных линий на промышленных предприятиях. С их помощью осуществляется распределение электроэнергии, управление полетом космических аппаратов и работой металлорежущих станков, регулирование микроклимата в зданиях. Полагаться на людей нельзя - и ответственность в критических приложениях перекладывается на автоматику.

Автоматическое управление начиналось с простых релейных схем, но теперь уровень сложности задач предполагает опору на цифровую обработку информации с использованием практически всех современных компьютерных технологий. Динамика развития индустрии промышленных систем отражена в отчете [1], данные которого основаны на опросах потребителей о закупаемых продуктах. Если в 1993 году было упомянуто 45 продуктов, то в 1996 году эта цифра выросла до 74 с основными закупками в трех крупных областях:

 управление процессами и инструментами (33%);

 интерфейс оператор - компьютер (37%);

 двигатели, приводы и управление движением (30%).

В таблице 1 приведены данные о приложениях, которые наиболее интенсивно используются в промышленных системах. Первые три места занимают распределенные системы управления, приложения на основе ПК и электроника для авиационных моторов, суммарно составляя 30% всех затрат в этой области. Другой аспект раскрывается в таблице 2, показывающей процентное распределение покупок по отраслям промышленности. Можно отметить следующие тенденции: увеличивается присутствие ПК в промышленном управлении, а по отраслям растут темпы автоматизации машиностроения; в химическом производстве динамика сохраняется; в нефтепереработке заметно небольшое замедление.

 

Таблица 1. Наиболее популярные продукты для промышленных систем

 

 

Таблица 2. Затраты на автоматизацию по отраслям промышленности

 

⇐ Предыдущая78910111213141516Следующая ⇒

Поделиться: