Введение. Linux как инструмент решения задач. Архитектура «цветочек»
Позикс очерчивает четкие рамки, а современные ситсемы за них выступают. И файловые системы, и права доступа, и т.д. Из этого следует, что если в прошлом семестре мы инварианты тол ько отмечали, то в этом семестре к ним надо приглядеться гораздо более внимательней, потому что именно они позволят решать пользовательчкие задачи из коробки.
Сюда же отностяся и новомодные вещи типа редактирование музыкальной коллекци или обработка мультимедийной информации вообще. Ели задача допускает формулировку вход-действие-выход, то средствами интеграции различных утилит эта задача будет решена.
На этой лекции прямо сейчас будет о чём? Там была вводная лекция про архитектуру системы как таковой. Тем половинки нынешней лекции - цветочек. Изучая операционную систему гну линукс как инструмент решения повседеневных задач мы не интересовлаись её устройством внутри себя. Теперь наша задач изучить это устройство и решать не повседневные задачи, а вполне себе любые.
Ядром ос является её ядро. Подобного рода архитектура восходит к теоретикам и практикам построения вычислсительных систем начиная с древнейших времён, которые явно указывали как именно должна быть сделана вычю машина, чтобы наша ос на этой аппаратной части хорошо работала. Доэтого надо ещё дожить, но то, тчо поучается в результате это как раз адаптацияжесткой и грубой практики к этой теории. Что такое ядро с точки зрения архитектуры вс? это изрядный кусок кода. Чем он отличается от других кусокв кода, которые тоже работают в этой ос?
- ядро всегда в памяти. Оно есть всегда. Зачем оно всегда? Затем, что оно обеспечивает изрядную часть программного стандарта, а именно тк часть, которая не может быть обеспечна обычным процессом в его правах.
- режим супервизора. режим супервизора заключается в том, что коду выполняющемуся в нём доступны все команды процессора, в том числе те, что манипултируют уникальными ресурсами -- выделяют память, цправляет контекстами.
Задача ядра состоит в том чтобы рулить теми ресурсами, которыми обычное приложение рулить просто не сможет. В ос с монолитным ядром, которой, в частности, является гну линукс, также в ведение ядра находится доступ к некоторым внешним устройствам. Зачем он туда вынесен? Так проще с ними общаться и выяснять кому когда доступ к ним разрешен и запрещён, проще с ними общаться, и так далее.
В современной ос помимо ядра есть понятие модуля. откуда возникло понятие? 12-15 лет назад были ос в котоорых ядра состояли из кода ядра и драйверов всех поддерживаемых устройств. Например, целых 100 устройств поддерживали. Сюда же относятся те куски кода ядра, которые относятся к функциональности, которую оно может иметь, а может не уметь. Все драйвера от всех устройств засунуть в ядро невозможно(начнем с того, что некоторые из них могут конфликтовать).
Итак, помимо ядра в режиме супервизора у нас работают модули. Модули могут быть скомпонованы с ядром уже в момент загрузки. Её можно подгрузить ио тгрузить. Они работают в режиме супервизора. Тем амым и решается проблематотальной перегрузки ненужной функциональностью ядра. втащим туда необходимый минимум, а всё остальное в виде модуля и подключать по мере необходимости.
Классю загрузка -- первичный загружает вторичный, вторичный загружает ядро, разбудили герцена, герцен разбудил декабристов..
Опасно подгружать модуль. А вдруг он вообще не от того ядра? В лучше случае подгрузится и упадет. А в худшем -- продолжит работтаь.Как-то. Поэтому очень строгие правила относительно оформления модулей.
Почему бы нам не начать прямо сейчас запускать какие-нибудь утилиты.
ОС
- унификация
- разделение доступа к ресурсам
- учёт
Для решения этих задач почти наверняка придёт организовывать атомарные вызовы в функцию. Например "напечатать файл". Поэтому, ядро с системными вызовами окружают демоны. Демон -- программа, которая втечение сущ ос всегда висит в памяти и ничего не длеает, пока её не попросят. КЕё могут попроситьсигналом, сокетом, ещё как-нибудь. Демоны на самом деле взялись из позднего Платона. У него были добрые духи, которые умели нашептывать правильные решения -- daemon. У американских программистов они превратились в demon. их ещё принято переводить как системные службы. Это такие части ос, которые решают более менее близкие к прикладным всегдашние задачи, например, подсистема печати, сетевые службы, ну, их много. Запуск задач по расписанию, журнализация. Они решают общесистемные задачи с ориентацией на использование в работе пользователя.
Непосредственно попросить у демона пользователь ничего не может, потому что мы не описали инстументы пользователя. Есть два способа обратиться к демону. можем написать программу, которая юудет лезть к соотв средству межпроцессного взаимодействия и дергать демона. Но такие программы уже есть и они называются утилиты. Их очень много. Утилиты предназначены не только для обращения к демонам.Это кирпичики, предназначенные для решения пользовательскх задач. Это те самые программы, которые мы запускаем из командной строки.
Утилиты это всё ещё часть ос. Они участвуют в унификации. Когда хотим напечатать файл, запускаем утилиту lpr. Он за нас унифицирует все действия.
нам до сих пор не хватает языка описания задания. Чтобы воспользоваться утилитами, решающими задачу необходима какая-то оболочка, которая бы позволяла организовать взаимодействие между всеми утилитами и демонами тоже таким образом, что, елси задача решается алгоритмческим комбинированием утилит, то она решается в этой оболочке.
Такой оболочкой является шелл. Он является хорошим инструментом для интеграции утилит.
Что делает пользователь? Он боится. Ну и ещё взаимодействует с этими утилитами. Причем, очевидно, не силой мысли. Инструмент, через который он взаимодействует -- командная строка. Шелл как оболочка(задача без интерактивности) и шелл в командной строке как интерактивная штука.