Главная страница
Навигация по странице:

  • Уменьшение требований к оперативной памяти и повышение производительности ядра

  • Отказоустойчивая файловая система Veritas

  • Переносимость приложений

  • Поддержка национальных алфавитов

  • Средства управления доступом

  • Поддержка мультипроцессирования

  • Общая организация традиционного ядра ОС UNIX

  • Принципы взаимодействия с ядром

  • Принципы обработки прерываний

  • 27. Управление процессами в UNIX

  • ос и с. ОСиС. 1. Классификация программного обеспечения


    Скачать 2.7 Mb.
    Название1. Классификация программного обеспечения
    Анкорос и с
    Дата11.12.2022
    Размер2.7 Mb.
    Формат файлаdoc
    Имя файлаОСиС.doc
    ТипДокументы
    #839260
    страница11 из 29
    1   ...   7   8   9   10   11   12   13   14   ...   29

    Характеристика FreeBSD.


    • На платформе Intel FreeBSD реализована как 32-х битная ОС, она не содержит 16-битного кода. Платформа i386 выполняет приложения быстрее в 32-х битном режиме, чем в 16-битном; это приводит к повышению производительности.

    • На платформе Alpha FreeBSD реализована как 64-битная ОС.

    • FreeBSD использует вытесняющую многозадачность с динамическим распределением приоритетов для обеспечения уравновешенного и чёткого разделения ресурсов между приложениями и пользователями.

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

    • FreeBSD обладает всеми средствами для работы в сетях TCP/IP, поддерживая, в том числе, SLIP, PPP, NFS, NIS. Это означает, что система с FreeBSD может взаимодействовать с другими системами и также работать в качестве ответственного сервера, обеспечивая такие жизненно необходимые функции, как NFS (network file system, применяется для удалённого доступа к файлам), e-mail сервер; на её базе можно создать сервер с www, ftp, маршрутизацией и firewall'ом для обслуживания организации. Кроме того, набор ports включает в себя ПО для связи с сетями на базе других протоколов, кроме IP.

    • Механизм защиты памяти гарантирует, что ни приложения, ни пользователи не будут испытывать проблемы с разделением ресурсов. Если приложение зависает, это не может затронуть работу других приложений.

    • FreeBSD включает в себя разработку, являющуюся промышленным стандартом, - X Window System (X11R6) GUI - графический пользовательский интерфейс.

    • Набор ports и packages (готовое к использованию программное обеспечение) включает в себя более 2-х тысяч приложений.

    • Тысячи дополнительных легко устанавливаемых приложений доступны в Интернете. FreeBSD совместима в исходных кодах со многими популярными коммерческими UNIX-системами, и большинство приложений для этих систем требуют нескольких изменений или вообще не требуют изменений для успешной компиляции их под FreeBSD. Больше всего свободно распространяемого ПО было разработано под BSD-like OS. В итоге, FreeBSD является платформой, на которую легче всего портировать ПО.

    • Переносимая по необходимости на диск виртуальная память (VM) и модель "совмещённая VM/кэш" эффективна при использовании жадных до памяти приложений и сохраняет удовлетворительное время отклика системы на запросы пользователей.

    • Разделяемые библиотеки (аналог микрософтовских dll) обеспечивают эффективное использование дискового пространства и памяти.

    • В состав ОС уже входит полный комплект приложений для разработки ПО на Си, Си++ и Фортране. Средства для работы с другими языками программирования содержатся в наборе ports и packages.

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

    • В дистрибутив входит также обширная online-документация, включая традиционное online-руководство (man pages) и handbook в html-формате + 700-страничная книга "The Complete FreeBSD" в электронном виде.



    UnixWare

    UnixWare представляет собой полную реализацию наиболее современной версии системы UNIX для Intel-совместимых платформ - UNIX System V Release 4.2 (SVR4.2). Система сочетает высокую производительность, удобный графический интерфейс и возможности гибкой интеграции с сетями NetWare. Реализованная в ядре поддержка протокола IPX предоставляет пользователям UnixWare прозрачный доступ к сетевым ресурсам NetWare. DOS-клиенты сети получают при этом терминальный доступ к приложениям на сервере UnixWare и возможность коллективного использования файлов, хранящихся на сервере NetWare. Система выпускается в двух вариантах: UnixWare Personal Edition для работы в качестве клиента и однорангового сервера на 2 соединения, UnixWare Application Server, для построения мощного многопользовательского сервера приложений.

    Версия UNIX SVR4.2 была создана фирмой UNIX System Laboratories (USL) в 1992 году как развитие версии UNIX System V Release 4. Для совместимости этой версии с наиболее популярными в секторе локальных сетей операционными системами Novell NetWare было создано совместное предприятие USL и Novell Univel, которое разработало и выпустило на рынок операционную систему UnixWare.
    Уменьшение требований к оперативной памяти и повышение производительности ядра
    Одной из важнейших особенностей UNIX SVR4.2 является возможность эффективно работать на ЭВМ с процессором 386SX и 6 MБ оперативной памяти. Эта возможность появилась в результате работы, направленной на уменьшение размера и увеличение скорости важнейших программных компонентов системы, включая ядро и средства графики. Была проделана работа по улучшению программ загрузчика системы и закрытия системы, а также и драйверов устройств SCSI.

    Изменения в структуре ОС и повышение производительности снизили минимальные требования к оперативной памяти на 30%. Преимущества UNIX SVR4.2 по требованиям к объему оперативной памяти еще более заметны по сравнению с системами с аналогичными возможностями. Так, для работы ПО Solaris фирмы SUN требуется минимум 12 МБ памяти, причем для нормальной работы SUN рекомендует использовать 16 МБ ОЗУ.

    В ОС UNIX SVR4.2 производительность при нормальной загрузке, при "грязной" загрузке после неаккуратного закрытия, а также при закрытии системы значительно увеличилась по сравнению с предыдущими версиями. В частности, время закрытия системы сократилось на 58% (с 38 до 17 секунд) на типичной аппаратной конфигурации ЭВМ. Загрузка системы при нормальных условиях эквивалентна физическому включению машины после аккуратного закрытия. Время нормальной загрузки сократилось на 48% (с 65 до 38 секунд). При "грязной" загрузке эти времена составляют соответственно 140 и 40 секунд (71%).
    Отказоустойчивая файловая система Veritas
    В дополнение к стандартным файловым системам (BFS, UFS, S5) UnixWare поддерживает: CD-ROM File System (CDFS), NetWare UNIX Client File System (NUCFS) и Veritas Fault Resilient File System. Система Veritas, основанная на транзакционном механизме операций с файловой системой, обеспечивает не только улучшенную производительность, но и высокую устойчивость к отказам системы.
    Переносимость приложений
    Унифицированная программная среда UnixWare обеспечивает поддержку широкого спектра приложений различных систем UNIX, включая SCO, ISC UNIX System V R3, SCO XENIX и BSD UNIX. Совместимость приложений обеспечивается строгим соблюдением промышленных стандартов UNIX System V Application Binary Interface (ABI), System V Interface Definition (SVID), iBSC2 и др.
    Графический интерфейс
    Стандарт X-Window, на основе которого построен мощный и удобный графический пользовательский интерфейс (GUI) UnixWare, в сочетании с сетевыми возможностями системы, позволяет эффективно использовать перспективные архитектуры типа "клиент-сервер". Графическая среда Desktop Manager позволяет выбирать одну из двух стандартных систем графического интерфейса (OSF/Motif или OPEN LOOK) и обеспечивает при работе с графическими объектами на экране доступ к приложениям, большинству системных программ и развитой системе подсказок. Предусмотрена также возможность непосредственного программирования функций Desktop Manager.
    Поддержка национальных алфавитов
    В UnixWare предусмотрен широкий набор средств "интернационализации", включающий поддержку различных раскладок клавиатуры, наборов символов и языков пользовательского интерфейса.
    Масштабируемые шрифты
    В комплект поставки UnixWare входит система Adobe Type Manager, обеспечивающая доступ к тысячам существующих масштабируемых шрифтов формата Type 1.
    Средства управления доступом
    В дополнение к средствам идентификации пользователей по имени и паролю UnixWare имеет развитые средства управления доступом к ресурсам системы. Имеется возможность полного протоколирования работы системы, включая регистрацию выполняемых команд и доступа к информации.
    Интеграция с NetWare
    UnixWare обеспечивает полную интеграцию с сетью NetWare, благодаря которой рабочие станции UnixWare имеют доступ к ресурсам (файловая система, принтеры, почта) сети NetWare, как и другие ee клиенты, а остальные пользователи локальной сети получают также терминальный доступ к серверу приложений UnixWare. При этом как на уровне клиента, так и на уровне сервера приложений операционная система UnixWare использует традиционный для NetWare сетевой протокол IPX. Пользователям UnixWare в локальной сети NetWare предоставляются следующие виды поддержки:


    • прозрачный доступ к файлам, принтерам и электронной почте;

    • протоколы IPX, SPX и NCP, встроенные в ядро операционной системы;

    • поддержка протоколов SAP (Service Advertising Protocol) и RIP (Routing Information Protocol);

    • графический пользовательский интерфейс с функциями NetWare.


    Поддержка мультипроцессирования
    Начиная с версии 2.0, UnixWare поддерживает симметричное мультипроцессирование (SMP). Оба варианта UnixWare 2.01 (Application Server и Personal Edition) поддерживают в базовой поставке 2 симметричных процессора Intel. UnixWare Application Server может поддерживать (за счет добавления модулей поддержки дополнительных процессоров) до 8 процессоров Intel. UnixWare 2.01 является многонитевой операционной системой.
    SCO UNIX System V/386
    Варианты ОС UNIX, производимые компанией SCO и предназначенные исключительно для использования на Intel-платформах, до сих пор базируются на лицензированных исходных текстах System V 3.2. Однако SCO довела свои продукты до уровня полной совместимости со всеми основными стандартами (в тех позициях, для которых существуют стандарты). Консерватизм компании объясняется прежде всего тем, что ее реализация ОС UNIX включает наибольшее количество драйверов внешних устройств и поэтому может быть установлена практически на любой Intel-платформе. Естественно, при переходе на другой вариант опорных исходных текстов ядра системы могла бы потребоваться массовая переделка драйверов. Тем не менее SCO имеет соглашение с французской компанией Chorus Systems о разработки новой версии SCO UNIX, базирующейся на микроядре Chorus и предназначенной для использования в системах реального времени.

    В настоящее время компания SCO приобрела у Novell ОС UnixWare и работает над версией UNIX, совмещающей особенности SCO UNIX и UnixWare в рамках одной системы.

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

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

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

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

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

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

    Машинно-зависимая часть традиционного ядра ОС UNIX включает следующие компоненты:


    • раскрутка и инициализация системы на низком уровне (пока это зависит от особенностей аппаратуры);

    • первичная обработка внутренних и внешних прерываний;

    • управление памятью (в той части, которая относится к особенностям аппаратной поддержки виртуальной памяти);

    • переключение контекста процессов между режимами пользователя и ядра;

    • связанные с особенностями целевой платформы части драйверов устройств.


    Основные функции
    К основным функциям ядра ОС UNIX принято относить следующие:


    1. Инициализация системы - функция запуска и раскрутки. Ядро системы обеспечивает средство раскрутки (bootstrap), которое обеспечивает загрузку полного ядра в память компьютера и запускает ядро.

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

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

    4. Управление файлами - функция, реализующая абстракцию файловой системы, - иерархии каталогов и файлов. Файловые системы ОС UNIX поддерживают несколько типов файлов. Некоторые файлы могут содержать данные в формате ASCII, другие будут соответствовать внешним устройствам. В файловой системе хранятся объектные файлы, выполняемые файлы и т.д. Файлы обычно хранятся на устройствах внешней памяти; доступ к ним обеспечивается средствами ядра. В мире UNIX существует несколько типов организации файловых систем. Современные варианты ОС UNIX одновременно поддерживают большинство типов файловых систем.

    5. Коммуникационные средства - функция, обеспечивающая возможности обмена данными между процессами, выполняющимися внутри одного компьютера (IPC - Inter-Process Communications), между процессами, выполняющимися в разных узлах локальной или глобальной сети передачи данных, а также между процессами и драйверами внешних устройств.

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


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

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

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

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

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

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

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

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

    25. Типы драйверов UNIX
    Любому программисту должно быть ясно, что простое объявление внешнего устройства специальным файлом не даст возможности работать с этим устройством, если не создан и соответствующим образом не подключен к системе специальный программный код, соответствующий специфике данного устройства. Как и в большинстве современных операционных систем, такого рода программный код в ОС UNIX называется драйвером устройства (в этом контексте слово драйвер лучше всего понимать в значении "управляющий").

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

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

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

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

    Подробности по поводу разных способов организации драйверов в ОС UNIX см. в разделе 3.3.

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

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

    Связь ядра системы с драйверами (рисунок 5.15) обеспечивается с помощью двух системных таблиц:


    • bdevsw - таблица блок-ориентированных устройств и

    • cdevsw - таблица байт-ориентированных устройств.

    Для связи используется следующая информация из индексных дескрипторов специальных файлов:


    • класс устройства (байт-ориентированное или блок-ориентированное),

    • тип устройства (лента, гибкий диск, жесткий диск, устройство печати, дисплей, канал связи и т.д.)

    • номер устройства.


    Класс устройства определяет выбор таблицы bdevsw или cdevsw. Эти таблицы содержат адреса программных секций драйверов, причем одна строка таблицы соответствует одному драйверу. Тип устройства определяет выбор драйвера. Типы устройств пронумерованы, т.е. тип определяет номер строки выбранной таблицы. Номер устройства передается драйверу в качестве параметра, так как в ОС UNIX драйверы спроектированы в расчете на обслуживание нескольких устройств одного типа.

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

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

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




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

    Аналогично организована работа при чтении данных с устройства.

    Драйвер блок-ориентированного устройства состоит в общем случае из секций открытия и закрытия файлов, а также секции стратегии. Кроме адресов этих секций, в таблице bdevsw указаны адреса так называемых таблиц устройств (rktab). Эти таблицы содержат информацию о состоянии устройства - занято или свободно, указатели на буфера, для которых активизированы операции обмена с данным устройством, а также указатели на цепочку буферов, в которых находятся блоки данных, предназначенные для обмена с данным устройством.

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

    После запуска устройства управление возвращается процессу, выдавшему запрос к драйверу.





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

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

    С появлением многоуровневых сетевых протоколов, таких как TCP/IP (US Defense Advanced Research Project Agency's Transmission Control Protocol/Internet Protocol), SNA (IBM's System Network Architecture), OSI (Open Systems Internetworking), X.25 и др. стало понятно, что в ОС UNIX требуется некоторая общая основа организации сетевых средств, основанных на многоуровневых протоколах. Для решения этой проблемы было реализовано несколько механизмов, обладающих примерно одинаковыми возможностями, но не совместимых между собой, поскольку каждый из них являлся результатом некоторого индивидуального проекта.

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

    Во многом эта проблема была решена компанией AT&T, которая предложила и реализовала механизм потоков (STREAMS), обеспечивающий гибкие и модульные возможности для реализации драйверов устройств и коммуникационных протоколов. Потоки были впервые реализованы Деннисом Ритчи в 1984 году и были включены в пакет Networking Support Facilities (NSU) UNIX.

    В UNIX потоки были включены как основа реализации существующего символьного ввода/вывода. Однако в реализацию потоков были включены интерфейс драйвера устройства (DDI - Device Driver Interface) и интерфейс между драйвером и ядром (DKI - Device Kernel Interface), которые в совокупности одновременно обеспечивают возможности по взаимодействию драйвера устройства с ядром системы и простоту повторного использования имеющегося исходного кода драйверов. С использованием механизма потоков были переписаны практически все символьные драйверы, полностью переработаны подсистема управления терминалами и механизм программных каналов (pipes).

    Если не вдаваться в детали, Streams представляют собой связанный набор средств общего назначения, включающий системные вызовы и подпрограммы, а также ресурсы ядра. В совокупности эти средства обеспечивают стандартный интерфейс символьного ввода/вывода внутри ядра, а также между ядром и соответствующими драйверами устройств, предоставляя гибкие и развитые возможности разработки и реализации коммуникационных сервисов. При этом механизм потоков не навязывает какой-либо конкретной архитектуры сети и/или конкретных протоколов. Как и любой другой драйвер устройства, потоковый драйвер представляется специальным файлом файловой системы со стандартным набором операций: open, close, read, write и ioctl. Простейшая форма организации потокового интерфейса показана на рисунке 2.4.

    Когда пользовательский процесс открывает потоковое устройство, пользуясь системным вызовом open, ядро связывает с драйвером заголовок потока. После этого пользовательский процесс общается с заголовком потока так, как если бы он представлял собой обычный драйвер устройства. Другими словами, заголовок потока отвечает за обработку всех системных вызовов, производимых пользовательским процессом по отношению к потоковому драйверу. Если процесс выполняет запись в устройство (системный вызов write), заголовок потока передает данные драйверу устройства в нисходящем направлении. Аналогично, при реализации чтения из устройства (системный вызов read) драйвер устройства передает данные заголовку потока в восходящем направлении.


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

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

    27. Управление процессами в UNIX
    1   ...   7   8   9   10   11   12   13   14   ...   29


    написать администратору сайта