ТЕЛЕ 2

Операционная система posix. Стандарты операционных систем реального времени. История создания и текущий статус стандарта POSIX

В курсе рассматривается стандарт на мобильный интерфейс операционной системы (POSIX), а также приемы и методы программирования приложений на основе данного стандарта, поясняемые многочисленными примерами. Затрагиваются вопросы программирования многопроцессных систем, взаимодействия приложений в рамках распределенных конфигураций. Обеспечение мобильности (переносимости, портабельности) программного обеспечения (ПО) - задача исключительной важности и сложности; в наше время это обстоятельство едва ли нуждается в пространных обоснованиях Один из общепринятых способов повышения мобильности ПО - стандартизация окружения приложений: предоставляемых программных интерфейсов, утилит и т.п. На уровне системных сервисов подобное окружение описывает стандарт POSIX (Portable Operating System Interface - мобильный интерфейс операционной системы); название предложил известный специалист, основатель Фонда свободного программного обеспечения Ричард Столмэн.

В курсе рассматривается наиболее современная его версия в редакции 2003 г., которую можно назвать "стандартом втройне", а именно: стандартом IEEE Std 1003.1, Техническим стандартом Open Group и, что для нас важнее всего, международным стандартом ISO/IEC 9945. Основная задача настоящего курса состоит в осмыслении приемов и методов использования стандартизованных служебных программ и функций. Не ставилась цель пересказать стандарт, осветив все тонкости реализации ОС, все возможные коды ошибок и т.п. Главное, на наш взгляд, -прочувствовать дух стандарта, научиться мобильным образом применять заложенные в нем возможности. В предположении, что читатель владеет языком С, мы не рассматривали ни его синтаксис, ни хрестоматийные библиотечные функции. Что же касается стандартного командного языка и его интерпретатора, то эта тема изложена довольно подробно, хотя многие практикующие программисты предпочитают пользоваться другими интерпретаторами. Значительное место - и по объему, и по роли - отведено примерам программ. Многие положения стандарта (связанные, скажем, с обработкой ошибочных ситуаций) излагаются не в основном тексте, а в соответствующих примерах Последние по возможности компилировались и выполнялись на нескольких аппаратно-программных платформах, в той или иной степени претендующих на соответствие стандарту POSIX. Тем не менее, недосмотры, конечно, возможны. Мы будем признательны за все замечания и предложения, относящиеся как к курсу в целом, так и к отдельным примерам программ.

История создания и текущий статус стандарта POSIX.

Обеспечение мобильности (переносимости, портабельности) программного обеспечения (ПО) - задача исключительной важности и сложности; в наше время это обстоятельство едва ли нуждается в пространных обоснованиях. Один из общепринятых способов повышения мобильности ПО - стандартизация окружения приложений: предоставляемых программных интерфейсов, утилит и т.п. На уровне системных сервисов подобное окружение описывает стандарт POSIX (Portable Operating System Interface - мобильный интерфейс операционной системы); название предложено известным специалистом, основателем Фонда свободного программного обеспечения Ричардом Столмэном.

Титульная страница.
Выходные данные.
Лекция 1. Основные понятия и идеи стандарта POSIX.
Лекция 2. Язык shell.
Лекция 3. Утилиты и функции, обслуживающие понятие "пользователь".
Лекция 4. Организация файловой системы.
Лекция 5. Файловый ввод/вывод.
Лекция 6. Средства обработки структурированных данных.
Лекция 7. Процессы.
Лекция 8. Средства межпроцессного взаимодействия.
Лекция 9. Общий терминальный интерфейс.
Лекция 10. Опрос характеристик хостов и их использование в приложениях.
Лекция 11. Сетевые средства.
Лекция 12. Время и работа с ним.
Лекция 13. Языково-культурная среда.
Лекция 14. Заключение.
Список литературы.


Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Программирование в стандарте POSIX, часть 1, Галатенко В.А., 2016 - fileskachat.com, быстрое и бесплатное скачивание.

- (IPAEng|ˈpɒzɪks) or Portable Operating System Interface cite web | title = POSIX | url = http://standards.ieee.org/regauth/posix/ | work = Standards | publisher = IEEE] is the collective name of a family of related standards specified by the IEEE … Wikipedia

POSIX - est le nom d une famille de standards définie depuis 1988 par l Institute of Electrical and Electronics Engineers et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardisation des API des logiciels destinés à… … Wikipédia en Français

Posix - est le nom d une famille de standards définie depuis 1988 par l IEEE et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du système d… … Wikipédia en Français

POSIX - es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identidad de la API. El término fue sugerido por Richard Stallman en respuesta a la demanda de la IEEE, que buscaba un nombre fácil de recordar. Una traducción … Wikipedia Español

POSIX - , 1986 im Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen unter Unix. Sowohl Unix Sy … Universal-Lexikon

POSIX - standartai statusas T sritis informatika apibrėžtis Standartų grupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų bei tarnybų. Pirmuosius standartus sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linukso… … Enciklopedinis kompiuterijos žodynas

POSIX - es el acrónimo de Portable Operating System Interface, viniendo la X de UNIX con el significado de la herencia de la API (Se traduciría como Sistema Operativo Portable basado en UNIX). Estos son una familia de estándares de llamadas al sistema… … Enciclopedia Universal

POSIX - (Portable Operating System Interface based on uniX) n. collection of standards for operating systems that are based on Unix (Computers) … English contemporary dictionary

POSIX

Posix - Das Portable Operating System Interface (POSIX [ˈpɒsɪks]) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Applikation und dem… … Deutsch Wikipedia

Книги

  • , Стивен А. Раго, У. Ричард Стивенс. "UNIX. Профессиональное программирование" - это подробнейшее справочное руководство, которое на протяжении 20 лет помогает профессиональным программистам на языке С писать исключительно…
  • UNIX. Профессиональное программирование , Стивенс У. Ричард, Раго Стивен А.. Эта книга заслуженно пользуется популярностью у серьезных программистов во всем мире, поскольку содержит самую важную и практическую информацию об управлении ядрами UNIX и Linux. Без этих…

POSIX (Portable Operating System Interface for Computer Environments - незави­симый от платформы системный интерфейс для компьютерного окружения) - это стандарт IEEE (Institute of Electrical and Electronics Engineers - институт инже­неров по электротехнике и радиоэлектронике), описывающий системные интер-

" В данном контексте под системными командами следует понимать некий набор программ, позволя­ющих управлять вычислительными процессами, например pstat, kill, dir и др.


Интерфейс POSIX___________________________________________________ 305

фейсы для открытых операционных систем, в том числе оболочки, утилиты и ин­струментарии. Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы админист­рирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в Других операционных системах.

Интерфейс POSIX начинался как попытка пропаганды институтом IEEE идей переносимости приложений в UNIX-средах путем разработки абстрактного неза­висимого от платформы стандарта. Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX. 1). Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта, что облегчает перенос приложений в эту систе­му, но UNIX-системой не является ни в каком виде, ибо ее архитектура использу­ет абсолютно иные принципы.

Этот стандарт подробно описывает систему виртуальной памяти (Virtual Memory System, VMS), многозадачность (Multiprocess Executing, МРЕ) и технологию пе­реноса операционных систем (CTOS). Таким образом, на самом деле POSIX пред­ставляет собой множество стандартов POSIX. 1-POSIX. 12. В табл. 9.1 перечисле­ны основные направления, описываемые данными стандартами. Следует также особо отметить, что в POSIX. 1 основным языком описания системных функций API предполагается язык С.

Таблица 9.1. Семейство стандартов POSIX

Стандарт Стандарт ISO Краткое описание

POSIX.0 Нет Введение в стандарт открытых систем. Данный документ

не является стандартом в чистом виде, а представляет собой рекомендации и краткий обзор технологий

POSIX.1 Да Системный интерфейс API (язык С)

POSIX.2 Нет Оболочки и утилиты (одобренные IEEE)

POSIX.3 Нет Тестирование и верификация

POSIX.4 Нет Задачи реального времени и потоки выполнения

POSIX.5 Да Использование языка ADA применительно

к стандарту POSIX. 1

POSIX.6 Нет Системная безопасность

POSIX.7 Нет Администрирование системы

POSIX.8 Нет Сети, «прозрачный» доступ к файлам, абстрактные

сетевые интерфейсы, не зависящие от физических протоколов, вызовы RPC, связь системы с приложениями, зависящими от протокола

POSIX.9 Да Использование языка Fortran, применительно

к стандарту POSIX. 1

POSIX. 10 Нет Super-computing Application Environment Profile (AEP)

POSIX. 11 Нет Обработка транзакций AEP

POSIX. 12 Нет Графический интерфейс пользователя (GUI)


306______________________________ Глава 9. Архитектура операционных систем

Таким образом, программы, написанные с соблюдением данных стандартов, бу­дут одинаково выполняться на всех POSIX-совместимых системах. Однако стан­дарты отчасти носят всего лишь рекомендательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования. Нередко программные системы заявляются как POSIX-совместимые, хотя таковыми их назвать нельзя. Причины кроются в формальном подходе к реализации интерфейса POSIX в различных операционных системах. На рис. 9.1 изображена типовая схема реализации строго соответствующего POSIX приложения.

Рис. 9.1. Схема реализации приложения, строго соответствующего стандарту POSIX

Из рисунка видно, что для взаимодействия с операционной системой программа использует только библиотеки POSIX. 1 и стандартную библиотеку RTL языка С, в которой возможно использование только 110 различных функций, также опи­санных стандартом POSIX. 1.

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

Реализации стандарта POSIX на уровне операционной системы различны. Если UNIX-системы в своем абсолютном большинстве изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым. Однако для его поддержки в операционной системе Windows NT введен специальный модуль API для поддержки стандарта POSIX, работаю­щий на уровне привилегий пользовательских процессов. Данный модуль обес­печивает преобразование и передачу вызовов из пользовательской программы к ядру системы и обратно, работая с ядром через WinAPI. Прочие приложения, написанные с использованием WinAPI, могут передавать информацию POSIX приложениям через стандартные механизмы потоков ввода-вывода stdin и stdout .


Примеры программирования для разных интерфейсов API____________________ 307

Примеры программирования для разных интерфейсов API

Для наглядной демонстрации принципиальных различий интерфейсов API наи­более популярных современных операционных систем для персональных ком­пьютеров рассмотрим простейший пример, в котором необходимо подсчитать количество пробелов в текстовых файлах, имена которых должны указываться в ко­мандной строке. Рассмотрим два варианта программы: для Windows (с использо­ванием WinAPI) и для Linux (POSIX API).

Поскольку нас интересует работа с параллельными задачами, пусть при выполне­нии программы для каждого из перечисленных в командной строке файлов созда­ется свой процесс или поток выполнения (задача), который параллельно с други­ми процессами (потоками) производит работу по подсчету пробелов в «своем» файле. Результатом работы программы будет являться список файлов с подсчи­танным количеством пробелов для каждого.

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

Для того чтобы было удобнее сравнивать эту (листинг 9.1) и следующую (лис­тинг 9.2) программы, а также учитывая, что задача не требует для своего решения оконного интерфейса, в тексте использованы только те вызовы API, которые не затрагивают графический интерфейс. Конечно, нынче редко какое приложение не использует возможностей GUI, но зато в нашем случае сразу можно увидеть раз­ницу в организации параллельной работы запускаемых вычислений.

ПО ) - задача исключительной важности и сложности; в наше время это обстоятельство едва ли нуждается в пространных обоснованиях. Один из общепринятых способов повышения мобильности ПО - стандартизация окружения приложений: предоставляемых программных интерфейсов, утилит и т.п. На уровне системных сервисов подобное окружение описывает стандарт POSIX ( Portable Operating System Interface - мобильный интерфейс операционной системы); название предложено известным специалистом, основателем Фонда свободного программного обеспечения Ричардом Столмэном.

Мы будем рассматривать наиболее современную из доступных версий стандарта POSIX , в редакции 2003 г., которую можно назвать "стандартом втройне", а именно: стандартом IEEE Std 1003.1, Техническим стандартом Open Group и (см. [ 6 ]), что для нас важнее всего, международным стандартом ISO /IEC 9945 (см. [ 1 ] , [ 2 ] , [ 3 ] , [ 4 ]).

История создания этой версии такова. В начале 1998 г. представители трех организаций - Комитета по стандартам мобильных приложений Института инженеров по электротехнике и электронике, Open Group и рабочей группы 15 подкомитета 22 совместного технического комитета 1 (JTC1/SC22/WG15) Международной организации по стандартизации - начали консультации по вопросу слияния и развития курируемых ими стандартов интерфейсов к системным сервисам: IEEE Std 1003.1, IEEE Std 1003.2, Базовых спецификаций от Open Group , ISO /IEC 9945-1, ISO /IEC 9945-2. В сентябре того же года в городе Остин, штат Техас, в офисе корпорации IBM состоялось организационное заседание группы, сформированной для достижения поставленной цели (см. http://www.opengroup.org/austin).

Основополагающим документом для пересмотренного стандарта, первый проект которого был представлен в июле 1999 года, стали Базовые спецификации от Open Group , поскольку они включали положения стандартов IEEE и ISO /IEC. В 2001 году, по завершении подготовительной работы, стандарт содержал следующие четыре части:

  1. основные определения (термины, концепции и интерфейсы, общие для всех частей);
  2. описание прикладного программного C-интерфейса к системным сервисам;
  3. описание интерфейса к системным сервисам на уровне командного языка и служебных программ ;
  4. детальное разъяснение положений стандарта, обоснование принятых решений.

Далее в ISO , IEEE и Open Group с большей или меньшей скоростью (в 2001-2002 гг.) прошло формальное утверждение нового стандарта POSIX . Тем временем накапливались относительно мелкие исправления, учтенные в редакции 2003-го года.

С развитием стандарта расширялась и трактовка термина " POSIX ". Первоначально он относился к документу IEEE Std 1003.1-1988, описывавшему прикладной программный интерфейс ОС класса Unix. После стандартизации интерфейса на уровне командного языка и служебных программ более правильно понимать под словом " POSIX " стандарт в целом, обозначая перечисленные выше части 2 и 3 через POSIX .1 и POSIX .2 в соответствии с нумерацией документов IEEE и ISO /IEC.

Основные идеи стандарта POSIX

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

У каждого интерфейса есть две стороны: вызывающая и вызываемая. Стандарт POSIX ориентирован в первую очередь на вызывающую. Его цель - сделать приложения мобильными на уровне исходного языка . Это значит, в частности, что при переносе C-программ на другую операционную платформу потребуется перекомпиляция. О мобильности выполнимых программ и/или объектных файлов речь не идет.

Стандарт POSIX отнюдь не ограничен рамками Unix-среды . Существуют операционные системы (ОС) "независимого происхождения" (например, системы реального времени ), предоставляющие необходимые сервисы и тем самым поддерживающие выполнение POSIX -совместимых приложений. Можно утверждать, что следование стандарту POSIX облегчает перенос приложений практически на любую сколько-нибудь распространенную операционную платформу. Дополнительные усилия по повышению мобильности, прилагаемые на этапе разработки, безусловно, окупятся.

Определяя интерфейс к системным сервисам, POSIX оставляет за рамками рассмотрения их реализацию. В частности, не различаются системные вызовы и библиотечные функции . Не являются объектом стандартизации средства администрирования , аппаратные ограничения и функции, необходимые только суперпользователю , что еще раз подчеркивает направленность стандарта

Предмет: Операционные системы.
Вопрос: №8

—————————————————————

Принципы построения ОС:

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

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

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

2.) Принцип функциональной избиратель-ности – в ОС выделяется некоторая часть важных модулей, которые должны постоянно находится в оперативной памяти для более эффективной организации вычислительного процесса. Эту часть в ОС называют ядром, так как это – основа системы. При формировании состава ядра приходится учитывать два противоречивых требования. С одной стороны, в состав ядра должны войти наиболее часто используемые системные модули, с другой – количество модулей должно быть таковым, чтобы объем памяти, занимаемый ядром, не был слишком большим. Помимо программных модулей, входящих в состав ядра и постоянно располагающихся в оперативной памяти, может быть много других системных программных модулей, которые получают название транзитных . Транзитные программные модули загружаются в оперативную память только при необходимости и в случае отсутствия свободного пространства могут быть замещены другими транзитными модулями.

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

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

5.) Принцип виртуализации: построение виртуальных ресурсов, их распределение и использование в настоящее время применяется практически в любой ОС. Этот принцип позволяет представить структуру системы в виде определенного набора планировщиков процессов и распредели-телей ресурсов (мониторов) и использовать единую централизованную схему распреде-ления ресурсов.

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

— единообразная по логике работы виртуаль-ная память практически неограниченного объема.

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

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

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

6.) Принцип независимости программ от внешних устройств: этот принцип реализу-ется сейчас в подавляющем большинстве ОС общего применения. Впервые наиболее последовательно данный принцип был реализован в ОС UNIX. Реализован он и в большинстве современных ОС для ПК. Этот принцип заключается в том, что связь программ с конкретными устройствами производится не на уровне трансляции программы, а в период планирования ее исполнения. В результате перекомпиляция при работе программы с новым устройством, на котором располагаются данные, не требуется.

7.) Принцип совместимости: одним из аспектов совместимости является способ-ность ОС выполнять программы, написан-ные для других ОС или для более ранних версий данной ОС, а также для другой аппаратной платформы. Необходимо разделять вопросы двоичной совмести-мости и совместимости на уровне исходных текстов приложений.

Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение на другой ОС. Для этого необходимы совместимость на уровне команд процессора, и совместимость на уровне системных вызовов, и даже на уровне библиотечных вызовов, если они являются динамически связываемыми.

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

Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того чтобы один компьютер выполнял программы другого (например, программу для ПК типа IBM PC желательно выполнить на ПК типа Macintosh фирмы Apple), этот компьютер должен работать с машинными командами, которые ему изначально непо-нятны. В таком случае процессор типа 680×0 (или PowerPC) должен исполнять двоичный код, предназначенный для процессора i80x86. Процессор 80×86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор 680×0 не понимает двоичный код 80×86, поэтому он должен выбрать каждую коман-ду, декодировать ее, чтобы определить, для

чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680×0.

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

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

9.) Принцип мобильности: операционная система относительно легко должна перено-

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

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

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

Введение стандартов POSIX преследовало цель обеспечить переносимость создава-емого программного обеспечения.

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

Обеспечение защиты информации от несанкционированного доступа является обязательной функцией сетевых операци-онных систем.

—————————————————————

Что такое POSIX : платформенно-незави-симый системный интерфейс для компьюте-рного окружения POSIX (Portable Operating System Interface for Computer Environments) – это стандарт IEEE(Institute of Electrical and Electronics Engineers − институт инженеров по электротехнике и радиоэлектронике.), описывающий системные интерфейсы для открытых ОС, в том числе оболочки, утилиты и инструментарии. Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасно-сти, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС. POSIX возник как попытка всемирно известной организации IEEE пропагандировать переносимость прило-жений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта. Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта.

Этот стандарт подробно описывает систему виртуальной памяти VMS (Virtual Memory System,), многозадачность МРЕ (Multi-Process Executing) и технологию переноса операционных систем CTOS (An Operating System produced Convergent Technology …). Таким образом, на самом деле POSIX представляет собой множество стандартов, именуемых POSIX.I –POSIX.12. Следует также особо отметить, что в POSIX.1 предполагается язык С в качестве основного

языка описания системных функций API.

Таким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах. Однако стандарт в некоторых случаях носит лишь рекомен-дательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования.

Реализации POSIX API на уровне операционной системы различны. Если UNIX-системы в своем абсолютном большинстве изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым. Однако для поддержки данного стандарта в операционной системе MS Windows NT введен специальный модуль поддержки POSIX API, работающий на уровне привилегий пользовательских процессов.

Данный модуль обеспечивает конвертацию и передачу вызовов из пользовательской программы к ядру системы и обратно, работая с ядром через Win API. Прочие приложения, созданные с использованием WinAPI, могут передавать информацию POSIX-приложениям через стандартные механизмы потоков ввода/вывода (stdin, stdout).

Нет похожих постов...