Функции операционных систем. Классификация операционных систем. Физическая структура жёсткого диска

Оглавление Введение 1 Функции операционных систем 4 Классификация операционных систем 4 История возникновения и этапы развития операционных систем 7 UNIX-подобные операционные системы. Linux 16 Архитектура операционных систем 20 Структура ОС Linux 40 Ядро 40 Графические оболочки 40 Дистрибутив 42 Физическая структура жёсткого диска 44 Раздел. Виды разделов 44 Главная загрузочная запись и загрузочный сектор 46 Начальная загрузка 47 Загрузчик операционной системы 48 Файловая система Linux 49 Точка монтирования 50 Структура каталогов в Linux 53 Операционная система DOS 57 Семейство операционных систем Windows 60 Основные принципы построения ОС 65 Процессы и треды 70 Планирование и диспетчеризация процессов и задач 74 Введение Современная компьютерная система состоит из одного или нескольких процессоров, оперативной памяти, дисков, клавиатуры, монитора, принтеров, сетевого интерфейса и других устройств, то есть является сложной комплексной системой. Написание программ, которые следят за всеми компонентами, корректно используют их и при этом работают оптимально, представляет собой крайне трудную задачу. По этой причине компьютеры оснащаются специальным уровнем программного обеспечения, называемым операционной системой. Операционная система отвечает за управление всеми перечисленными устройствами и обеспечивает пользователя имеющими простой, доступный интерфейс программами для работы с аппаратурой. Операционная система (ОС) — комплекс управляющих и обрабатывающих программ, которые, с одной стороны, выступают как интерфейс между устройствами вычислительной системы и прикладными программами, а с другой — предназначены для управления устройствами, управления вычислительными процессами, эффективного распределения вычислительных ресурсов между вычислительными процессами и организации надёжных вычислений. Рис. 1.1 — Место операционной системы в многоуровневой структуре компьютера Операционная система как виртуальная (расширенная) машина Архитектура большинства компьютеров на уровне машинных команд очень неудобна для ее использования прикладными программами. Например, работа с диском предполагает знакомство с внутренним устройством его электронного компонента — контроллера для ввода команд вращения диска, поиска и форматирования дорожек, чтения и записи секторов и т.д. Ясно, что средний программист не в состоянии учитывать все особенности работы оборудования (в современной терминологии заниматься разработкой драйверов устройств), а должен иметь простую высокоуровневую абстракцию, скажем, представляя информационное пространство диска как набор файлов. Файл можно открывать для чтения или записи, использовать для получения или сброса информации, а потом закрывать. Это концептуально проще, чем заботиться о деталях перемещения головок дисков или организации работы мотора. Аналогичным образом, с помощью простых и ясных абстракций, скрываются от программиста все ненужные ему подробности организации работы физических устройств. Более того, на современных вычислительных комплексах может быть создана иллюзия неограниченного размера операционной памяти и числа процессоров. Всем этим занимается операционная система. Таким образом, операционная система представляется пользователю виртуальной машиной, с которой проще иметь дело, чем непосредственно с оборудованием компьютера. Операционная система как менеджер ресурсов Операционная система предназначена для управления всеми частями весьма сложной архитектуры компьютера. Представим для примера, что случится, если несколько программ, работающих на одном компьютере, будут пытаться одновременно осуществлять вывод на принтер. Мы получили бы неупорядоченную смесь строчек и страниц, выведенных различными программами. Операционная система предотвращает хаос такого рода за счет буферизации информации, предназначенной для печати, на диске и организации очереди на печать. Для многопользовательских компьютеров, необходимость управления ресурсами и их защиты еще более очевидна. Следовательно, операционная система как менеджер ресурсов, осуществляет упорядоченное и контролируемое распределение процессоров, памяти и других ресурсов между различными программами, их использующими. Управление ресурсами включает в себя их мультиплексирование (распределение) двумя способами: во времени и в пространстве. Когда ресурс распределяется во времени, различные пользователи и программы используют его по очереди. Сначала один из них получает доступ к использованию ресурса, потом другой и т. д. Например, несколько программ хотят обратиться к центральному процессору. В этой ситуации операционная система сначала разрешает доступ к процессору одной программе, затем, после того как она поработала достаточное время, другой программе, затем следующей и, в конце концов, опять первой. Определение того, как долго ресурс будет использоваться во времени, кто будет следующим и на какое время ему предоставляется ресурс — это задача операционной системы. Другой вид распределения — это пространственное мультиплексирование. Вместо поочередной работы каждый клиент получает часть ресурса. Обычно оперативная память разделяется между несколькими работающими программами, так что все они одновременно могут постоянно находиться в памяти (например, используя центральный процессор по очереди). Если предположить, что памяти достаточно для того, чтобы хранить несколько программ, эффективнее разместить в памяти сразу несколько программ, чем выделить всю память одной программе, особенно если ей нужна лишь небольшая часть имеющейся памяти. Конечно, при этом возникают проблемы справедливого распределения, защиты памяти и т. д., и для разрешения подобных вопросов существует операционная система. Операционная система как защитник пользователей и программ Если вычислительная система допускает совместную работу нескольких пользователей, то возникает проблема организации их безопасной деятельности. Необходимо обеспечить сохранность личной информации на диске, чтобы никто не мог удалить или повредить чужие файлы. Нельзя разрешить программам одних пользователей произвольно вмешиваться в работу программ других пользователей. Нужно пресекать попытки несанкционированного использования вычислительной системы. Всю эту деятельность осуществляет операционная система как организатор безопасной работы пользователей и их программ. С такой точки зрения операционная система выглядит системой безопасности в государстве, на которую возложены полицейские и контрразведывательные функции. Функции операционных систем Основные: • Выполнение по запросу программ низкоуровневых действий, которые являются общими для большинства программ и часто встречаются почти во всех программах (ввод и вывод данных, запуск и остановка других программ, выделение и освобождение дополнительной памяти и др.). • Загрузка программ в оперативную память и их выполнение. • Стандартизованный доступ к периферийным устройствам (устройства ввода-вывода). • Управление оперативной памятью (распределение между процессами, организация виртуальной памяти). • Управление доступом к данным на энергонезависимых носителях (таких как жёсткий диск, оптические диски и др.), организованным в той или иной файловой системе. • Обеспечение пользовательского интерфейса. • Сетевые операции, поддержка стека сетевых протоколов. Дополнительные: • Параллельное или псевдопараллельное выполнение задач (многозадачность). • Эффективное распределение ресурсов вычислительной системы между процессами. • Разграничение доступа различных процессов к ресурсам. • Организация надёжных вычислений (невозможности одного вычислительного процесса намеренно или по ошибке повлиять на вычисления в другом процессе), основаная на разграничении доступа к ресурсам. • Взаимодействие между процессами: обмен данными, взаимная синхронизация. • Защита самой системы, а также пользовательских данных и программ от действий пользователей (злонамеренных или по незнанию) или приложений. • Многопользовательский режим работы и разграничение прав доступа (см. аутентификация, авторизация). Классификация операционных систем Операционные системы могут различаться особенностями реализации внутренних алгоритмов управления основными ресурсами компьютера (процессорами, памятью, устройствами), особенностями использованных методов проектирования, типами аппаратных платформ, областями использования и многими другими свойствами. Ниже приведена классификация ОС по нескольким наиболее основным признакам. Особенности алгоритмов управления ресурсами В зависимости от алгоритма управления процессором, операционные системы делятся на: Однопроцессорные и многопроцессорные По числу одновременно выполняемых задач операционные системы делятся на два класса: Однозадачные (MS DOS) Многозадачные (OS/2, Unix, Windows) В однозадачных системах используются средства управления периферийными устройствами, средства управления файлами, средства общения с пользователями. Многозадачные ОС используют все средства, которые характерны для однозадачных, и, кроме того, управляют разделением совместно используемых ресурсов: процессор, ОЗУ, файлы и внешние устройства. В зависимости от областей использования многозадачные ОС подразделяются на три типа: Системы пакетной обработки (ОС ЕС) Системы с разделением времени (Unix, Linux, Windows) Системы реального времени (RT11) Системы пакетной обработки предназначены для решения задач, которые не требуют быстрого получения результатов. Главной целью ОС пакетной обработки является максимальная пропускная способность или решение максимального числа задач в единицу времени. Эти системы обеспечивают высокую производительность при обработке больших объемов информации, но снижают эффективность работы пользователя в интерактивном режиме. В системах с разделением времени для выполнения каждой задачи выделяется небольшой промежуток времени, и ни одна задача не занимает процессор надолго. Если этот промежуток времени выбран минимальным, то создается видимость одновременного выполнения нескольких задач. Эти системы обладают меньшей пропускной способностью, но обеспечивают высокую эффективность работы пользователя в интерактивном режиме. Системы реального времени применяются для управления технологическим процессом или техническим объектом, например, летательным объектом, станком и т.д. По числу одновременно работающих пользователей на ЭВМ ОС разделяются на однопользовательские (MS DOS) и многопользовательские (Unix, Linux, Windows 95 - XP) В многопользовательских ОС каждый пользователь настраивает для себя интерфейс пользователя, т.е. может создать собственные наборы ярлыков, группы программ, задать индивидуальную цветовую схему, переместить в удобное место панель задач и добавить в меню Пуск новые пункты. В многопользовательских ОС существуют средства защиты информации каждого пользователя от несанкционированного доступа других пользователей. Одним из важнейших признаков классификации ЭВМ является разделение их на локальные и сетевые. Локальные ОС применяются на автономных ПК или ПК, которые используются в компьютерных сетях в качестве клиента. В состав локальных ОС входит клиентская часть ПО для доступа к удаленным ресурсам и услугам. Сетевые ОС предназначены для управления ресурсами ПК включенных в сеть с целью совместного использования ресурсов. Они представляют мощные средства разграничения доступа к информации, ее целостности и другие возможности использования сетевых ресурсов. История возникновения и этапы развития операционных систем Так как операционные системы появились и развивались в процессе конструирования компьютеров, то эти события исторически тесно связаны. Идея компьютера была предложена английским математиком Чарльзом Бэбиджем (Charles Babage) в середине девятнадцатого века. Его механическая «аналитическая машина» так и не смогла по-настоящему заработать, потому что технологии того времени не удовлетворяли требованиям, необходимым для изготовления нужных деталей точной механики. 45 – 55-ый годы XX века. Настоящее рождение цифровых вычислительных машин произошло вскоре после окончания Второй мировой войны. В середине 40-х были созданы первые ламповые вычислительные устройства. В то время одна и та же группа людей участвовала и в проектировании, и в эксплуатации, и в программировании вычислительной машины. Это была скорее научно-исследовательская работа в области вычислительной техники, а не использование компьютеров в качестве инструмента решения каких-либо практических задач из других прикладных областей. Программирование осуществлялось исключительно на машинном языке, управления основными функциями машины осуществлялось просто при помощи соединения коммутационных панелей проводами. Тогда еще не были известны языки программирования (даже ассемблера не было). Не было никакого системного программного обеспечения, кроме библиотек математических и служебных подпрограмм, которые программист мог использовать для того, чтобы не писать каждый раз коды, вычисляющие значение какой-либо математической функции или управляющие стандартным устройством ввода-вывода. Операционные системы все еще не появились, все задачи организации вычислительного процесса решались вручную каждым программистом с пульта управления, который представлял собой примитивное устройство ввода-вывода, состоящее из кнопок, переключателей и индикаторов. Фактически тогда на компьютерах занимались только прямыми числовыми вычислениями, например расчетами таблиц синусов, косинусов и логарифмов. К началу 50-х, с выпуском перфокарт, установившееся положение несколько улучшилось. Стало возможно вместо использования коммутационных панелей записывать и считывать программы с карт, но во всем остальном процедура вычислений оставалась прежней. 55 – 65-ый годы. С середины 50-х годов начался новый период в развитии вычислительной техники, связанный с появлением новой технической базы — полупроводниковых элементов. Выросло быстродействие процессоров, увеличились объемы оперативной и внешней памяти. Компьютеры стали более надежными, теперь они могли непрерывно работать настолько долго, чтобы на них можно было возложить выполнение действительно практически важных задач. Наряду с совершенствованием аппаратуры заметный прогресс наблюдался также в области автоматизации программирования и организации вычислительных работ. В эти годы появились первые алгоритмические языки, и таким образом к библиотекам математических и служебных подпрограмм добавился новый тип системного программного обеспечения — трансляторы. Выполнение каждой программы стало включать большое количество вспомогательных работ: загрузка нужного транслятора (АЛГОЛ, ФОРТРАН, КОБОЛ и т. п.), запуск транслятора и получение результирующей программы в машинных кодах, связывание программы с библиотечными подпрограммами, загрузка программы в оперативную память, запуск программы, вывод результатов на периферийное устройство. Для организации эффективного совместного использования трансляторов, библиотечных программ и загрузчиков в штат многих вычислительных центров были введены должности операторов, профессионально выполнявших работу по организации вычислительного процесса для всех пользователей этого центра. Но как бы быстро и надежно ни работали операторы, они никак не могли состязаться в производительности с работой устройств компьютера. Большую часть времени процессор простаивал в ожидании, пока оператор запустит очередную задачу. А поскольку процессор представлял собой весьма дорогое устройство, то низкая эффективность его использования означала низкую эффективность использования компьютера в целом. Для решения этой проблемы были разработаны первые системы пакетной обработки, которые автоматизировали всю последовательность действий оператора по организации вычислительного процесса. Ранние системы пакетной обработки явились прообразом современных операционных систем, они стали первыми системными программами, предназначенными не для обработки данных, а для управления вычислительным процессом. Оператор составлял пакет заданий, которые в дальнейшем без его участия последовательно запускались на выполнение управляющей программой — монитором. Кроме того, монитор был способен самостоятельно обрабатывать наиболее часто встречающиеся при работе пользовательских программ аварийные ситуации, такие как отсутствие исходных данных, переполнение регистров, деление на ноль, обращение к несуществующей области памяти и т. д. Пакет обычно представлял собой набор перфокарт, но для ускорения работы он мог переноситься на более удобный и емкий носитель, например на магнитную ленту или магнитный диск. Ранние системы пакетной обработки значительно сократили затраты времени на вспомогательные действия по организации вычислительного процесса, а значит, был сделан еще один шаг по повышению эффективности использования компьютеров. Однако при этом программисты-пользователи лишились непосредственного доступа к компьютеру, что снижало эффективность их работы — внесение любого исправления требовало значительно больше времени, чем при интерактивной работе за пультом машины. 1965-1975 годы. В это время в технической базе вычислительных машин произошел переход от отдельных полупроводниковых элементов типа транзисторов к интегральным микросхемам, что открыло путь к появлению следующего поколения компьютеров. Большие функциональные возможности интегральных схем сделали возможным реализацию на практике сложных компьютерных архитектур, таких, например, как IBM/360. В этот период были реализованы практически все основные механизмы, присущие современным ОС: мультипрограммирование, мультипроцессирование, поддержка многотерминального многопользовательского режима, виртуальная память, файловые системы, разграничение доступа и сетевая работа. В эти годы начинается расцвет системного программирования. Из направления прикладной математики, представляющего интерес для узкого круга специалистов, системное программирование превращается в отрасль индустрии, оказывающую непосредственное влияние на практическую деятельность миллионов людей. Революционным событием данного этапа явилась промышленная реализация мультипрограммирования. (Заметим, что в виде концепции и экспериментальных систем этот способ организации вычислений существовал уже около десяти лет). В условиях резко возросших возможностей компьютера по обработке и хранению данных выполнение только одной программы в каждый момент времени оказалось крайне неэффективным. Решением стало мультипрограммирование — способ организации вычислительного процесса, при котором в памяти компьютера находилось одновременно несколько программ, попеременно выполняющихся на одном процессоре. Эти усовершенствования значительно улучшили эффективность вычислительной системы: компьютер теперь мог использоваться почти постоянно, а не менее половины времени работы компьютера, как это было раньше. Мультипрограммирование было реализовано в двух вариантах — в системах пакетной обработки и разделения времени. Мультипрограммные системы пакетной обработки так же, как и их однопрограммные предшественники, имели своей целью обеспечение максимальной загрузки аппаратуры компьютера, однако решали эту задачу более эффективно. В мультипрограммном пакетном режиме процессор не простаивал, пока одна программа выполняла операцию ввода-вывода (как это происходило при последовательном выполнении программ в системах ранней пакетной обработки), а переключался на другую готовую к выполнению программу. В результате достигалась сбалансированная загрузка всех устройств компьютера, а следовательно, увеличивалось число задач, решаемых в единицу времени. В мультипрограммных системах пакетной обработки пользователь по-прежнему был лишен возможности интерактивно взаимодействовать со своими программами. Для того чтобы хотя бы частично вернуть пользователям ощущение непосредственного взаимодействия с компьютером, был разработан другой вариант мультипрограммных систем — системы разделения времени. Этот вариант рассчитан на многотерминальные системы, когда каждый пользователь работает за своим терминалом. Вариант мультипрограммирования, применяемый в системах разделения времени, был нацелен на создание для каждого отдельного пользователя иллюзии единоличного владения вычислительной машиной за счет периодического выделения каждой программе своей доли процессорного времени. Многотерминальный режим использовался не только в системах разделения времени, но и в системах пакетной обработки. При этом не только оператор, но и все пользователи получали возможность формировать свои задания и управлять их выполнением со своего терминала. Такие операционные системы получили название систем удаленного ввода заданий. Терминальные комплексы могли располагаться на большом расстоянии от процессорных стоек, соединяясь с ними с помощью различных глобальных связей — модемных соединений телефонных сетей или выделенных каналов. Для поддержания удаленной работы терминалов в операционных системах появились специальные программные модули, реализующие различные (в то время, как правило, нестандартные) протоколы связи. Такие вычислительные системы с удаленными терминалами, сохраняя централизованный характер обработки данных, в какой-то степени являлись прообразом современных сетей, а соответствующее системное программное обеспечение — прообразом сетевых операционных систем. Реализация мультипрограммирования потребовала внесения очень важных изменений в аппаратуру компьютера, непосредственно направленных на поддержку нового способа организации вычислительного процесса. При разделении ресурсов компьютера между программами необходимо обеспечить быстрое переключение процессора с одной программы на другую, а также надежно защитить коды и данные одной программы от непреднамеренной или преднамеренной порчи другой программой. В процессорах появился привилегированный и пользовательский режимы работы, специальные регистры для быстрого переключения с одной программы на другую, средства защиты областей памяти, а также развитая система прерываний. В привилегированном режиме, предназначенном для работы программных модулей операционной системы, процессор мог выполнять все команды, в том числе и те из них, которые позволяли осуществлять распределение и защиту ресурсов компьютера. Программам, работающим в пользовательском режиме, некоторые команды процессора были недоступны. Таким образом, только ОС могла управлять аппаратными средствами и исполнять роль монитора и арбитра для пользовательских программ, которые выполнялись в непривилегированном, пользовательском режиме. Еще одной важной тенденцией этого периода является создание семейств программно-совместимых машин и операционных систем для них. Примерами семейств программно-совместимых машин, построенных на интегральных микросхемах, являются серии машин IBM/360 и IBM/370. Вскоре идея программно-совместимых машин стала общепризнанной. Программная совместимость требовала и совместимости операционных систем. Однако такая совместимость подразумевает возможность работы на больших и на малых вычислительных системах, с большим и с малым количеством разнообразной периферии, в коммерческой области и в области научных исследований. Операционные системы, построенные с намерением удовлетворить всем этим противоречивым требованиям, оказались чрезвычайно сложными. Они состояли из многих миллионов ассемблерных строк, написанных тысячами программистов, и содержали тысячи ошибок, вызывающих нескончаемый поток исправлений. Операционные системы этого поколения были очень дорогими. Так, разработка OS/360, объем кода для которой составил 8 Мбайт, стоила компании IBM 80 миллионов долларов. Однако несмотря на необозримые размеры и множество проблем, OS/360 и другие ей подобные операционные системы этого поколения действительно удовлетворяли большинству требований потребителей. За это десятилетие был сделан огромный шаг вперед и заложен прочный фундамент для создания современных операционных систем. Операционные системы и глобальные сети В начале 70-х годов появились первые сетевые операционные системы, которые в отличие от многотерминальных ОС позволяли не только рассредоточить пользователей, но и организовать распределенное хранение и обработку данных между несколькими компьютерами, связанными связями. Любая сетевая операционная система, с одной стороны, выполняет все функции локальной операционной системы, а с другой стороны, обладает некоторыми дополнительными средствами, позволяющими ей взаимодействовать по сети с операционными системами других компьютеров. Программные модули, реализующие сетевые функции, появлялись в операционных системах постепенно, по мере развития сетевых технологий, аппаратной базы компьютеров и возникновения новых задач, требующих сетевой обработки. Хотя теоретические работы по созданию концепций сетевого взаимодействия велись почти с самого появления вычислительных машин, значимые практические результаты по объединению компьютеров в сети были получены в конце 60-х, когда с помощью глобальных связей и техники коммутации пакетов удалось реализовать взаимодействие машин класса мэйнфреймов и суперкомпьютеров. Эти дорогостоящие компьютеры часто хранили уникальные данные и программы, доступ к которым необходимо было обеспечить широкому кругу пользователей, находившихся в различных городах на значительном расстоянии от вычислительных центров. В 1969 году Министерство обороны США инициировало работы по объединению суперкомпьютеров оборонных и научно-исследовательских центров в единую сеть. Эта сеть получила название ARPANET и явилась отправной точкой для создания самой известной ныне глобальной сети — Интернета. Сеть ARPANET объединяла компьютеры разных типов, работавшие под управлением различных ОС с добавленными модулями, реализующими коммуникационные протоколы, общие для всех компьютеров сети. Операционные системы мини-компьютеров и первые локальные сети К середине 70-х годов наряду с мэйнфреймами широкое распространение получили мини-компьютеры, такие как PDP-11, Nova, HP. Мини-компьютеры первыми использовали преимущества больших интегральных схем, позволившие реализовать достаточно мощные функции при сравнительно невысокой стоимости компьютера. Архитектура мини-компьютеров была значительно упрощена по сравнению с мэйнфреймами, что нашло отражение и в их операционных системах. Многие функции мультипрограммных многопользовательских ОС мэйнфреймов были усечены, учитывая ограниченность ресурсов мини-компьютеров. Операционные системы мини-компьютеров часто стали делать специализированными, например только для управления в реальном времени (ОС RT-11 для мини-компьютеров PDP-11) или только для поддержания режима разделения времени (RSX-11M для тех же компьютеров). Эти операционные системы не всегда были многопользовательскими, что во многих случаях оправдывалось невысокой стоимостью компьютеров. Важной вехой в истории мини-компьютеров и вообще в истории операционных систем явилось создание ОС UNIX. Доступность мини-компьютеров и вследствие этого их распространенность на предприятиях послужили мощным стимулом для создания локальных сетей. Предприятие могло себе позволить иметь несколько мини-компьютеров, находящихся в одном здании или даже в одной комнате. Естественно, возникала потребность в обмене информацией между ними и в совместном использовании дорогого периферийного оборудования. Первые локальные сети строились с помощью нестандартного коммуникационного оборудования, в простейшем случае — путем прямого соединения последовательных портов компьютеров. Программное обеспечение также было нестандартным и реализовывалось в виде пользовательских приложений. Развитие операционных систем в 80-е годы К наиболее важным событиям этого десятилетия можно отнести разработку стека TCP/IP, становление Интернета, стандартизацию технологий локальных сетей, появление персональных компьютеров и операционных систем для них. Внедрение протоколов TCP/IP в ARPANET придало этой сети все основные черты, которые отличают современный Интернет. В 1983 году сеть ARPANET была разделена на две части: MILNET, поддерживающую военные ведомства США, и новую ARPANET. Для обозначения составной сети ARPANET и MILNET стало использоваться название Internet, которое в русском языке со временем (и с легкой руки локализаторов Microsoft) превратилось в Интернет. Интернет стал отличным полигоном для испытаний многих сетевых операционных систем, позволившим проверить в реальных условиях возможности их взаимодействия, степень масштабируемости, способность работы при экстремальной нагрузке, создаваемой сотнями и тысячами пользователей. Начало 80-х годов связано с еще одним знаменательным для истории операционных систем событием — появлением персональных компьютеров. С точки зрения архитектуры персональные компьютеры ничем не отличались от класса мини-компьютеров, но их стоимость была существенно ниже. Если мини-компьютер позволил иметь собственную вычислительную машину отделу предприятия или университету, то персональный компьютер дал такую возможность отдельному человеку. Компьютеры стали широко использоваться неспециалистами, что потребовало разработки «дружественного» программного обеспечения, и предоставление этих «дружественных» функций стало прямой обязанностью операционных систем. Персональные компьютеры послужили также мощным катализатором для бурного роста локальных сетей, создав для этого отличную материальную основу в виде десятков и сотен компьютеров, принадлежащих одному предприятию и расположенных в пределах одного здания. В результате поддержка сетевых функций стала для ОС персональных компьютеров необходимым условием. Однако и дружественный интерфейс, и сетевые функции появились у операционных систем персональных компьютеров не сразу. Первая версия наиболее популярyой операционной системы раннего этапа развития персональных компьютеров — MS-DOS компании Microsoft — была лишена этих возможностей. Это была однопрограммная однопользовательская ОС с интерфейсом командной строки, способная стартовать с дискеты. Основными задачами для нее были управление файлами, расположенными на гибких и жестких дисках, а также поочередный запуск программ. MS-DOS не была защищена от программ пользователя, так как процессор Intel 8088 не поддерживал привилегированного режима. Разработчики первых персональных компьютеров считали, что при индивидуальном использовании компьютера и ограниченных возможностях аппаратуры нет смысла в поддержке мультипрограммирования, поэтому в процессоре не были предусмотрены привилегированный режим и другие механизмы поддержки мультипрограммных систем. Иной путь выбрала компания Novell. Она изначально сделала ставку на разработку операционной системы со встроенными сетевыми функциями и добилась на этом пути выдающихся успехов. Ее сетевые операционные системы NetWare на долгое время стали эталоном производительности, надежности и защищенности для локальных сетей. В 1987 году в результате совместных усилий Microsoft и IBM появилась первая многозадачная операционная система для персональных компьютеров с процессором Intel 80286, в полной мере использующая возможности защищенного режима — OS/2. Эта система была хорошо продуманна. Она поддерживала вытесняющую многозадачность, виртуальную память, графический пользовательский интерфейс (не с первой версии) и виртуальную машину для выполнения DOS-приложений. Фактически она выходила за пределы простой многозадачности с ее концепцией распараллеливания отдельных процессов, получившей название многопоточности. Особенности современного этапа развития операционных систем В 90-е годы практически все операционные системы, занимающие заметное место на рынке, стали сетевыми. Сетевые функции сегодня встраиваются в ядро ОС, являясь ее неотъемлемой частью. Операционные системы получили средства для работы со всеми основными технологиями локальных и глобальных сетей, а также средства для создания составных сетей. В операционных системах используются средства мультиплексирования нескольких стеков протоколов, за счет которого компьютеры могут поддерживать одновременную сетевую работу с разнородными клиентами и серверами. Появились специализированные ОС, которые предназначены исключительно для выполнения коммуникационных задач. Например, сетевая операционная система IOS компании Cisco Systems, работающая в маршрутизаторах, организует в мультипрограммном режиме выполнение набора программ, каждая из которых реализует один из коммуникационных протоколов. Во второй половине 90-х годов все производители операционных систем резко усилили поддержку средств работы с Интернетом. Кроме самого стека TCP/IP в комплект поставки начали включать утилиты, реализующие такие популярные сервисы Интернета, как telnet, ftp, DNS и Web. Влияние Интернета проявилось и в том, что компьютер превратился из чисто вычислительного устройства в средство коммуникаций с развитыми вычислительными возможностями. На современном этапе развития операционных систем на передний план вышли средства обеспечения безопасности. Это связано с возросшей ценностью информации, обрабатываемой компьютерами, а также с повышенным уровнем угроз, существующих при передаче данных по сетям, особенно по публичным, таким как Интернет. Многие операционные системы обладают сегодня развитыми средствами защиты информации, основанными на шифрации данных, аутентификации и авторизации. Современным операционным системам присуща многоплатформенностъ, то есть способность работать на совершенно различных типах компьютеров. Многие операционные системы имеют специальные версии для поддержки кластерных архитектур, обеспечивающих высокую производительность и отказоустойчивость. Исключением пока является ОС NetWare, все версии которой разработаны для платформы Intel, а реализации функций NetWare в виде оболочки для других ОС, например NetWare for AIX, успеха на имели. В последние годы получила дальнейшее развитие долговременная тенденция повышения удобства работы человека с компьютером. Эффективность работы человека становится основным фактором, определяющим эффективность вычислительной системы в целом. Усилия человека не должны тратиться на настройку параметров вычислительного процесса, как это происходило в ОС предыдущих поколений. Постоянно повышается удобство интерактивной работы с компьютером путем включения в операционную систему развитых графических интерфейсов, использующих наряду с графикой звук и видеоизображение. Это особенно важно для превращения компьютера в терминал новой публичной сети, которой постепенно становится Интернет, так как для массового пользователя, терминал должен быть почти таким же понятным и удобным, как телефонный аппарат. Пользовательский интерфейс операционной системы становится все более интеллектуальным, направляя действия человека в типовых ситуациях и принимая за него рутинные решения. Уровень удобств в использования ресурсов, которые сегодня предоставляют пользователям, администраторам и разработчикам приложений операционные системы изолированных компьютеров, для сетевых операционных систем является только заманчивой перспективой. Пока пользователи и администраторы сети тратят значительное время на попытки выяснить, где находится тот или иной ресурс, разработчики сетевых приложений прилагают много усилий для определения местоположения данных и программных модулей в сети. Операционные системы будущего должны обеспечить высокий уровень прозрачности сетевых ресурсов, взяв на себя задачу организации распределенных вычислений, превратив сеть в виртуальный компьютер. UNIX-подобные операционные системы. Linux Первоначально UNIX была разработана в конце 1960-х годов сотрудниками Bell Labs, в первую очередь Кеном Томпсоном, Денисом Ритчи и Дугласом МакИлроем. В 1969 году Кен Томпсон, стремясь реализовать идеи, которые были положены в основу MULTICS, но на более скромном аппаратном обеспечении, написал первую версию новой операционной системы, а Брайан Керниган придумал для неё название — UNICS (UNIplexed Information and Computing System — Примитивная информационная и вычислительная служба) — в противовес MULTICS (MULTIplexed Information and Computing Service). Позже это название сократилось до UNIX. В ноябре 1971 года вышла версия для PDP-11, наиболее успешного семейства миникомпьютеров 1970-х. Эта версия получила название «первая редакция» (Edition 1) и была первой официальной версией. Системное время все реализации UNIX отсчитывают с 1 января 1970. Первые версии UNIX были написаны на ассемблере и не имели встроенного компилятора с языком высокого уровня. Со временем стало очевидно, что необходимость переписывать всю систему заново для каждой новой машины — занятие отнюдь не веселое, поэтому Томпсон решил переписать UNIX на языке высокого уровня, который он сам специально разработал и назвал языком В. Язык В представлял собой упрощенную форму языка BCPL. Эта попытка оказалась неудачной из-за слабостей языка В, в первую очередь, из-за отсутствия в нем структур данных. Тогда Ритчи разработал следующий язык, явившийся преемником языка В, который, естественно, получил название С, и написал для него прекрасный компилятор. Вместе Томпсон и Ритчи переписали UNIX на С. Язык С оказался как раз тем языком, который и был нужен в то время, и он сохраняет лидирующие позиции в области системного программирования до сих пор. В 1973 году вышла третья редакция UNIX, со встроенным компилятором языка Си. 15 октября того же года появилась четвёртая редакция, с переписанным на Си системным ядром, а в 1975 — пятая редакция, полностью переписанная на Си. С 1974 года UNIX стал бесплатно распространяться среди университетов и академических учреждений. Калифорнийский университет в Беркли был одним из многих университетов, приобретших UNIX Version 6 практически с момента ее выхода. Поскольку с системой поставлялся полный комплект исходных текстов, университет мог существенно модифицировать систему. При финансовой поддержке управления перспективного планирования научно-исследовательских работ ARPA (Advanced Research Projects Agency) при Министерстве обороны США университет в Беркли разработал и выпустил улучшенную версию операционной системы UNIX для мини-компьютера PDP-11, названую 1BSD (First Berkeley Software Distribution — программное изделие Калифорнийского университета, 1-я версия). Cистема 4BSD (включая 4.1 BSD, 4.2BSD, 4.3BSD и 4.4BSD) содержала большое количество усовершенствований. Важнейшими из них были использование виртуальной памяти и страничная подкачка файлов, что позволяло создавать программы, большие по размеру, чем физическая память. Другое изменение заключалось в поддержке имен файлов длиной более 14 символов. Реализация файловой системы также была изменена, благодаря чему работа с файловой системой стала существенно быстрее. Более надежной стала обработка сигналов. В 4-й версии Berkeley UNIX появилась поддержка сетей, в результате чего используемый в 4 BSD протокол TCP/IP стал стандартом де-факто в мире UNIX, а позднее и в Интернете, в котором преобладают серверы на базе системы UNIX. Университет в Беркли также добавил значительное количество утилит для системы UNIX, включая новый редактор vi и новую оболочку csh, компиляторы языков Pascal и Lisp и многое другое. Все эти усовершенствования привели к тому, что многие производители компьютеров (Sun Microsystems, DEC и другие) стали основывать свои версии системы UNIX на Berkeley UNIX, а не на «официальной» версии компании AT&T, System V. В результате Berkeley UNIX получила широкое распространение в академических и исследовательских кругах. К концу 80-х широкое распространение получили две различные и в чем-то несовместимые версии системы UNIX: 4.3BSD и System V Release 3. Кроме того, практически каждый производитель добавлял свои нестандартные усовершенствования. Этот раскол в мире UNIX, вместе с тем фактом, что стандарта на формат двоичных программ не было, сильно замедлил коммерческое признание операционной системы UNIX. Производители программного обеспечения не могли написать пакет программ для системы UNIX так, чтобы он гарантированно мог быть запущен на любой системе UNIX (как, например, это делалось в системе MS-DOS). Различные попытки стандартизации системы UNIX провалились с самого начала. Например, корпорация AT&T выпустила стандарт SVID (System V Interface Definition — описание интерфейса UNIX System V), в котором определялись все системные вызовы, форматы файлов и т. д. Этот документ был попыткой построить в одну шеренгу всех производителей UNIX System V, но он не оказал никакого влияния на вражеский лагерь (BSD), который просто проигнорировал его. Первая попытка примирить два варианта системы UNIX была предпринята при содействии Совета по стандартам при Институте инженеров по электротехнике и электронике IEEE Standard Boards, глубокоуважаемой и, что еще важнее, нейтральной организации. В этой работе приняли участие сотни людей из промышленности, академических и правительственных организаций. Коллективное название данного проекта — POSIX. Первые три буквы этого сокращения означали Portable Operating System — переносимая операционная система. Буквы IX в конце слова были добавлены, чтобы имя проекта выглядело юниксообразно. После большого количества высказанных аргументов и контраргументов, опровержений и опровергнутых опровержений, комитет POSIX выработал стандарт, известный как 1003.1. Этот стандарт определяет набор библиотечных процедур, которые должна предоставлять каждая соответствующая данному стандарту система UNIX. Идея стандарта POSIX заключается в том, что производитель программного обеспечения при написании программы использует только процедуры, описанные в стандарте 1003.1, таким образом, гарантируя, что эта программа будет работать на любой версии системы UNIX, поддерживающей данный стандарт. Одной из таких систем была ОС MINIX. Основной целью её создания было получить как можно более простую систему, повторяющую функции UNIX, так как размеры исходных кодов UNIX росли и не всегда оставались открытыми. MINIX была разработана специально для студентов и рассчитана на то что они смогут полностью разобраться в ней за один семестр. Однако многим не хватало её функциональности. Наконец через несколько лет финский студент Линус Торвальдс решил сам написать еще один клон системы UNIX, который он назвал Linux. Это должна была быть полноценная операционная система, со многими функциями, отсутствующими (по намерению авторов) в системе MINIX. Первая версия операционной системы Linux 0.01 была выпущена в 1991 году. Она была разработана и собрана в системе MINIX и заимствовала некоторые идеи системы MINIX, начиная со структуры дерева исходных текстов и кончая структурой файловой системы. Новая ОС получила название Linux — в определенной степени случайно: так именовался домашний каталог Линуса на том FTP-сервере, на котором она впервые была выложена для свободного доступа. Наиболее существенные моменты истории создания Linux. Во-первых, следует подчеркнуть, что Линус Торвальдс не занимался адаптацией MINIX (или какого-либо иного варианта UNIX): в своей работе он руководствовался описаниями системных вызовов, данными в соответствующем стандарте POSIX, не привязанными к какой-либо конкретной реализации. В результате Linux не является чистым клоном UNIX: его можно считать первой настоящей POSIX-системой в полном смысле этого слова. А черты сходства с какими-либо вариантами System V или BSD обусловлены только тем, насколько полно все они воплощают соответствующие стандарты. Во-вторых, Linux создавался на машине с процессором i386 для архитектуры Intel и первоначально — только для нее. Более того, долгое время автор вообще сомневался, что его система когда-либо сможет быть портирована на любую иную аппаратную платформу. И потому соответствие стандартам в данном случае преследовало целью не переносимость Linux самого по себе, а в первую очередь возможность компиляции в этой ОС всего ранее созданного программного ассортимента для UNIX и POSIX-совместимых систем вообще. Влияние UNIX на эволюцию операционных систем Идеи, заложенные в основу UNIX, оказали огромное влияние на развитие компьютерных операционных систем. В настоящее время UNIX-системы признаны одними из самых исторически важных ОС. UNIX была написана на языке высокого уровня, а не на ассемблере (доминировавшем в то время). UNIX популяризовала идею иерархической файловой системы с произвольной глубиной вложенности. Другие операционные системы того времени позволяли разбивать дисковое пространство на каталоги или разделы, но число уровней вложенности было фиксировано и, зачастую, уровень вложенности был только один. То, что интерпретатор команд стал просто одной из пользовательских программ, а в качестве дополнительных команд выступают отдельные программы, является ещё одной инновацией Multics, популяризированной UNIX. Язык командной оболочки UNIX используется пользователем как для интерактивной работы, так и для написания скриптов. Так как оболочка и команды операционной системы являются обычными программами, пользователь может выбирать их в соответствии со своими предпочтениями, или даже написать собственную оболочку. Наконец, новые команды можно добавлять к системе без перекомпиляции ядра. Новый, предложенный в командной строке UNIX, способ создания цепочек программ, последовательно обрабатывающих данные, способствовал использованию параллельной обработки данных. Широко используемый в системном программировании язык Си, созданный изначально для разработки UNIX, превзошёл UNIX по популярности. Первые разработчики UNIX способствовали внедрению принципов модульного программирования и повторного использования в инженерную практику. UNIX предоставлял возможность использования протоколов TCP/IP на сравнительно недорогих компьютерах, что привело к быстрому росту Интернета. Это, в свою очередь, способствовало быстрому обнаружению нескольких крупных уязвимостей в системе безопасности, архитектуре и системных утилитах UNIX. Архитектура операционных систем Любая сложная система должна иметь понятную и рациональную структуру, то есть разделяться на части — модули, имеющие вполне законченное функциональное назначение с четко оговоренными правилами взаимодействия. Ясное понимание роли каждого отдельного модуля существенно упрощает работу по модификации и развитию системы. Напротив, сложную систему без хорошей структуры чаще проще разработать заново, чем модернизировать. Функциональная сложность операционной системы неизбежно приводит к сложности ее архитектуры, под которой понимают структурную организацию ОС на основе различных программных модулей. Обычно в состав ОС входят исполняемые и объектные модули стандартных для данной ОС форматов, библиотеки разных типов, модули исходного текста программ, программные модули специального формата (например, загрузчик ОС, драйверы ввода-вывода), конфигурационные файлы, файлы документации, модули справочной системы и т. д. Большинство современных операционных систем представляют собой хорошо структурированные модульные системы, способные к развитию, расширению и переносу на новые платформы. Какой-либо единой архитектуры ОС не существует, но существуют универсальные подходы к структурированию ОС. Ядро и вспомогательные модули ОС Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы: • ядро — модули, выполняющие основные функции ОС;  • модули, выполняющие вспомогательные функции ОС. Модули ядра выполняют такие базовые функции ОС, как управление процессами, памятью, устройствами ввода-вывода и т. п. Ядро составляет основу операционной системы, без него ОС является полностью неработоспособной и не сможет выполнить ни одну из своих функций. В состав ядра входят функции, решающие внутрисистемные задачи организации вычислительного процесса, такие как переключение контекстов, загрузка/выгрузка станиц, обработка прерываний. Эти функции недоступны для приложений. Другой класс функций ядра служит для поддержки приложений, создавая для них так называемую прикладную программную среду. Приложения могут обращаться к ядру с запросами — системными вызовами — для выполнения тех или иных действий, например для открытия и чтения файла, вывода графической информации на дисплей, получения системного времени и т. д. Функции ядра, которые могут вызываться приложениями, образуют интерфейс прикладного программирования — API. Функции, выполняемые модулями ядра, являются наиболее часто используемыми функциями операционной системы, поэтому скорость их выполнения определяет производительность всей системы в целом. Для обеспечения высокой скорости работы ОС все модули ядра или большая их часть постоянно находятся в оперативной памяти, то есть являются резидентными. Ядро является движущей силой всех вычислительных процессов в компьютерной системе, и крах ядра равносилен краху всей системы. Поэтому разработчики операционной системы уделяют особое внимание надежности кодов ядра, в результате процесс их отладки может растягиваться на многие месяцы. Остальные модули ОС выполняют весьма полезные, но менее обязательные функции. Например, к таким вспомогательным модулям могут быть отнесены программы архивирования данных на магнитной ленте, дефрагментации диска, текстового редактора. Вспомогательные модули ОС оформляются либо в виде приложений, либо в виде библиотек процедур. Поскольку некоторые компоненты ОС оформлены как обычные приложения, то есть в виде исполняемых модулей стандартного для данной ОС формата, то часто бывает очень сложно провести четкую грань между операционной системой и приложениями. Решение о том, является ли какая-либо программа частью ОС или нет, принимает производитель ОС. Вспомогательные модули ОС обычно подразделяются на следующие группы: • утилиты — программы, решающие отдельные задачи управления и сопровождения компьютерной системы, такие, например, как программы сжатия дисков, архивирования данных на магнитную ленту; • системные обрабатывающие программы — текстовые или графические редакторы, компиляторы, компоновщики, отладчики; • программы предоставления пользователю дополнительных услуг — специальный вариант пользовательского интерфейса, калькулятор и даже игры; • библиотеки процедур различного назначения, упрощающие разработку приложений, например библиотека математических функций, функций ввода-вывода и т. д. Разделение операционной системы на ядро и модули-приложения обеспечивает легкую расширяемость ОС. Чтобы добавить новую высокоуровневую функцию, достаточно разработать новое приложение, и при этом не требуется модифицировать ответственные функции, образующие ядро системы. Однако внесение изменений в функции ядра может оказаться гораздо сложнее, и сложность эта зависит от структурной организации самого ядра. В некоторых случаях каждое исправление ядра может потребовать его полной перекомпиляции. Модули ОС, оформленные в виде утилит, системных обрабатывающих программ и библиотек, обычно загружаются в оперативную память только на время выполнения своих функций, то есть являются транзитными. Постоянно в оперативной памяти располагаются только самые необходимые коды ОС, составляющие ее ядро. Такая организация ОС экономит оперативную память компьютера. Важным свойством архитектуры ОС, основанной на ядре, является возможность защиты кодов и данных операционной системы за счет выполнения функций ядра в привилегированном режиме. Ядро в привилегированном режиме Для надежного управления ходом выполнения приложений операционная система должна иметь по отношению к приложениям определенные привилегии. Иначе некорректно работающее приложение может вмешаться в работу ОС и, например, разрушить часть ее кодов. Все усилия разработчиков операционной системы окажутся напрасными, если их решения воплощены в незащищенные от приложений модули системы, какими бы элегантными и эффективными эти решения ни были. Операционная система должна обладать исключительными полномочиями также для того, чтобы играть роль арбитра в споре приложений за ресурсы компьютера в мультипрограммном режиме. Ни одно приложение не должно иметь возможности без ведома ОС получать дополнительную область памяти, занимать процессор дольше разрешенного операционной системой периода времени, непосредственно управлять совместно используемыми внешними устройствами. Обеспечить привилегии операционной системе невозможно без специальных средств аппаратной поддержки. Аппаратура компьютера должна поддерживать как минимум два режима работы — пользовательский режим (user mode) и привилегированный режим, который также называют режимом ядра (kernel mode), или режимом супервизора (supervisor mode). Подразумевается, что операционная система или некоторые ее части работают в привилегированном режиме, а приложения — в пользовательском режиме. Так как ядро выполняет все основные функции ОС, то чаще всего именно ядро становится той частью ОС, которая работает в привилегированном режиме (рис. 3.3). Иногда это свойство — работа в привилегированном режиме — служит основным определением понятия «ядро». Рис. 3.3. Архитектура операционной системы с ядром в привилегированном режиме Приложения ставятся в подчиненное положение за счет запрета выполнения в пользовательском режиме некоторых критичных команд, связанных с переключением процессора с задачи на задачу, управлением устройствами ввода-вывода, доступом к механизмам распределения и защиты памяти. Очень важно, что механизмы защиты памяти используются операционной системой не только для защиты своих областей памяти от приложений, но и для защиты областей памяти, выделенных ОС какому-либо приложению, от остальных приложений. Говорят, что каждое приложение работает в своем адресном пространстве. Это свойство позволяет локализовать некорректно работающее приложение в собственной области памяти, так что его ошибки не оказывают влияния на остальные приложения и операционную систему. Повышение устойчивости операционной системы, обеспечиваемое переходом ядра в привилегированный режим, достигается за счет некоторого замедления выполнения системных вызовов. Системный вызов привилегированного ядра инициирует переключение процессора из пользовательского режима в привилегированный, а при возврате к приложению — переключение из привилегированного режима в пользовательский (рис. 3.4). Во всех типах процессоров из-за дополнительной двукратной задержки переключения переход на процедуру со сменой режима выполняется медленнее, чем вызов процедуры без смены режима.  Рис. 3.4. Смена режимов при выполнении системного вызова к привилегированному ядру Архитектура ОС, основанная на привилегированном ядре и приложениях пользовательского режима, стала, по существу, классической. Ее используют многие популярные операционные системы, в том числе многочисленные версии UNIX, VAX VMS, IBM OS/390, OS/2, и с определенными модификациями — Windows NT. В некоторых случаях разработчики ОС отступают от этого классического варианта архитектуры, организуя работу ядра и приложений в одном и том же режиме. Так, известная специализированная операционная система NetWare компании Novell использует привилегированный режим процессоров Intel x86/ Pentium как для работы ядра, так и для работы своих специфических приложений — загружаемых модулей NLM (рис. 3.5). При таком построении ОС обращения приложений к ядру выполняются быстрее, так как нет переключения режимов, однако при этом отсутствует надежная аппаратная защита памяти. Многослойная структура ОС Вычислительную систему, работающую под управлением ОС на основе ядра, можно рассматривать как систему, состоящую из трех иерархически расположенных слоев: нижний слой образует аппаратура, промежуточный — ядро, а утилиты, обрабатывающие программы и приложения, составляют верхний слой системы (рис. 3.6). Слоистую структуру вычислительной системы принято изображать в виде системы концентрических окружностей, иллюстрируя тот факт, что каждый слой может взаимодействовать только со смежными слоями. Действительно, при такой организации ОС приложения не могут непосредственно взаимодействовать с аппаратурой, а только через слой ядра. Рис. 3.6. Трехслойная схема вычислительной системы Многослойный подход является универсальным и эффективным способом декомпозиции сложных систем любого типа, в том числе и программных. В соответствии с этим подходом система состоит из иерархии слоев. Каждый слой обслуживает вышележащий слой, выполняя для него некоторый набор функций, которые образуют межслойный интерфейс (рис. 3.7). На основе функций нижележащего слоя следующий (вверх по иерархии) слой строит свои функции — более сложные и более мощные, которые, в свою очередь, оказываются примитивами для создания еще более мощных функций вышележащего слоя. Строгие правила касаются только взаимодействия между слоями системы, а между модулями внутри слоя связи могут быть произвольными. Отдельный модуль может выполнить свою работу либо самостоятельно, либо обратиться к другому модулю своего слоя, либо обратиться за помощью к нижележащему слою через межслойный интерфейс. Такая организация системы имеет много достоинств. Она существенно упрощает разработку системы, так как позволяет сначала определить «сверху вниз» функции слоев и межслойные интерфейсы, а затем при детальной реализации постепенно наращивать мощность функций слоев, двигаясь «снизу вверх». Кроме того, при модернизации системы можно изменять модули внутри слоя без необходимости производить какие-либо изменения в остальных слоях, если при этих внутренних изменениях межслойные интерфейсы остаются в силе. Поскольку ядро представляет собой сложный многофункциональный комплекс, то многослойный подход обычно распространяется и на структуру ядра. Ядро может состоять из следующих слоев: • Средства аппаратной поддержки ОС. До сих пор об операционной системе говорилось как о комплексе программ, но, вообще говоря, часть функций ОС может выполняться и аппаратными средствами. Поэтому иногда можно встретить определение операционной системы как совокупности программных и аппаратных средств, что и отражено на рис. 3.8. К операционной системе относят, естественно, не все аппаратные устройства компьютера, а только средства аппаратной поддержки ОС, то есть те, которые прямо участвуют в организации вычислительных процессов: средства поддержки привилегированного режима, систему прерываний, средства переключения контекстов процессов, средства защиты областей памяти и т. п. • Машинно-зависимые компоненты ОС. Этот слой образуют программные модули, в которых отражается специфика аппаратной платформы компьютера. В идеале этот слой полностью отделяет вышележащие слои ядра от особенностей аппаратуры. Это позволяет разрабатывать вышележащие слои на основе машинно-независимых модулей, существующих в единственном экземпляре для всех типов аппаратных платформ, поддерживаемых данной ОС. • Базовые механизмы ядра. Этот слой выполняет наиболее примитивные операции ядра, такие как программное переключение контекстов процессов, диспетчеризацию прерываний, перемещение страниц из памяти на диск и обратно и т. п. Модули данного слоя не принимают решений о распределении ресурсов — они только отрабатывают принятые «наверху» решения, что и дает повод называть их исполнительными механизмами для модулей верхних слоев. • Менеджеры ресурсов. Этот слой состоит из мощных функциональных модулей, реализующих стратегические задачи по управлению основными ресурсами вычислительной системы. Обычно на данном слое работают менеджеры (называемые также диспетчерами) процессов, ввода-вывода, файловой системы и оперативной памяти. Каждый из менеджеров ведет учет свободных и используемых ресурсов определенного типа и планирует их распределение в соответствии с запросами приложений. Для исполнения принятых решений менеджер обращается к нижележащему слою базовых механизмов с запросами. Внутри слоя менеджеров существуют тесные взаимные связи, отражающие тот факт, что для выполнения процессу нужен доступ одновременно к нескольким ресурсам — процессору, области памяти, возможно, к определенному файлу или устройству ввода-вывода. Например, при создании процесса менеджер процессов обращается к менеджеру памяти, который должен выделить процессу определенную область памяти для его кодов и данных. • Интерфейс системных вызовов. Этот слой является самым верхним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс операционной системы. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения. Рис. 3.8. Многослойная структура ядра ОС Приведенное разбиение ядра ОС на слои является достаточно условным. В реальной системе количество слоев и распределение функций между ними может быть и иным. Выбор количества слоев ядра является ответственным и сложным делом: увеличение числа слоев ведет к некоторому замедлению работы ядра за счет дополнительных накладных расходов на межслойное взаимодействие, а уменьшение числа слоев ухудшает расширяемость и логичность системы. Обычно операционные системы, прошедшие долгий путь эволюционного развития, например многие версии UNIX, имеют неупорядоченное ядро с небольшим числом четко выделенных слоев, а у сравнительно «молодых» операционных систем, таких как Windows NT, ядро разделено на большее число слоев и их взаимодействие формализовано в гораздо большей степени. Машинно-зависимые компоненты ОС Одна и та же операционная система не может без каких-либо изменений устанавливаться на компьютерах, отличающихся типом процессора или/и способом организации всей аппаратуры. В модулях ядра ОС не могут не отразиться все особенности аппаратной платформы. Однако опыт разработки операционных систем показывает: ядро можно спроектировать таким образом, что только часть модулей будут машинно-зависимыми, а остальные не будут зависеть от особенностей аппаратной платформы. В хорошо структурированном ядре машинно-зависимые модули локализованы и образуют программный слой, естественно примыкающий к слою аппаратуры. Такая локализация машинно-зависимых модулей существенно упрощает перенос операционной системы на другую аппаратную платформу. Объем машинно-зависимых компонентов ОС зависит от того, насколько велики отличия в аппаратных платформах, для которых разрабатывается ОС. Например, ОС, построенная на 32-битовых адресах, для переноса на машину с 16-битовыми адресами должна быть практически переписана заново. Одно из наиболее очевидных отличий — несовпадение системы команд процессоров — преодолевается достаточно просто. Операционная система программируется на языке высокого уровня, а затем соответствующим компилятором вырабатывается код для конкретного типа процессора. Однако во многих случаях различия в организации аппаратуры компьютера лежат гораздо глубже и преодолеть их таким образом не удается. Например, однопроцессорный и двухпроцессорный компьютеры требуют применения в ОС совершенно разных алгоритмов распределения процессорного времени. Аналогично отсутствие аппаратной поддержки виртуальной памяти приводит к принципиальному различию в реализации подсистемы управления памятью. Для компьютеров на основе процессоров Intel x86/Pentium разработка экранирующего машинно-зависимого слоя ОС несколько упрощается за счет встроенной в постоянную память компьютера базовой системы ввода-вывода — BIOS. BIOS содержит драйверы для всех устройств, входящих в базовую конфигурацию компьютера: жестких и гибких дисков, клавиатуры, дисплея и т. д. Эти драйверы выполняют весьма примитивные операции с управляемыми устройствами, но за счет этих операций экранируются различия аппаратных платформ персональных компьютеров на процессорах Intel разных производителей. Разработчики операционной системы могут пользоваться слоем драйверов BIOS как частью машинно-зависимого слоя ОС, а могут и заменить все или часть драйверов BIOS компонентами ОС. Переносимость операционной системы Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую ОС называют переносимой (portable), или мобильной. Хотя ОС часто описываются либо как переносимые, либо как непереносимые, мобильность — это не бинарное состояние, а понятие степени. Вопрос не в том, может ли быть система перенесена, а в том, насколько легко можно это сделать. Для того чтобы обеспечить свойство мобильности ОС, разработчики должны следовать следующим правилам. • Большая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда предполагается переносить систему. Такими языками являются стандартизованные языки высокого уровня. Большинство переносимых ОС написано на языке С, который имеет много особенностей, полезных для разработки кодов операционной системы, и компиляторы которого широко доступны. • Объем машинно-зависимых частей кода, которые непосредственно взаимодействуют с аппаратными средствами, должен быть по возможности минимизирован. Так, например, следует всячески избегать прямого манипулирования регистрами и другими аппаратными средствами процессора. Для уменьшения аппаратной зависимости разработчики ОС должны также исключить возможность использования по умолчанию стандартных конфигураций аппаратуры или их характеристик. Аппаратно-зависимые параметры можно «спрятать» в программно- задаваемые данные абстрактного типа. Для осуществления всех необходимых действий по управлению аппаратурой, представленной этими параметрами, должен быть написан набор аппаратно-зависимых функций. • Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, а не быть распределен по всей системе. Изоляции подлежат все части ОС, которые отражают специфику как процессора, так и аппаратной платформы в целом. Низкоуровневые компоненты ОС, имеющие доступ к процессорно-зависимым структурам данных и регистрам, должны быть оформлены в виде компактных модулей, которые могут быть заменены аналогичными модулями для других процессоров. В идеале слой машинно-зависимых компонентов ядра полностью отделяет остальную часть ОС от конкретных деталей аппаратной платформы, по крайней мере для того набора платформ, который поддерживает данная ОС. В результате происходит подмена реальной аппаратуры некой унифицированной виртуальной машиной, одинаковой для всех вариантов аппаратной платформы. Все слои операционной системы, которые лежат выше слоя машинно-зависимых компонентов, могут быть написаны для управления именно этой виртуальной аппаратурой. Таким образом, у разработчиков появляется возможность создавать один вариант машинно-независимой части ОС для всего набора поддерживаемых платформ (рис. 3.9). Рис. 3.9. Перенос операционной системы на разные аппаратные платформы Микроядерная архитектура Микроядерная архитектура является альтернативой классическому способу построения операционной системы. Под классической архитектурой в данном случае понимается рассмотренная выше структурная организация ОС, в соответствии с которой все основные функции операционной системы, составляющие многослойное ядро, выполняются в привилегированном режиме. При этом некоторые вспомогательные функции ОС оформляются в виде приложений и выполняются в пользовательском режиме наряду с обычными пользовательскими программами (становясь системными утилитами или обрабатывающими программами). Каждое приложение пользовательского режима работает в собственном адресном пространстве и защищено тем самым от какого-либо вмешательства других приложений. Код ядра, выполняемый в привилегированном режиме, имеет доступ к областям памяти всех приложений, но сам полностью от них защищен. Приложения обращаются к ядру с запросами на выполнение системных функций. Суть микроядерной архитектуры состоит в следующем. В привилегированном режиме остается работать только очень небольшая часть ОС, называемая микроядром (рис. 3.10). Микроядро защищено от остальных частей ОС и приложений. В состав микроядра обычно входят машинно-зависимые модули, а также модули, выполняющие базовые (но не все!) функции ядра. Набор функций микроядра обычно соответствует функциям слоя базовых механизмов обычного ядра. Такие функции операционной системы трудно, если не невозможно, выполнить в пространстве пользователя. Рис. 3.10. Перенос основного объема функций ядра в пользовательское пространство Все остальные более высокоуровневые функции ядра оформляются в виде приложений, работающих в пользовательском режиме. Однозначного решения о том, какие из системных функций нужно оставить в привилегированном режиме, а какие перенести в пользовательский, не существует. В общем случае многие менеджеры ресурсов, являющиеся неотъемлемыми частями обычного ядра — файловая система, подсистемы управления виртуальной памятью и процессами, менеджер безопасности и т. п., — становятся «периферийными» модулями, работающими в пользовательском режиме. Работающие в пользовательском режиме менеджеры ресурсов имеют принципиальные отличия от традиционных утилит и обрабатывающих программ операционной системы, хотя при микроядерной архитектуре все эти программные компоненты также оформлены в виде приложений. Утилиты и обрабатывающие программы вызываются в основном пользователями. Ситуации, когда одному приложению требуется выполнение функции (процедуры) другого приложения, возникают крайне редко. Поэтому в операционных системах с классической архитектурой отсутствует механизм, с помощью которого одно приложение могло бы вызвать функции другого. Совсем другая ситуация возникает, когда в форме приложения оформляется часть операционной системы. По определению, основным назначением такого приложения является обслуживание запросов других приложений, например создание процесса, выделение памяти, проверка прав доступа к ресурсу и т. д. Именно поэтому менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами ОС, то есть модулями, основным назначением которых является обслуживание запросов локальных приложений и других модулей ОС. Очевидно, что для реализации микроядерной архитектуры необходимым условием является наличие в операционной системе удобного и эффективного способа вызова процедур одного процесса из другого. Поддержка такого механизма и является одной из главных задач микроядра. Схематично механизм обращения к функциям ОС, оформленным в виде серверов, выглядит следующим образом (рис. 3.11). Клиент, которым может быть либо прикладная программа, либо другой компонент ОС, запрашивает выполнение некоторой функции у соответствующего сервера, посылая ему сообщение. Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы друг от друга. Микроядро, выполняющееся в привилегированном режиме, имеет доступ к адресным пространствам каждого из этих приложений и поэтому может работать в качестве посредника. Микроядро сначала передает сообщение, содержащее имя и параметры вызываемой процедуры нужному серверу, затем сервер выполняет запрошенную операцию, после чего ядро возвращает результаты клиенту с помощью другого сообщения. Таким образом, работа микроядерной операционной системы соответствует известной модели клиент-сервер, в которой роль транспортных средств выполняет микроядро. Рис. 3.11. Реализация системного вызова в микроядерной архитектуре   Преимущества и недостатки микроядерной архитектуры Операционные системы, основанные на концепции микроядра, в высокой степени удовлетворяют большинству требований, предъявляемых к современным ОС, обладая переносимостью, расширяемостью, надежностью и создавая хорошие предпосылки для поддержки распределенных приложений. За эти достоинства приходится платить снижением производительности, и это является основным недостатком микроядерной архитектуры. Высокая степень переносимости обусловлена тем, что весь машинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше изменений и все они логически сгруппированы вместе. Расширяемость присуща микроядерной ОС в очень высокой степени. В традиционных системах даже при наличии многослойной структуры нелегко удалить один слой и поменять его на другой по причине множественности и размытости интерфейсов между слоями. Добавление новых функций и изменение существующих требует хорошего знания операционной системы и больших затрат времени. В то же время ограниченный набор четко определенных интерфейсов микроядра открывает путь к упорядоченному росту и эволюции ОС. Добавление новой подсистемы требует разработки нового приложения, что никак не затрагивает целостность микроядра. Микроядерная структура позволяет не только добавлять, но и сокращать число компонентов операционной системы, что также бывает очень полезно. Например, не всем пользователям нужны средства безопасности или поддержки распределенных вычислений, а удаление их из традиционного ядра чаще всего невозможно. Обычно традиционные операционные системы позволяют динамически добавлять в ядро или удалять из ядра только драйверы внешних устройств — ввиду частых изменений в конфигурации подключенных к компьютеру внешних устройств подсистема ввода-вывода ядра допускает загрузку и выгрузку драйверов «на ходу», но для этого она разрабатывается особым образом. При микроядерном подходе конфигурируемость ОС не вызывает никаких проблем и не требует особых мер — достаточно изменить файл с настройками начальной конфигурации системы или же остановить не нужные больше серверы в ходе работы обычными для остановки приложений средствами. Использование микроядерной модели повышает надежность ОС. Каждый сервер выполняется в виде отдельного процесса в своей собственной области памяти и таким образом защищен от других серверов операционной системы, что не наблюдается в традиционной ОС, где все модули ядра могут влиять друг на друга. И если отдельный сервер терпит крах, то он может быть перезапущен без останова или повреждения остальных серверов ОС. Более того, поскольку серверы выполняются в пользовательском режиме, они не имеют непосредственного доступа к аппаратуре и не могут модифицировать память, в которой хранится и работает микроядро. Другим потенциальным источником повышения надежности ОС является уменьшенный объем кода микроядра по сравнению с традиционным ядром — это снижает вероятность появления ошибок программирования. Модель с микроядром хорошо подходит для поддержки распределенных вычислений, так как использует механизмы, аналогичные сетевым: взаимодействие клиентов и серверов путем обмена сообщениями. Серверы микроядерной ОС могут работать как на одном, так и на разных компьютерах. В этом случае при получении сообщения от приложения микроядро может обработать его самостоятельно и передать локальному серверу или же переслать по сети микроядру, работающему на другом компьютере. Переход к распределенной обработке требует минимальных изменений в работе операционной системы — просто локальный транспорт заменяется на сетевой. Производительность. При классической организации ОС (рис. 3.12, а) выполнение системного вызова сопровождается двумя переключениями режимов, а при микроядерной организации (рис. 3.12, 6) — четырьмя. Таким образом, операционная система на основе микроядра при прочих равных условиях всегда будет менее производительной, чем ОС с классическим ядром. Именно по этой причине микроядерный подход не получил такого широкого распространения, которое ему предрекали. Рис. 3.12. Смена режимов при выполнении системного вызова Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT. В версиях 3.1 и 3.5 диспетчер окон, графическая библиотека и высокоуровневые драйверы графических устройств входили в состав сервера пользовательского режима, и вызов функций этих модулей осуществлялся в соответствии с микроядерной схемой. Однако очень скоро разработчики Windows NT поняли, что такой механизм обращений к часто используемым функциям графического интерфейса существенно замедляет работу приложений и делает данную операционную систему уязвимой в условиях острой конкуренции. В результате в версию Windows NT 4.0 были внесены существенные изменения — все перечисленные выше модули были перенесены в ядро, что отдалило эту ОС от идеальной микроядерной архитектуры, но зато резко повысило ее производительность. Этот пример иллюстрирует главную проблему, с которой сталкиваются разработчики операционной системы, решившие применить микроядерный подход, — что включать в микроядро, а что выносить в пользовательское пространство. В идеальном случае микроядро может состоять только из средств передачи сообщений, средств взаимодействия с аппаратурой, в том числе средств доступа к механизмам привилегированной защиты. Однако многие разработчики не всегда жестко придерживаются принципа минимизации функций ядра, часто жертвуя этим ради повышения производительности. В результате реализации ОС образуют некоторый спектр, на одном краю которого находятся системы с минимально возможным микроядром, а на другом — системы, подобные Windows NT, в которых микроядро выполняет достаточно большой объем функций. Совместимость и множественные прикладные среды В то время как многие архитектурные особенности операционных систем непосредственно касаются только системных программистов, концепция множественных прикладных сред непосредственно связана с нуждами конечных пользователей — возможностью операционной системы выполнять приложения, написанные для других операционных систем. Такое свойство операционной системы называется совместимостью.   Двоичная совместимость и совместимость исходных текстов Необходимо различать совместимость на двоичном уровне и совместимость на уровне исходных текстов. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение в среде другой ОС. Совместимость на уровне исходных текстов требует наличия соответствующего компилятора в составе программного обеспечения компьютера, на котором предполагается выполнять данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый исполняемый модуль. Совместимость на уровне исходных текстов важна в основном для разработчиков приложений, в распоряжении которых эти исходные тексты всегда имеются. Но для конечных пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут использовать один и тот же коммерческий продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на различных машинах. Гораздо сложнее достичь двоичной совместимости операционным системам, предназначенным для выполнения на процессорах, имеющих разные архитектуры. Помимо соблюдения приведенных выше условий необходимо организовать эмуляцию двоичного кода. Для того чтобы компьютер смог интерпретировать машинные инструкции, которые ему изначально непонятны, на нем должно быть установлено специальное программное обеспечение — эмулятор. Эмулятор должен последовательно выбирать каждую двоичную инструкцию первого процессора, программным способом дешифрировать ее, чтобы определить, какие действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в инструкциях второго процессора. Так как к тому же у второго процессора нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как у первого, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти. Состояние эмулируемых регистров и флагов после выполнения каждой команды должно быть абсолютно таким же, как и в реальном процессоре первого типа. Это простая, но очень медленная работа, так как одна команда первого процессора исполняется значительно быстрее, чем эмулирующая его последовательность команд на втором процессоре. Трансляция библиотек Выходом в таких случаях является использование так называемых прикладных программных сред. Одной из составляющих, формирующих прикладную программную среду, является набор функций интерфейса прикладного программирования API, которые операционная система предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращения к библиотечным функциям. Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графических интерфейсов пользователя), при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые действия. Они непрерывно выполняют вызовы библиотек GUI для манипулирования окнами и для других связанных с GUI действий. Сегодня в типичных программах 60-80 % времени тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на «родном» коде. Таким образом достигается существенное ускорение выполнения программ с API другой операционной системы. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз. Чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Концепции, положенные в основу разных ОС, могут входить в противоречие друг с другом. Для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера.   Способы реализации прикладных программных сред Создание полноценной прикладной среды, полностью совместимой со средой другой операционной системы, является достаточно сложной задачей, тесно связанной со структурой операционной системы. Один из наиболее очевидных вариантов реализации множественных прикладных сред основывается на стандартной многоуровневой структуре ОС. На рис. 3.13 операционная система OS1 поддерживает кроме своих «родных» приложений приложения операционных систем OS2 и OS3. Для этого в ее составе имеются специальные приложения — прикладные программные среды, — которые транслируют интерфейсы «чужих» операционных систем API OS2 и API OS3 в интерфейс своей «родной» операционной системы — API OS1. Рис. 3.13. Прикладные программные среды, транслирующие системные вызовы К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов. В приведенном на рис. 3.14 примере операционная система поддерживает приложения, написанные для OS1, OS2 и OS3. Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3. В этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем случае несовместимые прикладные среды. В разных ОС по-разному осуществляется управление системным временем, используется разный формат времени дня, на основании собственных алгоритмов разделяется процессорное время и т. д. Функции каждого API реализуются ядром с учетом специфики соответствующей ОС, даже если они имеют аналогичное назначение. Аналогично при завершении процесса ядру также необходимо определять, к какой ОС относится данный процесс. Для того чтобы ядро могло выбрать нужный вариант реализации системного вызова, каждый процесс должен передавать в ядро набор идентифицирующих характеристик. Рис. 3.14. Реализация совместимости на основе нескольких равноправных API Еще один способ построения множественных прикладных сред основан на микроядерном подходе. При этом очень важно отделить базовые, общие для всех прикладных сред, механизмы операционной системы от специфических для каждой из прикладных сред высокоуровневых функций, решающих стратегические задачи. В соответствии с микроядерной архитектурой все функции ОС реализуются микроядром и серверами пользовательского режима. Важно, что каждая прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов (рис. 3.15). Приложения, используя API, обращаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает приложению результат. В ходе выполнения запроса прикладной среде приходится, в свою очередь, обращаться к базовым механизмам ОС, реализуемым микроядром и другими серверами ОС. Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры. Рис. 3.15. Микроядерный подход к реализации множественных прикладных сред Создание в рамках одной операционной системы нескольких прикладных сред для выполнения приложений различных ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее между операционными системами. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной ОС с приложениями, написанными для других ОС. В результате пользователи получают большую свободу выбора операционных систем и более легкий доступ к качественному программному обеспечению. Структура ОС Linux Ядро Linux, произносится (также GNU/Linux) — общее название Unix-подобных операционных систем на основе одноимённого ядра и собранных для него библиотек и системных программ. В любой операционной системе можно выделить 4 основных части: ядро, файловую структуру, интерпретатор команд пользователя и утилиты. Ядро — это основная, определяющая часть ОС, которая управляет аппаратными средствами и выполнением программ. Файловая структура — это система хранения файлов на запоминающих устройствах. Интерпретатор команд или оболочка — это программа, организующая взаимодействие пользователя с компьютером. И, наконец, утилиты — это просто отдельные программы, которые, вообще говоря, ничем принципиально не отличаются от других программ, запускаемых пользователем, разве только своим основным назначением — они выполняют служебные функции. Схематично взаимодействие основных частей операционной системы можно изобразить следующим рисунком: Графические оболочки Linux — это операционная система, унаследовавшая от Unix прежде всего возможность работы из командной строки. Однако в век развития цифровых технологий было бы неразумно использовать только те возможности системы, которые так или иначе связаны с использованием командной строки. Фактически, работа пользователя с персональным компьютером была бы ограничена только вводом и выводом текстовой информации и воспроизведением файлов ограниченного числа форматов. Большие и многогранные программные пакеты, будь то офисные приложения, текстовые процессоры или приложения для работы с графикой, были бы недоступны. Конечно, командная строка незаменима во многих операциях, и в этом вам уже, наверное, удалось убедиться после прочтения главы, описывающей приемы работы с ней. Однако для тех пользователей, которым не нужно проводить тонкую настройку системы или администрировать компьютерную сеть, использование командной строки в повседневной работе может оказаться обременительным. Поэтому для работы с пользовательскими приложениями и программами, а также и из эстетических соображений в Linux была создана графическая система X Window. X Window System — оконная система, обеспечивающая стандартные инструменты и протоколы для построения графического интерфейса пользователя. X Window System обеспечивает базовые функции графической среды: отрисовку и перемещение окон на экране, взаимодействие с мышью и клавиатурой. X Window System не определяет деталей интерфейса пользователя — этим занимаются среды рабочего стола и менеджеры окон, которых разработано множество. По этой причине внешний вид программ в среде X Window System может очень сильно различаться в зависимости от возможностей и настроек конкретного оконного менеджера. Наиболее известными представителями сред рабочего стола являются KDE (K Desktop Enviroment) и GNOME (GNU Network Object Model Environment). В X Window System предусмотрена сетевая прозрачность: графические приложения могут выполняться на другой машине в сети, а их интерфейс при этом будет передаваться по сети и отображаться на локальной машине пользователя (в случае если это разрешено в настройках). В контексте X Window System термины «клиент» и «сервер» имеют непривычное для многих пользователей значение: «сервер» означает локальный дисплей пользователя (дисплейный сервер), а «клиент» — программу, которая этот дисплей использует (она может выполняться на удалённом компьютере). Дистрибутив Дистрибутив (от англ. distribute — распространять) — это набор программного обеспечения, включающий все 4 основные составные части ОС, то есть ядро, файловую систему, оболочку и совокупность утилит. Наличие дистрибутивов вызвано тем, что форма программного обеспечения, используемая для его распространения, почти никогда не совпадает с формой программного обеспечения работающей системы. Однако различные дистрибутивы отличаются друг от друга по составу включенных в них программ, они содержат как стандартные для всех дистрибутивов программы (например, оболочку bash или ядро, хотя версии ядра и оболочки тоже могут быть выбраны различные в разных дистрибутивах), так и уникальные разработки авторов дистрибутива, например, программы для конфигурирования системы, разные графические оболочки, утилиты для работы с ядром и т. д. Дистрибутив обычно содержит программы для начальной инициализации системы (инициализация аппаратной части, загрузка урезанной версии системы и запуск программы-установщика), программу-установщик (для выбора режимов и параметров установки) и набор специальных файлов, содержащих отдельные части системы (так называемые пакеты). Программа установки позволяет также произвести первичную настройку системы. Дистрибутивы включают следующие компоненты: • Программа-загрузчик. Инициализация аппаратной части, загрузка (обычно) урезанной версии системы, инициализация носителей. • Программа установки. Выбор параметров установки и пакетов для установки • Программа начальной конфигурации. Начальное конфигурирование системы • Наборы пакетов. Наличие программ, необходимых пользователю, специализированность дистрибутива (общего назначения, спасательные, «живые», микро и т. д., а также ориентированность на решение конкретных задач — кластерные дистрибутивы, дистрибутивы для специфических областей науки и т. д.) • Программа управления пакетами. Установка пакетов на работающую систему, обновление пакетов и т. д. Linux иногда отождествляют с определенным дистрибутивом, называя так всю систему в целом. Это не совсем правильно. Linux — это отнюдь не самый первый дистрибутив и уж, тем более, не современная его разновидность. Linux — это только ядро системы, упрощенно говоря, самая главная ее часть, вокруг которой и объединены все компоненты системы. Поэтому правильнее говорить не «Linux», а «операционная система на основе ядра Linux», хотя первый термин сейчас более распространен, так что для краткости можно использовать и его. Ядра Linux выпускаются и обновляются постоянно, не зависимо от развития того или иного дистрибутива. Физическая структура жёсткого диска Сектора Любой жёсткий диск можно представить как огромный «чистый лист», на который можно записывать данные и откуда потом их можно считать. Чтобы ориентироваться на диске, всё его пространство разбивают на небольшие «клеточки» — сектора. Сектор — это минимальная единица хранения данных на диске, обычно его размер составляет 512 байт. Все сектора на диске нумеруются: каждый из n секторов получает номер от 0 до n–1. Благодаря этому любая информация, записанная на диск, получает точный адрес — номера соответствующих секторов. Так что диск ещё можно представить как очень длинную строчку (ленточку) из секторов. На жестком диске минимальным адресуемым элементом является кластер, который содержит несколько секторов. Таблица FAT16 может адресовать 216 = 65 536 кластеров. Для дисков большой емкости размер кластера оказывается слишком большим, так как информационная емкость жестких дисков может достигать 150 Гбайт. Например, для диска объемом 40 Гбайт размер кластера будет равен: 40 Гбайт/65536 = 655 360 байт = 640 Кбайт. Раздел. Виды разделов Представлять жёсткий диск как единый «лист» не всегда бывает удобно: иногда полезно «разрезать» его на несколько независимых листов, на каждом из которых можно писать и стирать что угодно, не опасаясь повредить написанное на других листах. Логичнее всего записывать раздельно данные большей и меньшей важности или просто относящиеся к разным вещам. Конечно, над жёстким диском следует производить не физическое, а логическое разрезание, для этого вводится понятие раздел (partition). Вся последовательность (очень длинная ленточка) секторов разрезается на несколько частей, каждая часть становится отдельным разделом. На одном физическом диске можно создать несколько разделов. Как правило, разделы создают для того, чтобы иметь возможность установки нескольких операционных систем или переноса пользовательских файлов на раздел, отличный от того, на который установлена ОС. Раздел (англ. partition) — часть долговременной памяти жёсткого диска, выделенная для удобства работы, и состоящая из смежных блоков. Выделение на одном жёстком диске нескольких разделов даёт следующие преимущества: • на одном физическом жёстком диске можно хранить информацию в разных файловых системах, или в одинаковых файловых системах, но с разным размером кластера (например, выгодно хранить файлы большого размера — например, видео — отдельно от маленьких, и задавать больший размер кластера для хранилища больших файлов); • можно отделить информацию пользователя от файлов операционной системы; • на одном жёстком диске можно установить несколько операционных систем; • манипуляции с одной файловой системой не сказываются на других файловых системах. Таблица разделов Технически разбиение диска на разделы организовано следующим образом: заранее определённая часть диска отводится под таблицу разделов, в которой и написано, как разбит диск. Стандартная таблица разделов для диска IBM-совместимого компьютера — HDPT (Hard Disk Partition Table) — располагается в конце самого первого сектора диска, после предзагрузчика (Master Boot Record, MBR) и состоит из четырёх записей вида «тип начало конец», по одной на каждый раздел. Начало и конец — это номера тех секторов диска, где начинается и заканчивается раздел. С помощью такой таблицы диск можно поделить на четыре или меньше разделов: если раздела нет, тип устанавливается в 0. Однако четырёх разделов редко когда бывает достаточно. Куда же помещать дополнительные поля таблицы разбиения? Создатели IBM PC предложили универсальный способ: один из четырёх основных разделов объявляется расширенным (extended partition); он, как правило, является последним и занимает всё оставшееся пространство диска. Расширенный раздел можно разбить на подразделы тем же способом, что и весь диск: в самом начале — на этот раз не диска, а самого раздела — заводится таблица разделов, с записями для четырёх разделов, которые снова можно использовать, причём один из подразделов может быть, опять-таки, расширенным, со своими подразделами и т. д. Разделы, упомянутые в таблице разделов диска, принято называть основными или первичными (primary partition), а все подразделы расширенных разделов — дополнительными (secondary partition). Так что основных разделов может быть не более четырёх, а дополнительных — сколько угодно. На диске может быть не более четырех основных разделов, а при наличии дополнительного раздела основных разделов может быть не более трех. Дополнительный раздел выступает в качестве контейнера, в котором можно создать один или несколько логических дисков. Разница между основным и дополнительным разделами заключается в том, что основной раздел может использоваться для запуска операционной системы, а с логических дисков дополнительного раздела запустить ОС нельзя. Раздел, на котором размещаются файлы, необходимые для запуска операционной системы, помечается и называется активным. На физическом диске может быть только один активный раздел. А раздел, содержащий системные файлы ОС Windows, называется загрузочным, и таких разделов может быть несколько (например, в конфигурациях с несколькими установленными ОС). Главная загрузочная запись и загрузочный сектор Главная загрузочная запись (англ. master boot record, MBR) — это код и данные, необходимые для загрузки операционной системы (ОС), и расположенные в первых физических секторах (чаще всего в самом первом) на жёстком диске или другом устройстве хранения информации. MBR содержит небольшой фрагмент исполняемого кода, таблицу разделов (partition table) и специальную сигнатуру. Цель MBR — ещё не загрузка ОС, а всего лишь выбор, «с какого раздела жёсткого диска следует загружать ОС». На стадии MBR происходит выбор раздела диска и ничего более. Загрузка самой ОС происходит на более поздних этапах. В процессе запуска компьютера после окончания начального теста (Power On Self Test, POST) MBR загружается базовой системой ввода-вывода (BIOS) в оперативную память Загрузочный сектор — это особый сектор на жёстком диске, дискете или другом дисковом устройстве хранения информации. Загрузочный сектор, расположенный в секторе 1 каждого тома, является структурой, обеспечивающей запуск компьютера. В этом секторе содержатся исполняемый код и данные, которые требует этот код, включая информацию о файловой системе, используемой на данном томе. Загрузочный сектор создается при форматировании тома. В конце загрузочного сектора размещается двухбайтовая структура, называемая маркером конца сектора. Загрузочный сектор, иногда называемый stage1, то есть первым этапом загрузки операционной системы, загружает программу второго этапа загрузки операционной системы (вторичный загрузчик, иногда в качестве него загружается boot manager или программа авторизации и защиты доступа). (В некоторых ОС роль stage1 выполняет MBR и при загрузке ОС с жесткого диска загрузочный сектор не используется. На незагружаемых разделах жесткого диска загрузочные секторы также могут не содержать программу загрузки) Начальная загрузка Большинство компьютерных систем могут исполнять только команды, находящиеся в оперативной памяти компьютера, в то время как современные операционные системы в большинстве случаев хранятся на жёстких дисках, загрузочных CDROM-ах, USB дисках или в локальной сети. После включения компьютера в его оперативной памяти нет операционной системы. Само по себе, без операционной системы, аппаратное обеспечение компьютера не может выполнять сложные действия, такие как, например, загрузку программы в память. Таким образом мы сталкиваемся с парадоксом, который кажется неразрешимым: для того, чтобы загрузить операционную систему в память, мы уже должны иметь операционную систему в памяти. Решением данного парадокса является использование специальной маленькой компьютерной программы, называемой начальным загрузчиком, или BIOS (Basic Input/Output System). Эта программа не обладает всей функциональностью операционной системы, но её достаточно для того, чтобы загрузить другую программу, которая будет загружать операционную систему. Часто используется многоуровневая загрузка, в которой несколько небольших программ вызывают друг друга до тех пор, пока одна из них не загрузит операционную систему. В современных компьютерах процесс начальной загрузки начинается с выполнения процессором команд, расположенных в постоянной памяти (например на IBM PC — команд BIOS), начиная с предопределённого адреса (процессор делает это после перезагрузки без какой бы то ни было помощи). Данное программное обеспечение может обнаруживать устройства, подходящие для загрузки, и загружать со специального раздела выбранного устройства (чаще всего загрузочного сектора данного устройства) загрузчик ОС. Начальные загрузчики должны соответствовать специфическим ограничениям, особенно это касается объёма. Например, на IBM PC загрузчик первого уровня должен помещаться в первых 446 байт главной загрузочной записи, оставив место для 64 байт таблицы разделов и 2 байта для сигнатуры AA55, необходимой для того, чтобы BIOS выявил сам начальный загрузчик. Загрузчик операционной системы Загрузчик операционной системы — системное программное обеспечение, обеспечивающее загрузку операционной системы непосредственно после включения компьютера. Загрузчик операционной системы: • обеспечивает необходимые средства для диалога с пользователем компьютера (например, загрузчик позволяет выбрать операционную систему для загрузки); • приводит аппаратуру компьютера в состояние, необходимое для старта ядра операционной системы (например, на не-x86 архитектурах перед запуском ядра загрузчик должен правильно настроить виртуальную память); • загружает ядро операционной системы в ОЗУ. Загрузка ядра операционной системы не обязательно происходит с жесткого диска. Загрузчик может получать ядро по сети. Ядро может храниться в ПЗУ или загружаться через последовательные интерфейсы (это может пригодиться на ранней стадии отладки создаваемой компьютерной системы); • формирует параметры, передаваемые ядру операционной системы (например, ядру Linux передаются параметры, указывающие способ подключения корневой файловой системы); • передаёт управление ядру операционной системы. На компьютерах архитектуры IBM PC запуск загрузчика осуществляется программным обеспечением BIOS, записанной в ПЗУ компьютера, после успешного окончания процедуры POST. Опишем процедуру, с помощью которой происходит загрузка с НЖМД IBM PC: BIOS производит чтение 512 байт первого сектора НЖМД (MBR) в ОЗУ по адресу 0x00007C00 (0x07C0:0x0000 в формате реального режима), затем прочитанному коду передаётся управление. Этот код читает и анализирует таблицу разделов жёсткого диска, а затем, в зависимости от вида загрузчика, либо передаёт управление загрузочному коду активного раздела жёсткого диска, либо самостоятельно загружает ядро с диска в оперативную память и передаёт ему управление. Распространённые загрузчики: • NTLDR — загрузчик ядра Windows NT • Windows Boot Manager (bootmgr.exe, winload.exe) — загрузчик ядра Windows Vista • LILO (LInux LOader) — загрузчик, в основном применяемый для загрузки ядра Linux • GRUB (Grand Unified Bootloader) — применяется для загрузки ядра Linux • Acronis os selector — коммерческая графическая утилита, прилагаемая к Acronis disk director, поддерживает windows и linux Файловая система Linux С точки зрения пользователя, файловая система — это логическая структура каталогов и файлов. В отличие от Windows, где каждый логический диск хранит отдельное дерево каталогов, во всех UNIX-подобных системах эта древовидная структура растет из одного корня: она начинается с корневого каталога, родительского по отношению ко всем остальным, а физические файловые системы разного типа, находящиеся на разных разделах и даже на удаленных машинах, представляются как ветви этого дерева. Имена файлов и каталогов могут иметь длину до 255 символов. Символы «/» (слэш) и символ с кодом 0 запрещены. Кроме того, ряд символов имеет специальное значение для командного интерпретатора, и их использование не рекомендуется. Это символы: ~!@#$&%*()[]{}'"\:;><`пробел Точки среди специальных символов нет, и имена вроде this.is.a.text.file.containing.the.famous.string.hello.world допустимы и широко распространены. Часто последняя отделенная точкой часть имени используется подобно «расширению имени» в Windows, обозначая файл определенного типа, но это обозначение несет смысл только для человека. Если имя файла начинается с точки, то этот файл считается скрытым: некоторые команды его «не видят». Linux различает регистр символов в именах файлов: так, в одном каталоге могут находиться два разных файла README и Readme. Полным именем файла (или путем к файлу) называется список вложенных друг в друга каталогов, заканчивающийся собственно именем файла. Начинаться он может с любого каталога, потому что в древовидной структуре между любыми двумя узлами существует путь. Если этот список начинается с корневого каталога, то путь называется абсолютным. Если с любого другого — то относительным (по отношению к этому каталогу). Устройство файловой системы linux очень сильно отличается от устройства в windows. Для начала, в линуксе нет дисков C или D. Один физический диск (или несколько) при установке системы разбивается на каталоги и подкаталоги. Основной, корневой каталог обозначается символом / (слэш) Вместо файла подкачки существует отдельный раздел /swap. Каждый каталог можно форматировать в нужную файловую систему, в зависимости от задач пользователя. Например Ext3, ReiserFS, JFS или другую. В разных дистрибутивах линукс схема и назначение некоторых каталогов может несколько отличаться. Большинство файловых систем, используемых Linux являются журналируемыми. Журналируемая файловая система перед тем, как что-то сделать с файлами, записывает на диск некое описание планируемой операции и вычеркивает каждый пункт плана только после того, как он успешно выполнен. Тогда после сбоя можно будет не проверять на целостность весь огромный раздел, а только просмотреть журнал и откатить незаконченные операции. Целью журналирования является обеспечение целостности файловой системы, а не сохранность пользовательских данных как таковых. Журналировать операции записи самих данных тоже можно: в этом случае есть вероятность, что данные после сбоя будут восстановлены. Правда, согласно золотому правилу механики, за все нужно платить, и платить приходится быстродействием. Решают вопрос разными ухищрениями: например, запись происходит в момент наименьшей активности, некоторые журналируемые файловые системы позволяют разместить журнал на другом физическом диске. Да и фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И, естественно, некоторый полезный объем теперь приходится отводить под сам журнал, но его размеры обычно не превышают 32 Мбайт, что по нынешним временам не так уж и много. Точка монтирования Рано или поздно пользователи Linux сталкиваются с таким понятием как монтирование разделов и дисков в Linux. Многие, особенно бывшие пользователи Windows, испытывают трудности с монтированием разделов, хотя если задуматься, то всё очень просто и логично. Ниже приводятся описание процесса монтирования в UNIX-like системах и разбор наиболее типичных случаев. И даже если вы окружены графическим интерфейсом, знание консольных команд может очень пригодиться. Кроме того, узнав пару-тройку полезных команд UNIX, вы приобщитесь к этой чёрной магии и, может быть, начнёте её использовать. Если ядро Linux опознало ваше устройство-носитель данных, то оно должно предоставить какой-то внешний интерфейс пользователю для работы с устройством. Этим интерфейсом является создание файлов-устройств в каталоге /dev Пример: Устройствам, подключённым к IDE, будут соответствовать файлы-устройства /dev/hda, /dev/hdb и так далее. Устройствам типа SCSI, а также близкие им по духу SATA-устройства и USB-флешки, будут иметь файлы-устройства /dev/sda, /dev/sdb и тому подобное. Если на диске есть разделы, то цифра в имени файла-устройства будет соответствовать номеру раздела. Пример: если на USB-флешке есть два раздела, то первый будет называться /dev/sda1, а второй /dev/sda2 Монтирование файловой системы — процесс, подготавливающий раздел диска к использованию операционной системой. Монтирование разделов = объяснение системе, как добраться до ваших данных и сделать их доступными для использования. Системе нужно объяснить три простые вещи: • какая файловая система на разделе; • какой файл-устройство вам нужно; • куда его подключить для просмотра = точка монтирования; Каталог, в котором вы будете просматривать содержимое ваших разделов, называется точкой монтирования (mount point). Поэтому нужно объяснить системе — командой или через графический интерфейс - что вы хотите смонтировать, куда и что за файловая система на этом разделе. В переводе на язык UNIX, это звучит так: mount -t vfat /dev/hda3 /mnt/storage Понятие файловой системы С точки зрения операционной системы, под файловой системой понимается внутренняя управляющая структура, заведующая хранением данных на физическом носителе, их поиском, извлечением и записью по запросам программ. Такие управляющие структуры в каждом семействе операционных систем строятся по схожим принципам. Так, DOS/Windows используют файловую систему FAT с вариантами FAT32 и VFAT. Файловые системы UNIX-подобных ОС разнообразнее, но тоже могут быть объединены в одно семейство. Linux умеет работать со множеством файловых систем, как с родными, и с еще большим их количеством обмениваться данными. Файловая система связывает носитель информации с одной стороны и API для доступа к файлам — с другой. Когда прикладная программа обращается к файлу, она не имеет никакого представления о том, каким образом расположена информация в конкретном файле, так же, как и на каком физическом типе носителя (CD, жёстком диске, магнитной ленте или блоке флеш-памяти) он записан. Всё, что знает программа — это имя файла, его размер и атрибуты. Эти данные она получает от драйвера файловой системы. Именно файловая система устанавливает, где и как будет записан файл на физическом носителе (например, жёстком диске). Основные функции любой файловой системы нацелены на решение следующих задач: • именование файлов; • программный интерфейс работы с файлами для приложений; • отображения логической модели файловой системы на физическую организацию хранилища данных; • организация устойчивости файловой системы к сбоям питания, ошибкам аппаратных и программных средств; • содержание параметров файла, необходимых для правильного его взаимодействия с другими объектами системы (ядро, приложения и пр.) В многопользовательских системах появляется еще одна задача: защита файлов одного пользователя от несанкционированного доступа другого пользователя, а также обеспечение совместной работы с файлами, к примеру при открытии файла одним из пользователей, для других этот же файл временно будет доступен в режиме «только чтение». Физически жесткий диск разбит на сектора размером 512 байт. Первый сектор дискового раздела в любой файловой системе считается загрузочной областью. В первичном разделе эта область содержит загрузочную запись — фрагмент кода, который инициирует процесс загрузки операционной системы при запуске. На других разделах эта область не используется. Остальные сектора объединены в логические блоки размером 1, 2 или 4 килобайта. Логический блок есть наименьшая адресуемая порция данных: данные каждого файла занимают целое число блоков. Блоки, в свою очередь, объединяются в группы блоков. Группы блоков и блоки внутри группы нумеруются последовательно, начиная с 1. Монтирование разделов и дисков в Linux Структура каталогов в Linux Понятие файла. С точки зрения UNIX-подобных ОС, файл представляет собой поток или последовательность байтов. Такой подход позволяет распространить понятие файла на множество ресурсов не только локального компьютера, но и удаленного, связанного с локальным сетью любого рода. Доступ к любому такому ресурсу осуществляется через универсальный интерфейс, благодаря чему запись данных в файл, отправка их на физическое устройство или обмен ими с другой работающей программой происходит аналогично. Это очень упрощает организацию данных и обмен ими. Операционная система Linux отличается и от DOS, если уж сравнивать операционные системы, умеющие работать в режиме командной строки, в частности тем, что в первой несколько смазывается роль расширения файла. Конечно, оно присутствует, и по нему можно определить, какой род информации заключен в данном файле, однако для самой операционной системы расширение не имеет особого значения. Нет в Linux и исполняемых файлов, в том виде, в котором они присутствуют в DOS (обычно они имеют расширение *exe). По большому счету, любой файл в Linux является исполняемым, если быть более точным, тот, в атрибутах которого указано право на его исполнение. Вообще, об атрибутах и свойствах файлов необходимо поговорить особо, поскольку зачастую эти параметры требуют к себе обращения Файловая организация в Linux имеет значительные отличия по сравнению с файловой организацией других операционных систем. Но различия эти касаются не только особенностей размещения файлов и каталогов на диске. Касаются они, возможно даже в большей степени, еще и свойств файлов. Эти свойства называются в Linux атрибутами файла. Вообще, атрибуты всех файлов, какие только можно встретить в Linux, условно делятся на две группы: атрибуты принадлежности файла и атрибуты прав доступа к нему. Атрибуты принадлежности — это атрибуты, указывающие, кому может принадлежать данный файл или каталог, поскольку каталог также является единицей файловой системы. В связи с тем, что Linux — система многопользовательская, то и определяется принадлежность файла по разному. Во-первых, файл может принадлежать только одному человеку — его владельцу, создавшему файл либо скопировавшему его из внешнего источника. В данном случае файлу назначается атрибут «owner». Во-вторых, файл может принадлежать определенной группе пользователей, в частности той, к которой принадлежит владелец файла. При этом в его атрибуты добавляется слово «group». И, наконец, в-третьих, файл может быть доступен для всех. И если это так, то в его свойствах можно найти значение «other». Что касается прав доступа к файлу, то их тоже существует три основные разновидности: право на чтение (просмотр), право на изменение (редактирование) и право на исполнение (запуск) файла. Перейдем к типам файлов. Основных типов файлов, характерных для файловой системы Linux, три: ￿обычные файлы; ￿символические ссылки; ￿файлы физических устройств. Конечно, есть и другие, но сфера их применения достаточно узка и лежит в основном в плоскости профессионального системного администрирования, поэтому их рассматривать мы не будем. Итак, с обычными файлами все понятно — это те файлы, в которых действительно содержатся данные. Многие считают, что поскольку Linux имеет свои собственные типы файлов для каждого вида информации (текстовой, графической, звуковой, видео), то она не синхронизируема с Windows. Однако это далеко не так. Linux поддерживает многие файлы с характерными для Windows расширениями: *bmp, *jpg, *html, *pdf, *txt, *doc, *rtf, *wav, *mp3 и многими другими, поэтому проблемы передачи данных между этими системами не существует или почти не существует. Что касается символических ссылок, то это — имена файлов, которых, как уже говорилось, может быть сколько угодно много. Сами ссылки можно использовать в целях упорядочивания иерархии файлов и поддержании в ней образцовой системности, когда администратору системы и простым пользователям точно известно, где найти тот или Файлы физических устройств — это те файлы, которые соответствуют устройствам, подключаемым к компьютеру (принтер, сканер, модем), синхронизирующимся с ним (КПК, mp3-плеер) или входящим в его основной состав (жесткий диск, звуковая и видео подсистемы). Структура каталогов Linux. В системных каталогах находятся файлы, необходимые для управления и сопровождения системы, а также стандартные программы. Их имена, расположение и содержание почти одинаковы почти во всех ОС Linux, поэтому эти каталоги называют также стандартными. Список главных каталогов и подкаталогов с их классификациями. • /bin: важнейшие бинарные файлы. Он содержит базовые команды, которые могут использоваться всеми пользователями и которые являются необходимыми для работы системы: Is, cp, login и др. • /boot: содержит файлы, необходимые для начального загрузчика GNU/Linux (GRUB или LILO для Intel, yaboot для РРС и т.п.). В нём может находиться ядро, но если ядро в этом каталоге отсутствует, тогда оно должно быть в корневом каталоге. • /dev: файлы системных устройств (dev от англ. DEVices). Некоторые файлы, находящиеся в /dev, являются обязательными, например, /dev/null, /dev/zero и /dev/tty. • /etc: содержит все конфигурационные файлы данного компьютера. Этот каталог не может содержать бинарные файлы. • /home: содержит все личные каталоги пользователей системы. Конфигурационные файлы приложений (типа почтовых клиентов и браузеров) располагаются в этом каталоге и начинаются с точки. Например, конфигурационные файлы Mozilla находятся в каталоге .mozilla. • /lib: содержит библиотеки, жизненно необходимые для системы; в нём также хранятся модули ядра в подкаталоге /lib/modules/KERNEL_VERSION. Он содержит все библиотеки, необходимые для работы бинарных файлов из каталогов /bin и /sbin. • /mnt: содержит точки монтирования для временно монтируемых файловых систем, таких как /mnt/cdrom, /mnt/f loppy и т.п. Каталог /mnt также используется для монтирования временных каталогов (карта USB, например, будет примонтирована в /mnt/removable). • /root: домашний каталог суперпользователя. • /sbin: содержит важные системные бинарные файлы, необходимые для запуска системы. Большинство этих файлов могут запускаться только root'oм. • /tmp: каталог предназначен для хранения временных файлов, которые могут создаваться отдельными программами. • /var: место для размещения данных, которые могут изменяться программами в режиме реального времени (например, почтовые серверы, программы наблюдения, серверы печати и др.) • /usr: Каталог /usr является главным каталогом для хранения приложений. Все бинарные файлы в этом каталоге не требуются для загрузки или обслуживания системы, поэтому иерархия /usr может, а зачастую так и есть, размещаться на отдельной файловой системе. Вследствие его (обычно) большого размера, /usr имеет свою собственную иерархию подкаталогов. Мы затронем только несколько из них: • /usr/bin: содержит значительное большинство системных бинарных файлов Любая бинарная программа, которая не является необходимой для обслуживания системы и не предназначена для системного администрирования, должна находиться в этом каталоге. Единственным исключением являются программы, которые вы самостоятельно компилируете и устанавливаете: они должны помещаться в /usr/local; • /usr/lib: содержит все библиотеки, необходимые для запуска программ, находящихся в /usr/bin и /usr/sbin. • /usr/local: это место, куда вы должны устанавливать любые приложения, компилируемые вами из исходных кодов. Программа установки должна будет создать необходимую иерархию; • /usr/share: содержит все аппаратно-независимые данные в режиме только для чтения, необходимые для приложений из /usr. Среди всего прочего вы найдёте в нём информацию о часовых поясах и региональных стандартах (локали) (zoneinf о и locale). Также следует упомянуть каталоги /usr/share/doc и /usr/share/man, которые соответственно содержат документацию к приложениям и системные страницы руководств. /var: Каталог /var содержит все рабочие данные для работающих в системе программ. В отличие от рабочих данных каталога /tmp, эти данные должны остаться нетронутыми в случае перезагрузки. В нём имеется много подкаталогов, вот некоторые из наиболее полезных: • /var/log: содержит файлы системных журналов, которые вы можете читать для выявления неисправностей в своей системе (особенно эти два: /var/log/messages и /var/log/kernel/errors). • /var/run: используется для слежения за всеми процессами, используемыми системой с момента её загрузки, позволяя вам выполнять над ними действия в случае изменения уровня выполнения системы. • /var/spool: содержит рабочие файлы системы, ожидающие определённых действий или обработки. Например, /var/spool/cups содержит рабочие файлы сервера печати, a /var/spool/mail хранит рабочие файлы почтового сервера (например, всю входящую и исходящую почту вашей системы). /etc: Конфигурационные файлы /etc - это один из самых жизненно важных каталогов систем UNIX®, потому что он содержит все конфигурационные файлы системы. /etc не должен быть помещён на отдельный раздел: он необходим для инициализации системы и при загрузке должен находиться на загрузочном разделе Для программ, которым требуется большое число конфигурационных файлов, существуют отдельные подкаталоги. Это относится, например, к X Window System, которая хранит все свои конфигурационные файлы в каталоге /etc/X11. Операционная система DOS В начале 80-х корпорация IBM разработала IBM PC (Personal Computer — персональный компьютер) и начала искать для него программное обеспечение. Сотрудники IBM связались с Биллом Гейтсом (Bill Gates), чтобы получить лицензию на право использования его интерпретатора языка Бейсик (BASIC). Они также поинтересовались, не знает ли он операционную систему, которая работала бы на PC. Гейтс посоветовал обратиться к Digital Research, тогда главенствующей компании по операционным системам. Но Килдэлл отказался встречаться с IBM, послав вместо себя подчиненного. Что еще хуже, его адвокат даже отказался подписывать соглашение о неразглашении, касающееся еще не выпущенного PC, чем полностью испортил дело. Корпорация IBM снова обратилась к Гейтсу с просьбой обеспечить ее операционной системой. После повторного запроса IBM Гейтс выяснил, что у местного изготовителя компьютеров, Seattle Computer Products, есть подходящая операционная система DOS (Disk Operating System — дисковая операционная система). Он направился в эту компанию с предложением выкупить DOS (предположительно за $50 000), которое компания Seattle Computer Products с готовностью приняла. Затем Гейтс создал пакет программ DOS/BASIC, и пакет был куплен IBM. Когда корпорация IBM захотела некоторых усовершенствований в программе, Билл Гейтс пригласил для этой работы Тима Патерсона (Tim Paterson), человека, написавшего DOS, ставшего первым служащим еще не оперившейся компании Гейтса Microsoft. Видоизмененная система была переименована в MS-DOS (MicroSoft Disk Operating System) и быстро заняла доминирующее положение на рынке IBM PC. Самым важным оказалось решение Гейтса (как оказалось, чрезвычайно мудрое) продать MS-DOS компьютерным компаниям для установки вместе с их оборудованием, в отличие от попыток Килдэлла продавать СР/М конечным пользователям (по крайней мере, на начальной стадии). Когда в 1983 году появился компьютер IBM PC/AT с центральным процессо процессором Intel 80286, система MS-DOS уже прочно стояла на ногах, а СР/М доживала свои последние дни. Позже система MS-DOS широко использовалась на компьютерах с процессорами 80386 и 80486. Хотя первоначальная версия MS-DOS была довольно примитивна, последующие версии системы выходили со все лучше разработанными свойствами, включая многое, позаимствованное от UNIX. (Корпорация Microsoft была неплохо информирована о системе UNIX и даже продавала ее микрокомпьютерную версию XENIX в первые годы своего существования.) СР/М, MS-DOS и другие операционные системы для первых микрокомпьюте микрокомпьютеров полностью основывались на вводе команд с клавиатуры. Затем, благодаря исследованиям, проведенным в 60-е годы Дагом Энгельбартом (Doug Engelbart) в научно-исследовательском институте Стэнфорда (Stanford Research Institute), это свойство операционных систем изменилось. Энгельбарт изобрел графический интерфейс пользователя (GUI, Graphical User Interface, произносимый как «гуи»), состоящий из окон, значков, различных меню и мыши. Эту идею переняпереняли разработчики из Xerox PARC и встроили в сконструированные ими машины. Однажды Стив Джобс (Steve Jobs), тот самый, который изобрел компьютер Apple в своем собственном гараже, посетил PARC, где увидел GUI и тотчас осознал его потенциальную ценность, практически не осознаваемую руководством Xerox. Тогда Джобе приступил к созданию Apple с графическим интерфейсом. Это привело к проекту Lisa, который был слишком дорог и потерпел коммерческую неудачу. Вторая попытка Джобса, Apple Macintosh, имела огромный успех не только из-за дешевизны, но и потому, что на нем работал дружественный интерфейс, то есть предназначенный для пользователей, ничего не знающих о компьютерах и, более того, вовсе не желающих чему-либо обучаться. Когда корпорация Microsoft решила создать преемника MS-DOS, она находилась полностью под влиянием успехов компании Macintosh. Была разработана система, получившая название Windows, базой для которой послужил GUI. Система Windows первоначально работала поверх MS-DOS (то есть это была скорее оболочка, чем настоящая операционная система). На протяжении 10 лет, с 1985 по 1995 год, система Windows исполняла роль графической среды поверх MS-DOS. Однако в 1995 году вышла в свет автономная версия Windows 95. Операционные системы корпорации Microsoft для настольных и переносных компькомпьютеров можно разделить на три семейства: MS-DOS, Consumer Windows (Windows 95/98/Me) и Windows NT. DOS (англ. Disk Operating System — дисковая операционная система, ДОС) — семейство операционных систем для персональных компьютеров. Ориентировано на использование дисковых накопителей, таких как жёсткий диск и дискета. DOS является однозадачной операционной системой. После запуска управление передаётся прикладной программе, которая получает в своё распоряжение все ресурсы компьютера и может осуществлять ввод/вывод посредством как функций предоставляемых операционной системой, так и функций базовой системы ввода/вывода (BIOS), а также работать с устройствами напрямую. Существует несколько ветвей ДОС для ПК. Все они схожи по наборам команд и базовой функциональности, но отличаются производительностью, стабильностью работы и дополнительными функциями. • DR-DOS (Novell DOS, Caldera DR-DOS) — выпущена Digital Research в 1991 году. • MS-DOS — выпущена компанией Microsoft в 1981 году. • PC DOS — выпущена компанией IBM в 1981 году. • PTS-DOS — выпущена компанией Физтех-софт в 1991 году или ранее. • Paragon DOS Pro. Ветка PTS-DOS, выпущенная компанией Paragon Software. Последние версии этой ветки включают поддержку FAT32. • FreeDOS — выпущена в 1994 году. Свободная ДОС, изначально называлась PD-DOS. • FreeDOS-32 — свободная 32-битная ДОС. Не требует расширителей для запуска 32-битных приложений. Планируется избавиться и от других ограничений ДОС (поддержка других файловых систем, многозадачности и т. п.). MS-DOS MS-DOS (англ. Microsoft Disk Operating System — дисковая ОС от Microsoft) — коммерческая операционная система фирмы Microsoft для IBM PC-совместимых персональных компьютеров. MS-DOS — самая известная ОС из семейства DOS, ранее устанавливаемая на большинство IBM PC-совместимых компьютеров. Со временем она была вытеснена ОС семейства Windows 9x и Windows NT. MS-DOS была создана в 1981 году и, в ходе её развития, было выпущено восемь крупных версий (1.0, 2.0 и т. д.) и два десятка промежуточных (3.1, 3.2 и т. п.), пока в 2000 году Microsoft не прекратила её разработку. Это был ключевой продукт фирмы, дававший ей существенный доход и маркетинговый ресурс, в ходе развития Microsoft от разработчика языка программирования до крупной компании, производящей самое разнообразное программное обеспечение. Последней коробочной версией стала 6.22, однако MS-DOS продолжала служить ядром для Windows 95 (версии 7.0 и 7.1), Windows 98 (версия 7.1) и Windows ME (версия 8.0). Минимальный набор файлов MS-DOS: Файлы ядра: IO.SYS — расширение BIOS MSDOS.SYS — обработка прерываний Командный процессор: COMMAND.COM — командный процессор (поддержка интерфейса командной строки). Строго говоря, для запуска MS-DOS наличие файла COMMAND.COM не является необходимым. Его можно заменить другим командным процессором, способным выполнять нужные вам команды. Делается это добавлением в CONFIG.SYS строки shell=c:\my\myprog.com. В своё время сторонними разработчиками было выпущено множество командных процессоров. Наиболее распространённый командный процессор, выпущенный сторонней фирмой, был NDOS.COM (лицензированный 4DOS) из пакета Norton Utilities фирмы Symantec. Файлы конфигурации: Для задания конфигурации ОС используются конфигурационные файлы специального формата: CONFIG.SYS — конфигурирование системы и загрузка драйверов устройств на этапе инициализации MSDOS.SYS AUTOEXEC.BAT — стартовый пакетный файл. Выполняется при запуске командного процессора во время загрузки системы. Также, в дистрибутив входят следующие драйверы и программы: ANSI.SYS — расширенный драйвер консоли (экрана и клавиатуры). HIMEM.SYS — драйвер дополнительной (extended memory) и HMA-памяти. EMM386.EXE — драйвер расширенной памяти (expanded memory). RAMDRIVE.SYS — драйвер электронного диска. KEYB.COM — драйвер переключения языковых раскладок клавиватуры. KEYBOARD.SYS — файл с описаниями языковых раскладок клавиатуры, оформленный как драйвер. COUNTRY.SYS — Файл с таблицами локализации, алфавитами сортировки. DISPLAY.SYS — драйвер дисплея; в частности, загружает локализованные шрифты. *.CPI — загружаемые шрифты кодовых страниц экрана и клавиатуры. MODE.COM — программа настройки ряда параметров экрана и портов ввода-вывода системы: последовательного, параллельного DOS Shell (DOSSHELL) — начиная с MS-DOS 5.0 входит в состав дистрибутива. Оболочка, использует «двухпанельный» принцип с псевдографическим интерфейсом. Семейство операционных систем Windows Microsoft Windows (англ. windows — окна) — семейство проприетарных операционных систем корпорации Майкрософт (Microsoft), ориентированных на применении графического интерфейса при управлении. Изначально были представлены многофункциональными надстройками для MS-DOS. В настоящее время под управлением операционных систем семейства Windows работает около 90 % персональных компьютеров. Обычно все версии Windows делят на несколько «групп». Графические интерфейсы и расширения для DOS Эти версии Windows не были полноценными операционными системами, а являлись надстройками к операционной системе MS-DOS и были по сути многофункциональным расширением, добавляя поддержку новых режимов работы процессора, поддержку многозадачности, обеспечивая стандартизацию интерфейсов аппаратного обеспечения и единообразие для пользовательских интерфейсов программ. Предоставляли встроенные средства (GDI) для создания графического интерфейса пользователя. • Windows 1.0 (1985) • Windows 2.0 (1987) • Windows 2.1 (Windows 386) (1987) — в системе появилась возможность запуска DOS-приложений в графических окнах, причём каждому приложению предоставлялись полные 640 Кб памяти. Полная поддержка процессора 80286. Появилась поддержка процессоров 80386. • Windows 3.0 (1990) — улучшена поддержка процессоров 80386 и защищённого режима. • Windows 3.1 (1992) — серьёзно переработанная Windows 3.0; устранены UAE (Unrecoverable Application Errors — фатальные ошибки прикладных программ), добавлен механизм OLE, печать в режиме WYSIWYG («что видите, то и получите»), шрифты TrueType, изменён Проводник (диспетчер файлов), добавлены мультимедийные функции. • Windows для рабочих групп (Windows for Workgroups) 3.1/3.11 — первая версия ОС семейства с поддержкой локальных сетей. В WFWG 3.11 также испытывались отдельные усовершенствования ядра, применённые позднее в Windows 95. Семейство Windows 9x Включает в себя Windows 95, Windows 98 и Windows Me. Windows 95 была выпущена в 1995 году. Её отличительными особенностями являются новый пользовательский интерфейс, поддержка длинных имён файлов, автоматическое определение и конфигурация периферийных устройств Plug and Play, и способность исполнять 32-битные приложения. Windows 95 использует вытесняющую многозадачность и выполняет каждое 32-битное приложение в своём адресном пространстве. Операционные системы этого семейства не являлись безопасными многопользовательскими системами как Windows NT, поскольку строгое разделение исполняющихся приложений не было реализовано в ядре. Программный интерфейс был подмножеством Win32 API поддерживаемым Windows NT, но имел поддержку юникода в очень ограниченном объёме. Также в нём не было должного обеспечения безопасности. В составе Windows 95 присутствовал MS-DOS 7.0, однако его роль сводилась к обеспечению процесса загрузки и исполнению 16-битных DOS приложений. Семейство Windows NT Все операционные системы этого семейства являются полностью 32-битными операционными системами, и не нуждаются в MS-DOS даже для загрузки. Только в этом семействе представлены операционные системы для серверов. До версии Windows 2000 включительно они выпускались под тем же названием что и аналогичная версия для рабочих станций, но с добавлением суффикса, например «Windows NT 4.0 Server» и «Windows 2000 Datacenter Server». Начиная с Windows Server 2003, серверные операционные системы называются по-другому. Windows NT 3.1 (1993) Windows NT 3.5 (1994) Windows NT 3.51 (1995) Windows NT 4.0 (1996) Windows 2000 (2000) — Windows NT 5.0 Windows XP (2001) — Windows NT 5.1 Windows XP 64-bit Edition (2006) — Windows NT 5.2 Windows Server 2003 (2003) — Windows NT 5.2 Windows Vista (2006) — Windows NT 6.0 Windows Home Server (2007) — Windows NT 5.2 Windows Server 2008 (2008) — Windows NT 6.0 Windows Small Business Server (2008) — Windows NT 6.0 Windows 7 — Windows NT 6.1 (2009) Windows Server 2008 R2 — Windows NT 6.1 (2009) В основу семейства Windows NT положено разделение адресных пространств между процессами. Каждый процесс имеет возможность работать с выделенной ему памятью. Однако он не имеет прав для записи в память других процессов, драйверов и системного кода. Семейство Windows NT относится к операционным системам с вытесняющей многозадачностью. Разделение процессорного времени между потоками происходит по принципу «карусели». Ядро операционной системы выделяет квант времени (в Windows 2000 квант равен примерно 20 мс) каждому из потоков по очереди при условии, что все потоки имеют одинаковый приоритет. Поток может отказаться от выделенного ему кванта времени. В этом случае система перехватывает у него управление (даже если выделенный квант времени не закончен) и передаёт управление другому потоку. При передаче управления другому потоку система сохраняет состояние всех регистров процессора в особой структуре в оперативной памяти. Эта структура называется контекстом потока. Сохранение контекста потока достаточно для последующего возобновления его работы. История. К концу 80-х корпорация Microsoft осознала, что построение современной 32-раз 32-разрядной операционной системы поверх 16-разрядной системы MS-DOS представляет собой не лучшее решение. Компания Microsoft наняла Дэвида Катлера, одного из ключевых разработчиков операционной системы VMS, созданной корпорацией DEC, и поручила ему возглавить работу над совершенно новой 32-разрядной операционной системой, совместимой с Windows. Эта новая система, названная позднее Windows NT (буквы NT означали New Technology — новая технология), предназначалась для деловых приложений, решающих критически важные, ответственные задачи, а также для домашнего использования. В это время мэйнфреймы все еще правили деловым миром, поэтому предположение, что компании будут использовать персональные компьютеры для чего-либо важного, тогда выглядело довольно утопично. Тем не менее, как показала история, это был правильный выбор. Такие свойства, как безопасность и высокая надежность, отсутствовавшие в версиях Windows, основанных на MS-DOS, были поставлены в данном проекте во главу угла. Опыт работы с VMS, полученный Катлером, отчетливо проявлялся при создании системы, и в строении NT и VMS есть нечто большее, чем просто поверхностное сходство. Проект оказался успешным, и в 1993 году была выпущена первая версия, названная Windows NT 3.1. Начальный номер версии был выбран так, чтобы он соответствовал номеру версии популярной тогда 16-разрядной Windows 3.1. Корпорация Microsoft ожидала, что операционная система NT быстро вытеснит Windows 3.1, так как по формальным показателям NT значительно превосходила ее. К большому удивлению разработчиков, почти все пользователи предпочли остаться на уже знакомой им старой 16-разрядной версии, а не переходить на неизвестную 32-разрядную систему, какой бы хорошей она ни была. Для операционной системы NT требовалось значительно больше памяти, чем для Windows 3.1, к тому же для новой системы не было 32-разрядных программ, поэтому зачем нужны были пользователям все эти хлопоты? Поскольку операционная система NT 3.1 потерпела неудачу на рынке, корпорация Microsoft решила выпустить 32-32-разрядную версию Windows 3.1, а именно Windows 95. Пользователи продолжали упорствовать, не желая переходить на NT, и корпорация Microsoft выпустила Windows 98 и, наконец, Windows Me. О каждой из которых заявлялось, что это самый последний выпуск операционной системы, основанной на MS-DOS. Несмотря на тот факт, что почти все покупатели и большинство корпораций проигнорировало операционную систему NT 3.1 для настольных систем, эта операционная система стала пользоваться некоторым спросом на рынке серверов. В 1994 и 1995 годах было выпущено несколько новых 3.x версий с небольшими изменениями. Эти версии начали также медленно приобретать сторонников среди пользователей настольных машин. Первое значительное усовершенствование системы NT появилось в 1996 году в виде версии NT 4.0. Эта система обладала мощностью, безопасностью и надежностью современной операционной системы, но она также использовала тот же самый пользовательский интерфейс, что и очень популярная тогда Windows 95. Эта совместимость облегчала пользователям переход с Windows 95 на NT, и многие пользователи так и поступили. ––––––––––––––––––––––––––––––––––––––––––––––– Семейство ОС Windows Mobile для карманных компьютеров Это семейство операционных систем реального времени было специально разработано для встраиваемых систем. Поддерживаются процессоры ARM, MIPS, SuperH и x86. В отличие от остальных операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как смартфоны, карманные компьютеры, GPS навигаторы, MP3 проигрыватели, и другие. В настоящее время под термином «Windows CE» понимают только ядро операционной системы. Например Windows Mobile 5.0 включает в себя ядро Windows CE 5.0, хотя в некоторых устройствах ядро Windows CE используется и без Windows Mobile. Windows CE Windows Mobile Семейство встраиваемых ОС Windows Embedded Windows Embedded — это семейство операционных систем реального времени, было специально разработано для применения в различных встраиваемых системах. Ядро системы общее с семейством ОС Windows CE и поддерживает процессоры ARM, MIPS, SuperH и x86. Windows Embedded включает дополнительные функции по встраиванию, среди которых фильтр защиты от записи (EWF и FBWF), загрузка с флеш-памяти, CD-ROM, сети, использование собственной оболочки системы и т. п. В отличие от остальных операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как: банкоматы, медицинские приборы, навигационное оборудование, «тонкие» клиенты, VoIP-терминалы, медиапроигрыватели, цифровые рамки (альбомы), кассовые терминалы, платёжные терминалы, роботы, игровые автоматы, музыкальные автоматы, и другие. Основные принципы построения ОС Принцип модульности Под модулем в общем случае понимают функционально законченный элемент системы, выполненный в соответствии с принятыми межмодульными интерфейсами. По своему определению модуль предполагает возможность без труда заменить его на другой при наличии заданных интерфейсов. Способы обособления составных частей ОС в отдельные модули могут существенно различаться, но чаще всего разделение происходит именно по функциональному признаку. В значительной степени разделение системы на модули определяется используемым методом проектирования ОС (восходящее или нисходящее проектирование). Особо важное значение при построении ОС имеют привилегированные, повторно входимые и реентерабельные модули, так как позволяют более эффективно использовать ресурсы вычислительной системы. Достижение реентерабельности реализуется различными способами. В некоторых системах реентерабельность программы получается автоматически, благодаря неизменяемости кодовых частей программ при исполнении (из-за особенностей системы команд машины), а также автоматическому распределению регистров, автоматическому отделению кодовых частей программ от данных и помещению последних в системную область памяти. Естественно, что для этого необходима соответствующая аппаратная поддержка. В других случаях это достигается программистами за счет использования специальных системных модулей. Принцип модульности отражает технологические и эксплуатационные свойства системы. Наибольший эффект от его использования достижим в случае, когда принцип распространен одновременно на операционную систему, прикладные программы и аппаратуру. Принцип функциональной избирательности В ОС выделяется некоторая часть важных модулей, которые должны постоянно находиться в оперативной памяти для более эффективной организации вычислительного процесса. Эту часть в ОС называют ядром, так как это действительно основа системы. При формировании состава ядра требуется учитывать два противоречивых требования. В состав ядра должны войти наиболее часто используемые системные модули. Количество модулей должно быть таковым, чтобы объем памяти, занимаемый ядром, был бы не слишком большим. В состав ядра, как правило, входят модули по управлению системой прерываний, средства по переводу программ из состояния счета в состояние ожидания, готовности и обратно, средства по распределению таких основных ресурсов, как оперативная память и процессор. Помимо программных модулей, входящих в состав ядра и постоянно располагающихся в оперативной памяти, может быть много других системных программных модулей, которые получают название транзитных. Транзитные программные модули загружаются в оперативную память только при необходимости и в случае отсутствия свободного пространства могут быть замещены другими транзитными модулями. В качестве синонима к термину "транзитный" можно использовать термин "диск-резидентный". Принцип генерируемости ОС Основное положение этого принципа определяет такой способ исходного представления центральной системной управляющей программы ОС (ее ядра и основных компонентов, которые должны постоянно находится в оперативной памяти), который позволял бы настраивать эту системную супервизорную часть, исходя из конкретной конфигурации конкретного вычислительного комплекса и круга решаемых задач. Эта процедура проводится редко, перед достаточно протяженным периодом эксплуатации ОС. Процесс генерации осуществляется с помощью специальной программы-генератора и соответствующего входного языка для этой программы, позволяющего описывать программные возможности системы и конфигурацию машины. В результате генерации получается полная версия ОС. Сгенерированная версия ОС представляет собой совокупность системных наборов модулей и данных. Упомянутый раньше принцип модульности положительно проявляется при генерации ОС. Он существенно упрощает настройку ОС на требуемую конфигурацию вычислительной системы. В наши дни при использовании персональных компьютеров с принципом генерируемости ОС можно столкнуться разве что только при работе с Linux. В этой UNIX-система имеется возможность не только использовать какое-либо готовое ядро ОС, но и самому сгенерировать (скомпилировать) такое ядро, которое будет оптимальным для данного конкретного персонального компьютера и решаемых на нем задач. Кроме генерации ядра в Linux имеется возможность указать и набор подгружаемых драйверов и служб, то есть часть функций может реализовываться модулями, непосредственно входящими в ядро системы, а часть - модулями, имеющими статус подгружаемых, транзитных. В остальных современных распространенных ОС для персональных компьютеров конфигурирование ОС под соответствующий состав оборудования осуществляется на этапе инсталляции, а потом состав драйверов и изменение некоторых параметров ОС может быть осуществлено посредством редактирования конфигурационного файла. Принцип функциональной избыточности Принцип функциональной избыточности: Этот принцип учитывает возможность проведения одной и той же работы различными средствами. В состав ОС может входить несколько типов мониторов (модулей супервизора, управляющих тем или другим видом ресурса), различные средства организации коммуникаций между вычислительными процессами. Наличие нескольких типов мониторов, нескольких систем управления файлами позволяет пользователям быстро и наиболее адекватно адаптировать ОС к определенной конфигурации вычислительной системы, обеспечивать максимально эффективную загрузку технических средств при решении конкретного класса задач, получать максимальную производительность при решении заданного класса задач. Принцип виртуализации Принцип виртуализации: построение виртуальных ресурсов, их распределение и использование в настоящее время применяется практически в любой ОС. Этот принцип позволяет представить структуру системы в виде определенного набора планировщиков процессов и распределителей ресурсов (мониторов) и использовать единую централизованную схему распреде-ления ресурсов. Наиболее естественным и законченным проявлением концепции виртуальности является понятие виртуальной машины. Виртуальная машина, предоставляемая пользователю, воспроизводит архитектуру реальной машины, но архитектурные элементы в таком представлении выступают с новыми или улучшенными характеристиками, как правило, упрощающими работу с системой. Характеристики могут быть произвольными, но чаще всего пользователи желают иметь собственную «идеальную» по архитектурным характерис-тикам машину в следующем составе: - единообразная по логике работы виртуальная память практически неограниченного объема. - произвольное количество виртуальных процессоров, способных работать параллельно и взаимодействовать во время работы. - произвольное количество внешних виртуальных устройств, способных работать с памятью виртуальной машины параллельно или последовательно, асинхронно или синхронно по отношению к работе того или иного виртуального процессора, инициирующего работу этих устройств. Одним из аспектов виртуализации является организация возможности выполнения в данной ОС приложений, которые разра-батывались для других ОС. Другими словами, речь идет об организации нескольких операционных сред. Принцип независимости программ от внешних устройств Принцип совместимости Одним из аспектов совместимости является способность ОС выполнять программы, написанные для других ОС или для более ранних версий данной ОС, а также для другой аппаратной платформы. Необходимо разделять вопросы двоичной совмести-мости и совместимости на уровне исходных текстов приложений. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение на другой ОС. Для этого необходимы совместимость на уровне команд процессора, и совместимость на уровне системных вызовов, и даже на уровне библиотечных вызовов, если они являются динамически связываемыми. Совместимость на уровне исходных текстов требует наличия соответствующего транслятора в составе системного программного обеспечения, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый выполняемый модуль. Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того чтобы один компьютер выполнял программы другого (например, программу для ПК типа IBM PC желательно выполнить на ПК типа Macintosh фирмы Apple), этот компьютер должен работать с машинными командами, которые ему изначально непо-нятны. В таком случае процессор типа 680×0 (или PowerPC) должен исполнять двоичный код, предназначенный для процессора i80×86. Процессор 80×86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор 680×0 не понимает двоичный код 80×86, поэтому он должен выбрать каждую команду, декодировать ее, чтобы определить, для чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680×0. Одним из средств обеспечения совместимости программных и пользовательских интерфейсов является соответствие стан-дартам POSIX, использование которого позволяет создавать программы в стиле UNIX, легко переносимых впоследствии из одной системы в другую. Принцип открытости и наращиваемости Принцип открытости и наращиваемости: Открытая операционная система доступна для анализа как пользователям, так и системным специалистам, обслуживающим вычислительную систему. Наращиваемая (модифицируемая, развиваемая) ОС позволяяет не только использовать возможности генерации, но и вводить в ее состав новые модули, совершенствовать существующие и т.д. Другими словами, следует обеспечить возможность легкого внесения дополнений и изменений в необходимых случаях без нарушения целостности системы. Прекрасные возможности для расширения предоставляет подход к структурированию ОС по типу клиент-сервер с использованием микро-ядерной технологии. В соответствии с этим подходом ОС строится как совокупность привилегированной управляющей программы и набора непривилегированных услуг (серверов). Основная часть ОС остается неизменной, и в то же время могут быть добавлены новые серверы или улучшены старые. Этот принцип иногда трактуют как расширяемость системы. Принцип мобильности Принцип мобильности: операционная система относительно легко должна перено- ситься с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа, которая включает наряду с типом процессора и способ организации всей аппаратуры компьютера (архитектуру вычислительной системы), на аппаратную платформу другого типа. Заметим, что принцип переносимости очень близок принципу совместимости, хотя это и не одно и то же. Создание переносимой ОС аналогично написанию любого перено-симого кода, при этом нужно следовать некоторым правилам: - большая часть ОС должна быть выполнена на языке, имеющемся на всех системах, на которые планируется в дальнейшем ее переносить. Это, прежде всего, означает, что ОС должна быть написана на языке высокого уровня, предпочтительно стандартизованном, например на языке С. Программа, написанная на ассемблере, не является в общем случае переносимой. - важно минимизировать или, если возмож-но, исключить те части кода, которые непосредственно взаимодействуют с аппаратными средствами. Зависимость от аппаратуры может иметь много форм. Некоторые очевидные формы зависимости включают прямое манипулирование регистрами и другими аппаратными средствами. Наконец, если аппаратнозависимый код не может быть полностью исключен, то он должен быть изолирован в нескольких хорошо локализуемых модулях. Аппаратнозависимый код не должен быть распределен по всей системе. Например, можно спрятать аппаратно-зависимую структуру в програмно задаваемые данные абстрактного типа. Введение стандартов POSIX преследовало цель обеспечить переносимость создаваемого программного обеспечения. Принцип обеспечения безопасности вычислений Принцип обеспечения безопасности вычислений: обеспечение безопасности при выполнении вычислений является желательным свойством для любой многопользовательской системы. Правила безопасности определяют такие свойства, как защиту ресурсов одного пользователя от других и установление квот по ресурсам для предотвращения захвата одним пользователем всех системных ресурсов таких например как память. Обеспечение защиты информации от несанкционированного доступа является обязательной функцией сетевых операционных систем. Процессы и треды Понятие процесса было введено для реализации идей мультипрограммирования. Напомним, в свое время различали термины «мультизадачность» и «мультипро­граммирование». Таким образом, для реализации «мультизадачности» в ее ис­ходном толковании необходимо было тоже ввести соответствующую сущность. Такой сущностью и стали так называемые «легковесные» процессы, или, как их теперь преимущественно называют, — потоки или треды (нити). Thread — поток, нить. Когда говорят о процессах (process), то тем самым хотят отметить, что операци­онная система поддерживает их обособленность: у каждого процесса имеется свое виртуальное адресное пространство, каждому процессу назначаются свои ресур­сы — файлы, окна, семафоры и т. д. Такая обособленность нужна для того, чтобы защитить один процесс от другого, поскольку они, совместно используя все ре­сурсы вычислительной системы, конкурируют друг с другом. В общем случае процессы просто никак не связаны между собой и могут принадлежать даже раз­ным пользователям, разделяющим одну вычислительную систему. Другими сло­вами, в случае процессов ОС считает их совершенно несвязанными и независимыми. При этом именно ОС берет на себя роль арбитра в конкуренции между процессами по поводу ресурсов. Однако желательно иметь еще и возможность задействовать внутренний парал­лелизм, который может быть в самих процессах. Такой внутренний параллелизм встречается достаточно часто и его использование позволяет ускорить их реше­ние. Например, некоторые операции, выполняемые приложением, могут требо­вать для своего исполнения достаточно длительного использования центрального процессора. В этом случае при интерактивной работе с приложением пользова­тель вынужден долго ожидать завершения заказанной операции и не может управ­лять приложением до тех пор, пока операция не выполнится до самого конца. Такие ситуации встречаются достаточно часто, например, при обработке боль­ших изображений в графических редакторах. Если же программные модули, исполняющие такие длительные операции, оформлять в виде самостоятельных «подпроцессов» (легковесных или облегченных процессов — потоков, можно также воспользоваться термином задача), которые будут выполняться парал­лельно с другими «подпроцессами» (потоками, задачами), то у пользователя по­является возможность параллельно выполнять несколько операций в рамках од­ного приложения (процесса). Легковесными эти задачи называют потому, что операционная система не должна для них организовывать полноценную вирту­альную машину. Эти задачи не имеют своих собственных ресурсов, они развива­ются в том же виртуальном адресном пространстве, могут пользоваться теми же файлами, виртуальными устройствами и иными ресурсами, что и данный про­цесс. Единственное, что им необходимо иметь, — это процессорный ресурс. В од­нопроцессорной системе треды (задачи) разделяют между собой процессорное время так же, как это делают обычные процессы, а в мультипроцессорной систе­ме могут выполняться одновременно, если не встречают конкуренции из-за об­ращения к иным ресурсам. Главное, что обеспечивает мпогопоточность, — это возможность параллельно вы­полнять несколько видов операций в одной прикладной программе. Параллель­ные вычисления (а следовательно, и более эффективное использование ресур­сов центрального процессора, и меньшее суммарное время выполнения задач) теперь уже часто реализуется на уровне тредов, и программа, оформленная в виде нескольких тредов в рамках одного процесса, может быть выполнена быстрее за счет параллельного выполнения ее отдельных частей. Например, если электрон­ная таблица или текстовый процессор были разработаны с учетом возможностей многопоточной обработки, то пользователь может запросить пересчет своего ра­бочего листа или слияние нескольких документов и одновременно продолжать заполнять таблицу или открывать для редактирования следующий документ. Особенно эффективно можно использовать многопоточность для выполнения распределенных приложений; например, многопоточпый сервер может парал­лельно выполнять запросы сразу нескольких клиентов. Как известно, операци­онная система OS/2 одной из первых среди ОС, используемых на ПК, ввела многопоточность. В середине девяностых годов для этой ОС было создано очень большое количество приложений, в которых использование механизмов много­поточной обработки реально приводило к существенно большей скорости вы­полнения вычислений. Итак, сущность «поток» была введена для того, чтобы именно с помощью этих единиц распределять процессорное время между возможными работами. Сущ­ность «процесс» предполагает, что при диспетчеризации нужно учитывать все ресурсы, закрепленные за ним. А при манипулировании тредами можно менять только контекст задачи, если мы переключаемся с одной задачи на другую в рам­ках одного процесса. Все остальные вычислительные ресурсы при этом не затра­гиваются. Каждый процесс всегда состоит по крайней мере из одного потока, и только если имеется внутренний параллелизм, программист может «расще­пить» один тред па несколько параллельных. Потребность в потоках (threads) возникла еще на однопроцессорных вычисли­тельных системах, поскольку они позволяют организовать вычисления более эф­фективно. Для использования достоинств многопроцессорных систем с общей памятью треды уже просто необходимы, так как позволяют не только реально ускорить выполнение тех задач, которые допускают их естественное распаралле­ливание, но и загрузить процессорные элементы работой, чтобы они не простаи­вали. Заметим однако, что желательно, чтобы можно было уменьшить взаимо­действие тредов между собой, ибо ускорение от одновременною выполнения параллельных потоков может быть сведено к минимуму из-за задержек синхро­низации и обмена данными. Каждый тред выполняется строго последовательно и имеет свой собственный программный счетчик и стек. Треды, как и процессы, могут порождать треды-по­томки, поскольку любой процесс состоит по крайней мере из одного треда. По­добно традиционным процессам (то есть процессам, состоящим из одного треда), каждый тред может находится в одном из активных состояний. Пока один тред заблокирован (или просто находится в очереди готовых к исполнению задач), другой тред того же процесса может выполняться. Треды разделяют процессор­ное время так же, как это делают обычные процессы, в соответствии с различны­ми вариантами диспетчеризации. Все треды имеют одно и то же виртуальное адресное про­странство своего процесса. Это означает, что они разделяют одни и те же гло­бальные переменные. Поскольку каждый тред может иметь доступ к каждому виртуальному адресу, один тред может использовать стек другого треда. Между потоками нет полной защиты, так как это, во-первых, невозможно, а во-вторых, не нужно. Все потоки одного процесса всегда решают общую задачу одного поль­зователя, и механизм потоков используется здесь для более быстрого решения задачи путем ее распараллеливания. При этом программисту очень важно полу­чить в свое распоряжение удобные средства организации взаимодействия частей одной программы. Повторим, что кроме разделения адресного пространства, все треды разделяют также набор открытых файлов, используют общие устройства, выделенные процее у, имеют одни и те же наборы сигналов, семафоры и т. п. А что у тредов будет их собственным? Собственными являются программный счетчик, стек, рабочие регистры процессора, потоки-потомки, состояние. Вследствие того, что треды, относящиеся к одному процессу, выполняются в од­ном и том же виртуальном адресном пространстве, между ними легко организовать тесное взаимодействие, в отличие от процессов, для которых нужны специ­альные механизмы обмена сообщениями и данными. Более того, программист, создающий многопоточное приложение, может заранее продумать работу мно­жества тредов процесса таким образом, чтобы они могли взаимодействовать наи­более выгодным способом, а не участвовать в конкуренции за предоставление ресурсов тогда, когда этого можно избежать. Для того чтобы можно было эффективно организовать параллельное выполне­ние рассмотренных сущностей (процессов и тредов), в архитектуру современных процессоров включена возможность работать со специальной информационной структурой, описывающей ту или иную сущность. Для этого уже на уровне архитектуры микропроцессора используется понятие «задача» (task). Оно как бы объединяет в себе обычный и «легковесный» процессы. Это понятие и поддер­живаемая для него на уровне аппаратуры информационная структура позволяют в дальнейшем при разработке операционной системы построить соответствую­щие дескрипторы как для процесса, так и для треда. Отличаться эти дескрипто­ры будут прежде всего тем, что дескриптор треда может хранить только контекст приостановленного вычислительного процесса, тогда как дескриптор процесса (process) должен уже содержать поля, описывающие тем или иным способом ре­сурсы, выделенные этому процессу. Планирование и диспетчеризация процессов и задач Стратегии планирования Прежде всего, следует отметить, что при рассмотрении стратегий планирования, как правило, идет речь о краткосрочном планировании, то есть о диспетчериза­ции. Долгосрочное планирование, как мы уже отметили, заключается в подборе таких вычислительных процессов, которые бы меньше всего конкурировали ме­жду собой за ресурсы вычислительной системы. Стратегия планирования определяет, какие процессы мы планируем на выпол­нение для того, чтобы достичь поставленной цели. Известно большое количество различных стратегий выбора процесса, которому необходимо предоставить про­цессор. Среди них, прежде всего, можно назвать следующие стратегии: по возможности заканчивать вычисления (вычислительные процессы) в том же самом порядке, в котором они были начаты; отдавать предпочтение более коротким процессам; предоставлять всем пользователям (процессам пользователей) одинаковые услуги, в том числе и одинаковое время ожидания. Когда говорят о стратегии обслуживания, всегда имеют в виду понятие процесса, а не понятие задачи, поскольку процесс, как мы уже знаем, может состоять из не­скольких потоков (задач). Дисциплины диспетчеризации Когда говорят о диспетчеризации, то всегда в явном или неявном виде имеют в виду понятие задачи (потока). Если ОС не поддерживает механизм тредов, то можно заменять понятие задачи на понятие процесса. Так как эти термины часто используются именно в таком смысле, мы вынуждены будем использовать тер­мин «процесс» как синоним термина «задача». Известно большое количество правил (дисциплин диспетчеризации), в соответ­ствии с которыми формируется список (очередь) готовых к выполнению задач. Различают два больших класса дисциплин обслуживания — бесприоритетпые и приоритетные. При бесприоритетном обслуживании выбор задачи произво­дится в некотором заранее установленном порядке без учета их относительной важности и времени обслуживания. При реализации приоритетных дисциплин обслуживания отдельным задачам предоставляется преимущественное право по­пасть в состояние исполнения. Диспетчеризация с динамическими приоритетами требует дополнительных рас­ходов па вычисление значений приоритетов исполняющихся задач, поэтому во многих ОС реального времени используются методы диспетчеризации на основе статических (постоянных) приоритетов. Хотя надо заметить, что динамические приоритеты позволяют реализовать гарантии обслуживания задач. Рассмотрим кратко некоторые основные (наиболее часто используемые) дисци­плины диспетчеризации. Самой простой в реализации является дисциплина FCFS (first come — first served), согласно которой задачи обслуживаются «в порядке очереди», то есть в порядке их появления. Те задачи, которые были заблокированы в процессе работы (попа­ли в какое-либо из состояний ожидания, например, из-за операций ввода/выво­да), после перехода в состояние готовности ставятся в эту очередь готовности перед теми задачами, которые еще не выполнялись. Другими словами, образу­ются две очереди (рис. 2.2): одна очередь образуется из новых задач, а вторая очередь — из ранее выполнявшихся, но попавших в состояние ожидание. Такой подход позволяет реализовать стратегию обслуживания «по возможности закан­чивать вычисления в порядке их появления». Эта дисциплина обслуживания не требует внешнего вмешательства в ход вычислений, при пей не происходит перераспределение процессорного времени. Существующие дисциплины дис­петчеризации процессов могут быть разбиты на два класса — вытесняющие (pre­emptive) и не вытесняющие (non-preemptive). В первых пакетных ОС часто реализовывали параллельное выполнение заданий без принудительного перс- распределения процессора между задачами. В большинстве современных ОС для мощных вычислительных систем, а также и в ОС для ITK, ориентированных на высокопроизводительное выполнение приложений (Windows NT, OS/2, Linux), реализована вытесняющая многозадачность. Можно сказть, что рассмотренная дисциплина относится к не вытесняющим. К достоинствам этой дисциплины, прежде всего, можно отнести простоту реали­зации и малые расходы системных ресурсов на формирование очереди задач. Однако эта дисциплина приводит к тому, что при увеличении загрузки вычисли тельной системы растет и среднее время ожидания обслуживания, причем ко­роткие задания (требующие небольших затрат машинного времени) вынуждены ожидать столько же, сколько и трудоемкие задания. Избежать этого недостатка позволяют дисциплины SJN и SRT. Дисциплина обслуживания SJN (shortest job next, что означает: следующим будет выполняться кратчайшее задание) требует, чтобы для каждого задания была из­вестна оценка в потребностях машинного времени. Необходимост ь сообщать ОС характеристики задач, в которых описывались бы потребности в ресурсах вычис­лительной системы, привела к тому, что были разработаны соответствующие языковые средства. В частности, язык JCL (job control language, язык управле­ния заданиями) быт одним из наиболее известных. Пользователи вынуждены были указывать предполагаемое, время выполнения, и для того, чтобы они не злоупотребляли возможностью указать заведомо меньшее время выполнения (с целью получить результаты раньше других), ввели подсчет реальных потребностей. Диспетчер задач сравнивал заказанное время и время выполнения, и в случае превышения указанной оценки в данном ресурсе ставил данное падание не в начало, а в конец очереди. Еще в некоторых ОС в таких случаях использовалась система штрафов, при которой в случае превышения заказанного машинного времени оплата вычислительных ресурсов осуществлялась уже по другим расценкам. Дисциплина обслуживания SJN предполагает, что имеется только одна очередь заданий готовых к выполнению. И задания, которые в процессе своего исполнения были временно заблокированы (например, ожидали завершения операции вводи/вывода), вновь попадают в конец очереди готовых к выполнению наравне с. вновь поступающими. Это приводит к Тому, что задания, которым требуется очень немного времени для своего завершения, вынуждены ожидать процессор наравне с длительными работами, что не всегда хорошо. Для устранения этого недостатка и была Предложена дисциплина SRT (shortest remaining time, следующее задание требует меньше всего времени для своего завершения). Все эти три дисциплины обслуживания могут использоваться для пакетных режимов обработки, когда пользователь не вынужден ожидать реакции системы, а просто сдает свое задание и через несколько часов получает свои результаты вычислений Для интерактивных же вычислений желательно прежде всего обеспечить приемлемое время реакции системы и равенство в обслуживании, если система является мультитерминальной. Если же это однопользовательская система, но с возможностью мультипрограммной обработки, то желательно, чтобы те программы, с которыми мы сейчас непосредственно работаем, имели лучшее время реакции, нежели наши фоновые задания. При этом мы можем пожелать, чтобы некоторые приложения выполняясь без нашего непосредственного участия (например, программа получения электронной почты, использующая модем и коммутируемые линии для передачи данных), тем не менее гарантированно получат необходимую им долю процессорного времени. Для решения подобных проблем используется дисциплина обслуживания, называемая RR (round robin, круговая, карусельная), и приоритетные методы обслуживания. Дисциплина обслуживания RR предполагает, что каждая задача получает процессорное время порциями (говорят: квантами времени q). После окончания кванта времени q задача снимается с процессора и он передается следующей задаче. Снятая задача ставится в конец очереди задач, готовых к выполнению Для оптимальной работы системы необходимо правильно выбрать закон, по которому кванты времени выделяются задачам. Величина кванта времени q выбирается как компромисс между приемлемым временем реакции системы па запросы пользователей (с тем чтобы их простей­шие запросы не вызывали длительного ожидания) и накладными расходами на частую смену контекста задач. Очевидно, что при прерываниях ОС вынуждена сохранить достаточно большой объем информации о текущем (прерываемом) процессе, поставить дескриптор снятой задачи в очередь, загрузить контекст за­дачи, которая теперь будет выполняться (ее дескриптор был первым в очереди готовых к исполнению). Если величина q велика, то при увеличении очереди го­товых к выполнению задач реакция системы станет плохой. Если же величина мала, то относительная доля накладных расходов на переключения между исполняющимися задачами станет большой и это ухудшит производительность системы. В некоторых ОС есть возможность указывать в явном виде величину q либо диапазон ее возможных значений, поскольку система будет стараться вы­бирать оптимальное значение сама. Вытесняющие и не вытесняющие алгоритмы диспетчеризации Диспетчеризация без перераспределения процессорного времени, то есть не вы­тесняющая многозадачность (non-preemptive multitasking) — это такой способ диспетчеризации процессов, при котором активный процесс выполняется до тех пор, пока он сам, что называется «по собственной инициативе», не отдаст управ­ление диспетчеру задач для выбора из очереди другого, готового к выполнению процесса или треда. Дисциплины обслуживания FCFS, SJN, SRT относятся к не вытесняющим. Диспетчеризация с перераспределением процессорного времени между задача­ми, то есть вытесняющая многозадачность (preemptive multitasking) — это такой способ, при котором решение о переключении процессора с выполнения одного процесса на выполнение другого процесса принимается диспетчером задач, а не самой активной задачей. При вытесняющей многозадачности механизм диспет­черизации задач целиком сосредоточен в операционной системе, и программист может писать свое приложение, не заботясь о том, как оно будет выполняться параллельно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения текущей задачи, сохраняет се контекст в дескрипторе задачи, выбирает из очереди готовых задач следующую и запускает се на выполнение, предварительно загрузив ее контекст. Дисциплина RR и многие другие, построенные на ее основе, относятся к вытес­няющим. При не вытесняющей многозадачности механизм распределения процессорного времени распределен между системой и прикладными программами. Приклад­ная программа, получив управление от операционной системы, сама определяет момент завершения своей очередной итерации и передает управление суперви­зору ОС с помощью соответствующего системного вызова. При этом естествен­но, что диспетчер задач, так же как и в случае вытесняющей мультизадачности, формирует очереди задач и выбирает в соответствии с некоторым алгоритмом (например, с учетом порядка поступления задач или их приоритетов) следую­щую задачу на выполнение. Такой механизм создает некоторые проблемы как для пользователей, так и для разработчиков. Для пользователей это означает, что управление системой может теряться на не­который произвольный период времени, который определяется процессом вы­полнения приложения (а не системой, старающейся всегда обеспечить приемле­мое время реакции на запросы пользователей). Если приложение тратит слишком много времени на выполнение какой либо работы (например, на фор­матирование диска), пользователь не может переключиться с этой задачи па дру­гую задачу (например, на текстовый или графический редактор, в то время как форматирование продолжалось бы в фоновом режиме). Эта ситуация нежелательна, так как пользователи обычно не хотят долго ждать, когда машина завершит свою задачу. Поэтому разработчики приложений для не вытесняющей операционной среды, возлагая на себя функции диспетчера задач, должны создавать приложения так чтобы они выполняли свои задачи небольшими частями. Так, упомянутая выше программа форматирования может отформатировать одну дорожку дискеты и вернуть управление системе. После выполнения других задач система возвратит управление программе форматирования, чтобы та отформатировала следующую дорожку. Подобный метод разделения времени между задачами работает, то он существенно затрудняет разработку программ и предъявляет повышенные требования к квалификации программиста. Например, в ныне уже забытой операционной среде Windows 3.x нативные приложения этой системы разделяли между собой процессорное время именно таким образом. И программисты сами должны были обеспечивать «дружественное» отношение своей программы к другим выполняемым одновременно с ней программам, достаточно часто отдавая управление ядру системы. Крайним проявлением «не дружественности» приложения является его зависание, которое приводит к общему краху системы. В системах с вытесняющей многозадачностью такие ситуации, как правило, исключены, так как центральный механизм диспетчеризации, во-первых, обеспечивает все задачи процессорным временем, а во-вторых, дает возможность иметь надежные механизмы для мониторинга вычислений и позволяет снять зависшую задачу с выполнения.