Remkomplekty.ru

IT Новости из мира ПК
4 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Архитектура операционной системы реферат

Архитектура операционной системы

Автор работы: Пользователь скрыл имя, 08 Апреля 2013 в 20:38, реферат

Описание работы

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

Содержание работы

Введение 3
1. Ядро и вспомогательные модули ОС 4
2. Ядро в привилегированном режиме 7
3. Многослойная структура ОС 11
4. Аппаратная зависимость и переносимость ОС 15
5. Типовые средства аппаратной поддержки 16
6. Машинно-зависимые компоненты ОС 18
7. Переносимость операционной системы 20
8. Микроядерная архитектура 22
9. Преимущества и недостатки микроядерной архитектуры 25
10. Двоичная совместимость и совместимость исходных текстов 27
11. Способы реализации прикладных программных сред 29
Заключение 33

Файлы: 1 файл

Архитектура операционной системы.docx

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«БАШКИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Факультет математики и информационных технологий

Кафедра информационных технологий

Реферат на тему

Архитектура операционной системы

Специальность 010501 – Прикладная математика и информатика

Выполнил: студент n-го курса

Иванов Иван Иванович

Д.ф.-м.н., доцент кафедры ПиЭИ

1. Ядро и вспомогательные модули ОС 4

2. Ядро в привилегированном режиме 7

3. Многослойная структура ОС 11

4. Аппаратная зависимость и переносимость ОС 15

5. Типовые средства аппаратной поддержки 16

6. Машинно-зависимые компоненты ОС 18

7. Переносимость операционной системы 20

8. Микроядерная архитектура 22

9. Преимущества и недостатки микроядерной архитектуры 25

10. Двоичная совместимость и совместимость исходных текстов 27

11. Способы реализации прикладных программных сред 29

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

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

Большинство современных операционных систем представляют собой хорошо структурированные модульные системы, способные к развитию, расширению и переносу на новые платформы. Какой-либо единой архитектуры ОС не существует, но существуют универсальные подходы к структурированию ОС.

  1. Ядро и вспомогательные модули ОС

Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы:

  • ядро — модули, выполняющие основные функции ОС;
  • модули, выполняющие вспомогательные функции ОС.

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

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

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

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

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

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

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

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

Некоторая программа может существовать определенное время как пользовательское приложение, а потом стать частью ОС, или наоборот. Ярким примером такого изменения статуса программы является Web-браузер компании Microsoft, который сначала поставлялся как отдельное приложение, затем стал частью операционных систем Windows NT 4.0 и Windows 95/98, а сегодня существует большая вероятность того, что по решению суда этот браузер снова превратится в самостоятельное приложение.

Рис. 1. Нечеткость границы между ОС и приложениями

Вспомогательные модули ОС обычно подразделяются на следующие группы:

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

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

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

Рис. 2. Взаимодействие между ядром и вспомогательными модулями ОС

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

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

  1. Ядро в привилегированном режим е

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

Читать еще:  Многоуровневая архитектура ис

Обеспечить привилегии операционной системе невозможно без специальных средств аппаратной поддержки. Аппаратура компьютера должна поддерживать как минимум два режима работы — пользовательский режим (user mode) и привилегированный режим, который также называют режимом ядра (kernel mode), или режимом супервизора (supervisor mode). Подразумевается, что операционная система или некоторые ее части работают в привилегированном режиме, а приложения — в пользовательском режиме.

Так как ядро выполняет все основные функции ОС, то чаще всего именно ядро становится той частью ОС, которая работает в привилегированном режиме (рис. 3). Иногда это свойство — работа в привилегированном режиме — служит основным определением понятия «ядро».

Рис. 3. Архитектура операционной системы с ядром в привилегированном режиме

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

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

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

Между количеством уровней привилегий, реализуемых аппаратно, и количеством уровней привилегий, поддерживаемых ОС, нет прямого соответствия. Так, на базе четырех уровней, обеспечиваемых процессорами компании Intel, операционная система OS/2 строит трехуровневую систему привилегий, а операционные системы Windows NT, UNIX и некоторые другие ограничиваются двухуровневой системой.

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

Основные концепции построения ОС. Архитектура ОС;

Примеры реализации ОС (на примере ОC Windows)

Инструментарий разработки и отладки компонент ОС

64. Утилиты по ОС Windows XP. Основные возможности инструментария по анализу и разработке компонент ОС: памяти, процессов и потоков, ввода-вывода, отладки. Использование дампа.

Основные концепции построения ОС.

0) Принцип модульности.

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

1) Принцип функциональной избирательности.

Для организации эффективной работы ОС, необходимо выделить и хранить в ОЗУ некоторые модули, составляющие ядро:

· Модули по управлению системы прерываний;

· Средство управления выполнения программ (загрузка, приостановка, остановка);

· Модули по управлению процессом (распределение процессорного времени), т.е. диспетчеры программ;

· Модули по управлению выделения памяти. В зависимости от ОС в ядро могут ещё входить другие модули;

· Транзитные модули (загружаются в ОЗУ по мере необходимости, при нехватке ОЗУ могут быть выгружены).

2) Принцип генерируемости ОС.

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

· Исходный код ОС;

· Компилятор с языка программирования на котором система написана;

· Специальная программа и входной язык для неё, который позволяет управлять процессом генерации.

3) Принцип функциональной избыточности.

В состав ОС должно входит несколько типов ПО для выполнения одинаковых функций (поддержка разных ФС).

4) Принцип виртуализации.

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

5) Принцип независимости программ от внешних устройств.

Связь программ с конкретным внешним устройством производится не на этапе трансляции, а на этапе выполнения программы. Получается выгода: не нужна лишняя «перекомпиляция».

6) Принцип совместимости.

Способность выполнять программы для другой ОС или даже для другой аппаратной платформы.

2 уровня совместимости:

· По выполняемому коду (бинарная). Условия совместимости:

◦ На уровне команд процессора (одна и та же платформа);

◦ Совместимость на уровне системных вызовов;

◦ Совместимость на уровне библиотечных вызовов, если являются динамично связываемыми.

· По исходному коду. Требуется выполнение следующих условий:

◦ Наличие компилятора платформы, на котором написана программа;

◦ Совместимость на уровне системных вызовов;

◦ Совместимость на уровне библиотечных вызовов.

7) Принцип открытой наращиваемой ОС (открыт исходный код).

Целостность ОС сохраняется (UNIX).

8) Принцип мобильности (переносимости).

ОС должна легко переноситься на другую аппаратную платформу. Правила создания переносимых ОС:

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

· Необходимо избегать кода, который непосредственно работает с аппаратным обеспечением.

9) Принцип обеспечения безопасности и защиты.

19. Защита системы от пользователя;

20. Защита от несанкционированного доступа.

Архитектура ОС.Различают 3 базовых типа архитектуры операционных систем:

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

Данную архитектуру имели самые первые поколения операционных систем.

· Имеются проблемы: расширяемости, переносимости исовместимости ОС;

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

0) Полная функциональность операционной системы разделяется на уровни, например уровень управления аппаратурой, уровень управления памятью, уровень файловой системы, уровень управления процессами и т.п.

1) Для каждого уровня определяются интерфейс взаимодействия, т.е. некоторый набор правил, согласно которым следует обращаться за услугами данного уровня.

2) Взаимодействие уровней строится таким образом, что каждый уровень может обращаться за услугами только к соседнему нижележащему уровню через его интерфейс.

3) Внутренние структуры данных каждого уровня не доступны другим уровням, а реализации процедур уровня скрыты и не зависят от реализаций процедур внутри других уровней.

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

Читать еще:  Vpn ошибка сертификата

Характерно вертикальное иерархическое распределение функциональности.

• Архитектура типа клиент-сервер на основе микроядра.

Является наиболее совершенной с точки зрения расширяемости и переносимости операционных систем.

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

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

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

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

Требования к архитектуре операционной системы

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

Во-первых, она управляет аппаратными и программными ресурсами системы. В настольном компьютере такими ресурсами являются процессор, оперативная память, дисковое пространство и т.п. (В сотовом телефоне это клавиатура, экран, адресная книга, номеронабиратель, батарея и средства подключения к сети).

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

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

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

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

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

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

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

3) Защищенность. Система должна быть защищена как от внутренних, так и от внешних ошибок, сбоев и отказов. Ее действия должны быть всегда предсказуемы, а приложения не должны иметь возможности наносить вред. Современная ОС защищает данные и другие ресурсы вычислительной системы от несанкционированного доступа и от попыток непреднамеренного повреждения этих данных.

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

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

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

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

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

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

Дата добавления: 2014-12-19 ; просмотров: 4 | Нарушение авторских прав

Архитектура операционных систем Семестр 2, Лекция 1. — презентация

Презентация была опубликована 4 года назад пользователемАркадий Радолинский

Похожие презентации

Презентация на тему: » Архитектура операционных систем Семестр 2, Лекция 1.» — Транскрипт:

1 Архитектура операционных систем Семестр 2, Лекция 1

2 Архитектура ОС Состав модулей (компонент) ОС Структура связей между отдельными модулями ОС Принципы взаимодействия модулей ОС Принципы функционирования ОС в плане выполнения отдельных функций и в целом

3 Типы архитектур Монолитная архитектура ОС с ядром ОС с ядром в привилегированном режиме Многослойная архитектура Микроядерная архитектура

4 Монолитная архитектура Нет разделения на отдельные модули Модули ОС сильно связаны Затруднено обновление операционной системы Затруднена разработка и отладка ОС Существует только в теории ОС

5 ОС с ядром Выделяется специальный модуль – ядро Для выполнения дополнительных задач используются вспомогательные модули Ядро Вспомогательный модуль Приложение пользователя

6 Функции ядра Внутрисистемные задачи организации вычислительного процесса Создание прикладной программной среды (предоставление API-функций приложениям пользователя и вспомогательным модулям)

7 Особенности реализации ядра Ядро реализует только основные функции ОС При реализации ядра важна скорость выполнения его функций Функции ядра реализуются как резидентные модули Ядро реализуется как программный модуль специального формата

8 Виды вспомогательных модулей Утилиты ОС Системные обрабатывающие программы (СОП) Программы предоставления пользователю дополнительных услуг Библиотеки процедур различного назначения

9 Особенности реализации вспомогательных модулей Реализуются в виде дополнительных программ или библиотек Загружаются в ОП только на время использования, т.е. являются транзитными модулями Формат модулей совпадает с форматом приложений пользователя Нет четкого различия между вспомогательными модулями и приложениями пользователя Для выполнения своих задач используют API- функции, предоставляемые ядром

Читать еще:  Ошибка 4013 как исправить

10 Достоинства ОС с ядром Легкая расширяемость Возможность обеспечения защиты системного программного кода и данных ОС

11 Ядро в привилегированном режиме Повышение привилегий основной части ОС по сравнению со вспомогательными модулями и приложениями пользователя Повышение уровня защищенности системного программного кода и данных операционной системы Пользовательский режим Привилегированный режим Ядро Утилиты СОП Приложения

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

13 Пользовательский режим Для выполнения вспомогательных модулей ОС Для выполнения приложений пользователя Обеспечивает защиту областей памяти приложений от воздействия других приложений (выполнение приложений в защищенном адресном пространстве)

14 Особенности выполнения приложений в пользовательском режиме Работа приложения Системный вызов Работа ядра Время переключения режимов

15 Многослойная структура ОС Развитие архитектуры ОС с ядром в привилегированном режиме Повышение уровня защищенности отдельных модулей ОС от воздействия других модулей Повышение уровня абстрагирования модулей верхних уровней ОС от аппаратной части ВС Повышение уровня независимости модулей Аппаратная часть Ядро Вспомогательные модули

16 Схема функционирования ОС с многослойной архитектурой Слой k Слой k+1 Межслойный интерфейс К слою k-1 К слою k+2 … … …

17 Типовой состав слоев ОС Средства аппаратной поддержки ОС Машинно-зависимые компоненты Базовые механизмы ядра Менеджеры ресурсов Интерфейс системных вызовов

18 Средства аппаратной поддержки операционной системы Часть функций операционной системы может быть реализована аппаратно Система прерываний Средства поддержки привилегированного режима Средства переключения контекстов Средства защиты областей памяти

19 Машинно-зависимые компоненты Напрямую взаимодействуют с аппаратной частью ВС В идеале полностью изолируют аппаратуру от модулей ОС, находящихся выше и приложений пользователей

20 Базовые механизмы ядра Наиболее примитивные функции и объекты ядра Переключение контекстов Диспетчеризация процессов Перемещение страниц памяти на диск и обратно Системные объекты

21 Менеджеры ресурсов Мощные функциональные модули, осуществляющие управление основными ресурсами системы Менеджеры процессов, ввода/вывода, файловой системы, безопасности…

22 Интерфейс системных вызовов Верхний слой ядра, взаимодействующий с системными утилитами и приложениями пользователя Образуют прикладной программный интерфейс

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

24 Особенности выполнения приложений в ОС с микроядерной архитектурой Микроядро Приложения пользователей Сервер Утилиты

25 Тенденции в развитии ОС Аппаратная переносимость Совместимость Множественные прикладные среды

26 Аппаратная переносимость Код операционной системы может быть достаточно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа

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

28 Совместимость Возможность перекомпиляции и/или исполнения приложений одной операционной системы в среде другой операционной системы

29 Типы совместимости Двоичная совместимость Существует возможность исполнения приложения одной ОС исполнить в среде другой ОС без перекомпиляции исходных кодов Совместимость исходных кодов Приложение одной ОС можно успешно перекомпилировать в другой ОС Совместимость на уровне вызовов API- функций Совместимость на уровне структуры исполняемого файла

30 Множественные программные среды Позволяют в рамках одной операционной системы исполнять приложения различных ОС без перекомпилирования исходных кодов Предоставление приложениям пользователей наборов API-функций различных операционных систем

31 Варианты реализации множественных программных сред Трансляция системных вызовов Равноправные прикладные программные интерфейсы Микроядерный подход

32 OS1 Трансляция системных вызовов Модули ядра API OS1 OS1 OS2 OS1 OS3 API OS2API OS3 Транслятор 2Транслятор 3

33 Равноправные API Модули ядра API OS1 OS1OS2OS3 API OS2API OS3

34 Микроядерный подход Микроядро OS1OS2OS3 API3API2API1 Сервер Приложения

Курс «Основы операционных систем»

2019/2020 учебный год

Преподаватели

Для студентов групп /80001 и /80003, которые планируют сдавать дифференцированный зачёт по курсу 29 января 2020 года, установлен срок сдачи на проверку результатов выполнения 2-й контрольной работы — 28 января 2020 года до 18.00.

Список студентов, которым требуется для допуска к дифференцированному зачёту написать контрольный тест по курсу (актуальность — 24 января 2020 года):

ПРАВИЛА УЧЁТА РЕЗУЛЬТАТОВ ТЕСТИРОВАНИЯ

  1. Студент, набравший не менее 17 баллов, допущен к сдаче дифференцированного зачёта.
  2. Студент, набравший от 17 до 25 баллов (включительно), вправе получить итоговую оценку не выше «удовлетворительно».
  3. Студент, набравший от 26 до 34 баллов (включительно), вправе получить итоговую оценку не выше «хорошо».
  4. Студент, набравший от 35 до 50 баллов (включительно), вправе получить итоговую оценку «отлично».
  5. Результаты обучения, полученные для других форм аттестации по курсу (домашние и контрольные работы, рефераты, выступления на семинарах и т.п.) не могут быть использованы для повышения итоговой оценки, сформированной по итогам тестирования.
  6. Повторное тестирование допускается (не более, чем дважды) лишь для студентов, не набравших 17 баллов.

ДИФФЕРЕНЦИРОВАННЫЙ ЗАЧЁТ ДЛЯ ГРУПП: /80001 и /80003 СОСТОИТСЯ 29 ЯНВАРЯ 2020 ГОДА ПО РАСПИСАНИЮ ЗИМНЕЙ СЕССИИ.

СТУДЕНТЫ, УСПЕШНО СДАВШИЕ ДИФФЕРЕНЦИРОВАННЫЙ ЗАЧЁТ ИЛИ ОТЧИСЛЕННЫЕ ЗА АКАДЕМИЧЕСКУЮ НЕУСПЕВАЕМОСТЬ, УДАЛЕНЫ ИЗ СПИСКОВ ГРУПП (С СОХРАНЕНИЕМ ПРЕЖНИХ ПОРЯДКОВЫХ НОМЕРОВ СТУДЕНТОВ В ГРУППАХ) .

ТРЕБОВАНИЯ КО ВТОРОЙ КОНТРОЛЬНОЙ РАБОТЕ:

1) все сценарии должны быть исполнимыми файлами на языке bash;

2) номер варианта контрольной работы должен соответствовать порядкового номеру студента в списке группы, приведённом на сайте курса;

3) каждый сценарий должен решать строго определённую функциональную задачу с предопределёнными в задании исходными данными («универсальные» решения недопустимы);

4) любое некорректное (не отвечающее его спецификации) выполнение сценария, означает отсутствие решения соответствующей задачи;

5) все присылаемые файлы сценариев (а также конфигурационные файлы этих сценариев) должны быть полностью готовы к использованию в ОС Ubuntu (никакие лишние файлы присылать не надо).

РЕКОМЕНДУЕТСЯ всем студентам, уже приславшим на проверку свои решённые варианты, повторно проверить их на соответствие вышеуказанным требованиям.

СПИСКИ СТУДЕНТОВ, успешно написавших контрольную работу по ОС Windows (актуальность — 29 января 2020 года)

  1. Бойцов Илья
  2. Валиев Георгий
  3. Загороднов Дмитрий
  4. Динмухаметов Марат
  5. Ковальчишин Кирилл
  6. Кошелева Анна
  7. Кузьмин Григорий
  8. Кузьмин Дмитрий
  9. Кучмин Дмитрий
  10. Назаров Дмитрий
  11. Терентьев Даниил
  12. Пешков Даниил
  13. Ульянов Андрей
  14. Фёдорова Дарья
  15. Шелаев Никита
  1. Безбородов Илья
  2. Кобыжев Александр
  3. Лихолетов Михаил
  4. Прозоров Филипп
  5. Рубан Станислав
  6. Самсонов Сергей
  7. Смирнов Лев
  8. Ткаченко Даниил
  9. Царькова Юлия
  10. Шалыгин Дмитрий
  11. Шерепа Никита
  1. Астудина Анастасия
  2. Васильев Роман
  3. Викторов Илья
  4. Викторова Дарья
  5. Джеус Андрей
  6. Джужуев Эдуард
  7. Дзюба Богдан
  8. Зайцева Елизавета
  9. Курняков Пётр
  10. Никифоров Тимофей
  11. Привалов Дмитрий
  12. Рубша Анастасия
  13. Ступин Алексей
  14. Танашкин Валерий
  15. Тарасенко Никита
  16. Фам Тхи Тхань Бинь
  17. Хвацкин Леонид
  18. Цаплин Илья
  19. Шрамков Максим
  1. Иванов Кирилл
  2. Карелин Олег
  3. Кашутин Андрей
  4. Кейта Абубакар Сидики
  5. Луняк Николай
  6. Петрунина Юлия
  7. Савельев Дмитрий
  8. Смирнов Никита
  9. Сухачёв Никита
  10. Трифонова Полина
  11. Фёдоров Сергей
  12. Чернышев Ярослав
  1. Бедрин Алексей
  2. Бибишев Пётр
  3. Быков Егор
  4. Васильев Игорь
  5. Горюнов Виталий
  6. Касаткин Дмитрий
  7. Медведев Данил
  8. Невоструева Яна
  9. Обоёнкова Владилена
  10. Сальдивар Мендес Габриэла
  11. Трачук Илья
  12. Филимонов Артём
  13. Юсупова Диана
  1. Есин Никита
  2. Иванов Игорь
  3. Киселёв Иван
  4. Кузин Евгений
  5. Курошев Кирилл
  6. Логвинов Денис
  7. Ложкин Андрей
  8. Луцкевич Анна
  9. Ляшенко Валерия
  10. Маковский Андрей
  11. Матвеец Андрей
  12. Пучкина Виктория
  13. Сахибгареев Рамис
  14. Солянкин Илья
  15. Телепова Мария

Ссылка на основную публикацию
Adblock
detector