Тема 1. Архитектура, назначение и функции операционных систем

Тема 1. Архитектура, назначение и функции операционных систем

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

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

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

Еще одно важное понятие, связанное с операционной системой, относится к реализации пользовательских интерфейсов. Как правило, любая операционная система обеспечивает удобную работу пользователя за счет средств пользовательского интерфейса. Эти средства могут быть неотъемлемой частью операционной среды (например, графический интерфейс Windows или текстовый интерфейс командной строки MS DOS), а могут быть реализованы отдельной системной программой – оболочкой операционной системы (например, Norton Commander для MS DOS). В общем случае под оболочкой операционной системы понимается часть операционной среды, определяющая интерфейс пользователя, его реализацию (текстовый, графический и т.п.), командные и сервисные возможности пользователя по управлению прикладными программами и компьютером.

Эффекты виртуализации

Экспертиза современных продуктов и недавние исследования раскрывают некоторые интересные возможности развития МВМ и требования, которые они предъявят к технологиям виртуализации.

Администраторы центра данных могут с единой консоли быстро вводить в действие ВМ и управлять тысячами виртуальных машин, выполняющихся на сотнях физических серверов. Вместо того чтобы конфигурировать отдельные компьютеры, администраторы будут создавать по имеющимся шаблонам новые экземпляры виртуальных серверов и отображать их на физические ресурсы в соответствии с политиками администрирования. Уйдет в прошлое взгляд на компьютер как на средство предоставления конкретных услуг. Администраторы будут рассматривать компьютеры просто как часть пула универсальных аппаратных ресурсов (примером тому может служить виртуальный центр VMware VirtualCenter).

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

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

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

Виртуальные машины сильно изменили отношение к компьютерам. Уже сейчас простые пользователи умеют легко создавать, копировать и совместно использовать ВМ. Модели их применения значительно отличаются от привычных, сложившихся в условиях вычислительной среды с ограниченной доступностью аппаратных средств. А разработчики ПО могут применять такие продукты, как VMware Workstation, чтобы легко установить компьютерную сеть для тестирования или создать собственный набор испытательных машин для каждой цели.

Повышенная мобильность ВМ значительно изменила способы их применения. Такие проекты, как Collective и Internet Suspend/Resume, демонстрируют возможность перемещения всей вычислительной среды пользователя по локальной и территориально-распределенной сети. Доступность высокоемких недорогих сменных носителей, например, жестких дисков USB, означает, что потребитель может захватить свою вычислительную среду с собой, куда бы он ни направлялся.

Динамический характер компьютерной среды на базе ВМ требует и более динамичной топологии сети. Виртуальные коммутаторы, виртуальные брандмауэры и оверлейные сети становятся неотъемлемой частью будущего, в котором логическая вычислительная среда отделится от своего физического местоположения.

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

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

Г ибкая обработка отказов. Виртуальные разделы можно настроить так, чтобы обеспечить автоматическую обработку отказов для одного или нескольких приложений. Благодаря средствам обеспечения высокой степени работоспособности, заложенным сейчас в платформы на базе процессоров Intel® Itanium® 2 и Intel® Xeon™ MP, требуемый уровень услуг часто можно обеспечить, предусмотрев аварийный раздел на той же платформе, где работает основное приложение. Если требуется еще более высокий уровень работоспособности, аварийный раздел можно разместить на отдельной платформе.

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

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

Размещение средств безопасности за пределами ВМ – привлекательный способ изоляции сети. Доступ к сети предоставляется ВМ после проверки, гарантирующей, что она, с одной стороны, не представляет угрозы, а с другой – неуязвима для нападения. Управление доступом к сети на уровне ВМ превращает виртуальную машину в мощный инструмент борьбы с распространением злонамеренного кода.

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

Гибкость управления ресурсами, которую обеспечивают МВМ, может сделать системы более стойкими к нападениям. Возможность быстро тиражировать ВМ и динамически адаптироваться к большим рабочим нагрузкам станет основой мощного инструмента, позволяющего справиться с нарастающими перегрузками из-за внезапного наплыва посетителей на Web-сайте или атаки типа "отказ в обслуживании".

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

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

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

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

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

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

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

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

 

Тема 2. Основные семейства операционных систем

USL, Unixware.

Название этой версии связано с компанией USL, созданной AT&T после того, как она решила, что UNIX отвлекает ее от основного бизнеса. Из десяти версий UNIX AT&T только семь разрабатывались непосредственно в этой организации, а последние связаны с USL. Само название компании менялось, и она даже получала новых хозяев. Последняя версия является стандартом для операционных систем UNIX и называется System V Release 4.2. Она впоследствии была приобретена фирмой Novell, известной выпуском сетевой операционной системы для IBM PC с именем NetWare. На основе последней версии системы усилиями Novell и USL создается система UnixWare. Но и эта система поменяла хозяина и далее некоторое время распространялась фирмой SCO.

BSD.

Вторая и очень важная ветвь операционных систем UNIX. Имеет такую историю: находясь в творческом отпуске, Кэн Томпсон установил UNIX в Калифорнийском университете в городе Беркли. Заметим, что он закончил его в свое время. Как было сказано выше, два аспиранта, Билл Джой и Чак Халей, заинтересовавшиеся внутренним устройством UNIX, под его руководством стали дорабатывать систему, в результате чего появилась самостоятельная ветвь в семействе UNIX – BSD. Билл Джой (как было сказано выше, в дальнейшем один из соучредителей фирмы Sun Microsystems), разработал для системы много интересных новинок. Уже во второй дистрибутив BSD была добавлена поддержка виртуальной памяти, позволяющая выполнять программы большего размера, чем оперативная память.

Важным моментом в развитии этого варианта UNIX является тот факт, что именно на ней (впервые в версии 4.1) был реализован стек протоколов TCP/IP в исследовательской сети ARPANET. Таким образом, последняя приобрела все основные свойства, которыми обладает сегодняшний Интернет. Но реализация этого протокола в BSD сделала все версии сетевыми.

Создатели оригинальной ВSD UNIX после прекращения деятельности Университета Беркли по разработке программного комплекса выпустили версии для аппаратной платформы Intel, среди которых, пожалуй, наиболее известна FrееВSD, еще существуют OpenBSD и NetBSD. Если Вы интересуетесь историей и версиями хВSD, то обратитесь к источнику.

Xenix.

Фирма Microsoft известна как разработчик операционной системы для аппаратной платформы IBM PC. В конце 70-х и начале 80-х годов на основе лицензии, купленной у AT&T, была создана система Xenix. Она не получила такого распространения, как думалось при ее создании. После выпуска делались заявления, что именно эта система является стратегическим курсом компании. Но впоследствии она была переделана так, что могла работать на разнообразном оборудовании. Отметим, что разработчики первых версий MS DOS были, по-видимому, знакомы с идеями UNIX, преломляя их для условий работы на аппаратуре IBM PC. Исходные тексты Xenix были проданы SCO, которая некоторое время поддерживала их, а затем прекратила. Некоторая часть исходных текстов Xenix перекочевала в программные комплексы, в частности, SCO Open Server. Заметим, что Microsoft постоянно обращала свой взор на UNIX с разных сторон: как на систему, где возникают новые интересные идеи, как на конкурента, как на возможность на основе этой системы объединиться с другими компаниями для развития нового направления бизнеса.

SCO.

Версия с таким названием сегодня не распространяется. Но она была популярной. Компания Santa Crus Operation (сокращенно SCO) купила у AT&T лицензию на UNIX. В 1988 году три фирмы (SCO, Microsoft и Interactive System) выпустили версию операционной системы для платформы Intel 386. В это время фирма SCO уже купила права на торговую марку UNIX. Сейчас фирма потеряла свою самостоятельность, и права на торговую марку принадлежат The Open Group.

Последние версии системы, поддерживаемые SCO, носили название SCO Open Server. Эта фирма разрабатывала операционные системы с разными названиями. Например, UnixWare она создавала совместно с Novell.

Sun OS, Solaris.

Вариант операционной системы с таким названием выпускается фирмой Sun Microsystems. Одним из ее основателем является Билл Джой, начавший разработку операционных систем в Калифорнийском университете после знакомства с Кеном Томпсоном. Solaris работает на разных аппаратных платформах и прежде всего – на SPARC (собственных процессорах фирмы Sun). Но эта операционная система перенесена и на компьютеры IBM PC и РоwerРС. До Solaris фирма Sun выпускала UNIX с названием Sun OS. Появление системы с новым именем было связано со стремлением обеспечить стандарты операционных систем на разной аппаратуре.

Среди других достижений фирмы Sun Microsystems отметим разработку Java и в дальнейшем представление компьютерному сообществу его исходных кодов.

OSF/1(True64UNIX).

Появление системы OSF/1 связано со стремлением ведущих компьютерных производителей создать противовес альянсу АТ&Т и Sun Мicrosystems. Название OSF является сокращением от Open Software Foundation. В OSF вошли IBM, HP, Digital Equipment Corporation (DEC) и другие. Фирма DEC, ныне уже не существующая, известна, прежде всего, как производитель компьютеров PDP, на которых начинались обе важнейшие версии AT&T и BSD. Фирмы IBM и HP выпускают и поныне успешные версии UNIX. Альянс OSF объединился c X/Open для организации The Open Group, которая сегодня является, видимо, основным хранителем UNIX как таковой.

Видимо, система OSF/1 должна была претендовать на роль третьей важной ветви UNIX (в противовес AT&T и BSD). Трудно сказать, случилось ли это, но вклад в стандарты мира UNIX был, несомненно, сделан. К примеру, принятый альянсом стандарт на графический интерфейс Motif (разработанный в МТИ) победил в конкуренции с разработкой Sun Open Look.

AIX.

Собственно история операционных систем начинается с платформы IBM. В 1955 году для вычислительной машины IBM701 была создана развитая операционная система. Сама фирма сделала очень много для развития операционных систем и в дальнейшем. Скажем, к примеру, о легендарных операционных системах для мейнфреймов IBM 360/370, на которых были реализованы многозадачность и многопользовательский терминальный режим.

Сегодня вариант UNIX, разрабатываемый фирмой IBM для собственных аппаратных платформ, имеет название AIX. Оно происходит от Advanced Interactive Executive – улучшенная интерактивная операционная система. Первая версия AIX появилась в 1986 году на основе SVR3.2 AT&T, а последняя имеет название AIX 6. Эта система объединила в себе лучшие черты версий AT&T, BSD и OSF/1.

Справедливости ради отметим, что в последние годы на своей аппаратуре IBM кроме AIX активно поддерживает и Linux. Но сегодня это только фрагмент, а несколько лет назад в категории "Программные продукты" Linux занимала верхнюю строчку.

HP-UX.

Второй по величине в мире компьютерный гигант разрабатывал систему с таким именем как серверную систему, управляющую вычислительными сетями. Она поддерживается до настоящего времени. Создавалась операционная система в основном для собственной серверной аппаратной платформы HP9000. Ее первая версия родилась на основе VERSION 7 AT&T в 1992 году, а последняя имеет номер 11.

IRIX.

Фирма Silicon Graphics известна как производитель оборудования для графических работ на компьютере. С момента создания в начале 80-х годов долгое время фирма занимала лидирующее положение в области машинной графики. Перейдя в сектор подготовки компьютерных эффектов для кино и телевидения, она, можно сказать, участвовала в создании многих известных кинокартин. В выпускаемых компьютерах Silicon Graphics соединены процессоры фирмы MIPS с RISC архитектурой и собственная операционная система IRIX (клон UNIX). Ее последняя версия была выпущена в 2006 году и имеет номер 6.5. Кроме того, Silicon Graphics разработала библиотеку для моделирования трехмерной графики OpenGL, программный комплекс MAYA. Помимо программных комплексов, фирма разрабатывает и аппаратную часть графических станций.

MacOS.

Версии с таким названием выпущены фирмой Apple. Ее основатель легендарный Стив Джобс (Steve Jobs), на наш взгляд, вполне заслуживает звания автора первого коммерчески успешного персонального компьютера. Хотя к 1977 году, моменту выпуска компьютеров Apple, уже существовали такие приборы нескольких фирм, в том числе Atari и IBM, но эту модель можно считать первой наиболее успешной коммерческой моделью персонального компьютера. Далее был выпущен компьютер Lisa (Local Integrated Software Architecture) с реализацией того, что называют GUI. Этот проект был представлен в январе 1983 года. Для фирмы Apple следующим этапом стало появление компьютеров Macintosh, выпускаемых со своей операционной системой. Все перечисленные модели строились на процессорах Motorola 68000, которые по своим возможностям долгое время превосходили IBM PC с графическим интерфейсом Windows. Параллельно с основной операционной системой в Apple создается UNIX-подобная система AUX.

После ухода из Apple Джобс разрабатывал собственную операционную систему NeXTSTEP. Вернувшись в Apple в 2000 году, он сделал своей основной операционной системой Mac OS. Она является преемницей операционных систем, созданных под руководством Стива Джобса, и строится на основе микроядра Mach 3.0 и элементов UNIX BSD 4.4. Система активно развивается, и ее последняя версия имеет номер 10.11.

Версии UNIX для IBM PC.

До 1991 года было выпущено несколько версий UNIX для аппаратной платформы IBM PC. Но, пожалуй, только версия Linuxсмогла составить серьезную конкуренцию продуктам фирмы Microsoft – Windows. Прежде всего, Linux используется на серверах, но постепенно завоевывает рынок программ и для автоматизации деятельности в офисе, для графических работ на персональных компьютерах. Отметим, что кроме этой операционной системы на IBM PC применяются ОС Solaris (с апреля 2010 года принадлежащей Oracle). Последняя была разработана для аппаратной платформы Sun, но была адаптирована для процессоров Intel. Также на такой аппаратной платформе распространены продукты компаний, вышедших из BSD. Они называются Free BSD, OpenBSD, NetBSD.

Операционная система Linux создавалась для персональных компьютеров с процессорами Intel. Но постепенно она "перешла" и на другие аппаратные платформы (SPARC, Alpha, Power PC). Полный перечень аппаратных платформ, на которых уже работает Linux, можно найти, например, по адресу в Интернете. В последние годы Linux получает распространение и на карманных персональных компьютерах.

Необычность операционной системы Linux заключается в том, что ее основу до настоящего времени создает Линус Торвальдс. А вот продукт для потребителей разрабатывают многие фирмы, формируя дистрибутивы (инсталляторы). Мы уже отмечали, что первый успешный инсталлятор Slackware был выпущен Патриком Фолькердингом. Сделаем оговорку. Уже в 1992 году появился дистрибутив SLS (Softlanding Linux System) Питера Мак-Дональда, включавший в себя оконную систему X – то есть, теоретически, пригодный для конечного пользователя.

Интересную классификацию множества инсталляторов Linux предложил А. Федорчук в своей статье, положив в ее основу следующие признаки:

● программа инсталляции;

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

● структура файловой системы;

● состав прикладных программ и утилит в инсталляторе.

По данной классификации дистрибутивы делятся на три группы, сходные с RedHat, Debain и Slackware.

Приведем наиболее популярные дистрибутивы этой операционной системы.

В последние годы среди многих версий операционных систем семейства Linux одной из самых популярных является Ubuntu. Его варианты выпускаются каждые 6 месяцев. Можно послать заявку, и дистрибутив будет доставлен по почте. Также можно скачать дистрибутив с бесплатных ресурсов Интернета. Финансирует развитие Ubuntu Марк Ричард Шаттлворт (Mark Richard Shuttleworth) – миллионер и второй космический турист, родившийся в ЮАР.

Самый древний дистрибутив Slackware – до сих пор в строю, хотя на сегодняшний день не входит в десятку самых популярных. На его основе созданы другие дистрибутивы.

Red Hat долгое время была одной из наиболее распространенной системой Linux. В рамках дистрибутивов американской компании опробованы многие технологии. Но с 2003 года фирма Red Hat сменила политику выпуска дистрибутивов. Свободно распространяемой версией стала Fedora, а система Red Hat Enterprise Linux является корпоративным решением, который продается.

SUSE – этот дистрибутив имеет корни от самого первого дистрибутива SLS, не имевшего широкого распространения. В свое время он был очень распространен в Европе. Но в 2003 году этот дистрибутив был куплен американской фирмой Novell.

Дистрибутив с именем Debian находится в списке пионеров. Его создание началось в 1993 году. На его основе строились многие дистрибутивы, один из них – ubuntu.

Отдельно скажем о русифицированных дистрибьюторах. Это Fedora (фирмы Red Hat раннее выпускавшую версию с названием Red Hat Cyrillic Edition), SuSe и Mandriva (долгое время имевший имя фирмы Mandrake), но как наиболее распространенную российскую разработку следует отметить Alt Linux.

Стандарты семейства UNIX

Причиной появления стандартов на операционную систему UNIX стало то, что она была перенесена на многие аппаратные платформы. Ее первые версии работали на аппаратуре PDP, но в 1976 и 1978 годах система была перенесена на Interdata и VAX. С 1977 по 1981 годы оформились две конкурирующие ветви: UNIX AT&T и BSD. Наверное, цели разработки стандартов были разными. Одна из них – узаконить главенство своей версии, а другая – обеспечить переносимость системы и прикладных программ между различными аппаратными платформами. В связи с этим говорят и о мобильности программ. Такие свойства имеют отношение как к исходным текстам программ, так и исполнимым программам.

Дальнейший материал приводится в хронологическом порядке появления стандартов.

System V Interface Definition (SVID)

Другое направление развития стандартов UNIX связано с тем, что не только энтузиасты задумывались о создании "эталонов". Основные разработчики системы с появлением многих "вариантов" решили издавать собственные документы. Так появляются стандарты, выпускаемые USG, организацией, разрабатывающей документацию версий UNIX AT&T с того момента, когда для создания операционной системы была образована эта дочерняя компания. Первый документ появился в 1984 году на основе SVR2. Он имел название SVID (System V Interface Definition). Четырехтомное описание было выпущено после выхода в свет версии SVR4. Эти стандарты дополнялись набором тестовых программ SVVS (System V Verification Suite). Основное назначение этих средств состояло в том, чтобы разработчики имели возможность судить, может ли их система претендовать на имя System V.

Отметим, что положение дел со стандартом SVID в чем-то сходно со стандартом языка программирования С. Изданная авторами этого языка программирования книга является одним из эталонов, но не единственным. Выпущенный позже стандарт С является результатом коллективного труда, прошел этап обсуждения широкой общественности и, видимо, может претендовать на ведущую роль в списке стандартов. Так и SVVS является набором тестов, позволяющих судить, достойна ли система соответствовать имени System V, только одной из версий UNIX. При этом не учитывается весь опыт разработки операционных систем от разных производителей.

Комитеты POSX

Работа по оформл I ению стандартов UNIX началась группой энтузиастов в 1980 году. Была сформулирована цель – формально определить услуги, которые операционные системы обеспечивают приложениям. Такой стандарт программного интерфейса стал основой документа POSIX (Portable Operating System Interface for Computing Environment – переносимый интерфейс операционной системы для вычислительной среды). Первая рабочая группа POSIX была образована в 1985 году на основе UNIX-ориентированного комитета по стандартизации /usr/group, также называемой UniForum. Название POSIX было предложено родоначальником GNU Ричардом Столмэном.

Ранние версии POSIX определяют множество системных сервисов, необходимых для функционирования прикладных программ, которые описаны в рамках интерфейса, специфицированного для языка С (интерфейс системных вызовов). Заложенные в нем идеи использовались комитетом ANSI (American National Standards Institute) при создании стандарта языка C, упомянутого ранее. Исходный состав функций, закладываемый в первые версии, опирался на UNIX AT&T (версия SVR4). Но в дальнейшем происходит, отрыв спецификаций стандартов POSIX от этой конкретной ОС. Подход к организации системы на основе множества базовых системных функций был применен не только в UNIX (например, WinAPI фирмы Microsoft).

В 1988 году был опубликован стандарт 1003.1 – 1988, определяющий API (Application Programming Interface, программный интерфейс приложений). Через два года был принят новый вариант стандарта IEEE 1003.1 – 1990. В нем были определены общие правила программного интерфейса, как для системных вызовов, так и для библиотечных функций. Далее утверждаются дополнения к нему, определяющие сервисы для систем реального времени, "нитей" POSIX и др. Важным является стандарт POSIX 1003.2 – 1992 – определение командного интерпретатора и утилит.

Имеется перевод этих двух групп документов, которые получили такие названия: POSIX.1 (интерфейс прикладных программ) и POSIX.2 (командный интерпретатор и утилиты – интерфейс пользователя). В упомянутом переводе содержатся три главы: основные понятия, системные услуги и утилиты. Глава "Системные услуги" разделена на несколько частей, каждая из которых группирует сходные по функциям услуги. Например, в одном из разделов "Базовый ввод/вывод" седьмая часть, посвященная операциям с каталогами, описывает три функции (opendir, readdir и closedir). Они определяются в четырех пунктах: "Синтаксис", "Описание", "Возвращаемое значение" и "Ошибки".

Для тех, кто знаком с алгоритмическим языком программирования С, приведем пример фрагментов описания. Фактически такое описание дает представление о том, как специфицируется "Интерфейс системных вызовов". В пункте "Синтаксис" про функцию readdir приведены такие строки:

#include <sys/types.h>

#include <dirent.h>

struct dirent *readdir(DIR *dirp);

 

Второй пункт ("Описание") содержит следующий текст:

" Типы и структуры данных, используемые в определениях с каталогами, определяются в файле dirent.h. Внутренний состав каталогов определяется реализацией. При чтении с помощью функции readdir формируется объект типа struct dirent, содержащий в качестве поля символьный массивd_name, в котором находится завершаемое символом NUL локальное имя файла.

Readdir читает текущий элемент каталога и устанавливает указатель позиции на следующий элемент. Открытый каталог задается указателем dirp. Элемент, содержащий пустые имена, пропускается".

А вот что приводится в пункте "Возвращаемое значение":

" Readdir при успешном завершении возвращает указатель на объект типа struct dirent, содержащий прочитанный элемент каталога. Прочитанный элемент может заноситься в статическую память и перекрывается очередным таким вызовом, примененным к тому же открытому каталогу. Вызов readdir для различных открытых каталогов не перекрывает читаемую информацию. В случае ошибки или достижении конца файла возвращается нулевой указатель ".

В пункте "Ошибки стандарта" указано следующее:

" Readdir и closedir обнаруживают ошибку. [EBADF] Dirp не являются указателем на открытый каталог ".

Этот пример показывает, как описываются представляемые приложением услуги. Требования к операционной системе (реализации) заключается в том, что она " …должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения. Константа _POSIX_VERSION имеет значение 200112L ".

В мире компьютерных технологий существует такое словосочетание: "программирование POSIX". Этому можно научиться, используя различные руководства по системному программированию UNIX и операционным системам. Есть отдельная книга с таким названием. Заметим, что в предисловии к этой книге сказано, что она описывает "… стандарт втройне … ", так как она опирается на последнюю версию POSIX 2003 года, в основе которой три стандарта: IEEE Std 1003.1, технический стандарт Open Group и ISO/IEC 9945.

Как же проверить соответствие конкретной системы стандарту POSIX? Формализация такого вопроса не так проста, как кажется на первый взгляд. В современных версиях предлагается 4 вида соответствия (четыре семантических значения слова "соответствие": полное, международное, национальное, расширенное).

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

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

· Base Definitions volume (XBD) – определение терминов, концепций и интерфейсов, общих для всех томов данного стандарта;

· System Interfaces volume (XSH) – интерфейсы системного уровня и их привязка к языку Си, где описываются обязательные интерфейсы между прикладными программами и операционной системой, в частности – спецификации системных вызовов;

· Shell and Utilities volume (XCU) – определение стандартных интерфейсов командного интерпретатора (т.н. POSIX-shell), а также базовой функциональности Unix-утилит;

· Rationale (Informative) volume (XRAT) – дополнительная, в том числе историческая, информация о стандарте.

Как и первые редакции, документ в своей основной части описывает группы представляемых услуг. Каждый элемент там описан в следующих пунктах: NAME (Имя), SINOPSIS (Синтаксис), DISCRIPTION (Описание), RETURN VALUE (Возвращаемое значение), ERRORS (Ошибки) и в заключении EXAMPLE (Примеры).

Современные версии стандарта определяют требования как к операционной системе, так и к прикладным программам.

И в заключение приведем отрывок из курса лекций Сухомлинова ("ВВЕДЕНИЕ В АНАЛИЗ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ", Сухомлинов В.А. Часть V. Методология и система стандартов POSIX OSE), посвященным области применимости стандартов:

"Область применимости стандартов POSIX OSE (Open System Environment) – обеспечение следующих возможностей (называемых еще свойствами открытости) для разрабатываемых информационных систем:

· Переносимость приложений на уровне исходных текстов (Application Portability at the Source Code Level), т.е. предоставление возможности переноса программ и данных, представленных на исходных текстах языков программирования, с одной платформы на другую.

· Системная интероперабельность (System Interoperability), т.е. поддержка взаимосвязанности между системами.

· Переносимость пользователей (User Portability), т.е. обеспечение возможности для пользователей работать на различных платформах без переобучения.

· Адаптируемость к новым стандартам (Accommodation of Standards), связанным с достижением целей открытости систем.

· Адаптируем