Концепция архитектуры
Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы: ядро и вспомогательные модули. Ядро выполняет все основные функции ОС и работает в особом – привилегированном – режиме.
Приложения выполняются независимо, каждое – в своем собственном адресном пространстве.
Преимущество такой архитектуры заключается в легкой расширяемости ОС: для добавления новой высокоуровневой функции достаточно разработать новое приложение, не касаясь ядра. В противовес этому, внесение изменений в функции ядра может оказаться достаточно сложным – вплоть до полной его перекомпиляции.
Архитектура ОС, основанная на привилегированном ядре и приложениях пользователя, считается классической. Она используется, в частности, в большинстве вариантов ОС Unix и с определенными модификациями – в ОС Windows NT.
Ядро и вспомогательные модули ОС
Ядро включает модули, выполняющие основные функции ОС:
- управление процессами;
- управление памятью;
- управление вводом-выводом и файловая система;
- интерфейс прикладного программирования API (Application Program Interface) для поддержки обращений к ядру из приложений.
Для обеспечения высокой скорости работы ОС модули ядра (все или большая часть), являются резидентными, т.е. постоянно находятся в оперативной памяти.
Вспомогательные модули по выполняемым функциям обычно подразделяются на следующие группы:
- утилиты – программы, решающие отдельные задачи управления и сопровождения компьютерной системы (сжатие дисков, их проверка, дефрагментация; архивирование, сбор статистики и т.д.);
- системные обрабатывающие программы (компиляторы, редакторы связей, загрузчики, отладчики, текстовые или графические редакторы);
- библиотеки процедур различного назначения для разработки приложений (математические функции, функции ввода-вывода и т.д.);
- программы, предоставляющие дополнительные услуги (калькулятор, некоторые игры).
По способу оформления эти модули представляют собой либо приложения, т.е. самостоятельные программы (утилиты, системные программы и программы дополнительных услуг), либо процедуры библиотек, вызываемые из приложений.
Вспомогательные модули ОС загружаются в оперативную память только на время выполнения (транзитные модули).
Решение о том, является ли какая-либо программа частью ОС или нет, принимает производитель ОС. Так, самостоятельное приложение, имеющее спрос, может быть включено в состав ОС (например, Веб-браузер Internet Explorer), или, наоборот, модуль ОС может превратиться в отдельное приложение.
Все модули (как вспомогательные, так и пользовательские приложения) обращаются к функциям ядра посредством системных вызовов (рис. 5.1).
Привилегированный режим ядра и пользовательский режим
Операционная система для осуществления своих управляющих функций должна иметь по отношению к приложениям определенные привилегии. Поэтому аппаратура компьютера поддерживает как минимум два режима: пользовательский режим (user mode) – для работы приложений; привилегированный режим, он же – режим ядра (kernel mode), или режим супервизора (supervisor mode) – для работы ОС или ее частей.
В привилегированном режиме чаще всего работает именно ядро как основная часть ОС. Понятия «ядро» и «привилегированный режим» тесно связаны, поэтому ядро также можно характеризовать как часть ОС, работающую в привилегированном режиме.
Привилегии обеспечиваются за счет запрета выполнения в пользовательском режиме некоторых критичных команд, связанных со следующими операциями:
- переключением процессора с задачи на задачу;
- управлением устройствами ввода-вывода;
- доступом к механизмам распределения и защиты памяти.
В пользовательском режиме безусловно запрещено выполнение инструкции перехода в привилегированный режим. Другие инструкции запрещается выполнять при определенных условиях, полностью контролируемых ОС. Например, ввод-вывод данных или доступ к памяти разрешены приложению, если соответствующие ресурсы выделены только этому приложению, и запрещены, если данные (соответственно память) являются общими для ОС и других приложений.
Если аппаратура (процессор) поддерживает хотя бы два уровня привилегий, то ОС может на этой основе создать программным способом сколь угодно развитую систему защиты и соответствующих прав доступа. Прямого соответствия между числом аппаратно реализуемых и программно реализуемых уровней привилегий нет. Так, на базе четырех уровней процессоров архитектуры х86 OS/2 строит трехуровневую, а Windows NT и Unix – двухуровневую систему привилегий.
Переключение процессора из пользовательского режима в привилегированный при системном вызове ядра, а затем обратное переключение повышает устойчивость ОС, но замедляет выполнение системных вызовов.
Многослойная структура ОС
Многослойный подход – универсальный и эффективный способ декомпозиции сложных систем, базирующийся на следующих положениях.
Система представляется как иерархия слоев. Функции нижележащего слоя являются примитивами для построения более сложных функций вышележащего слоя.
Взаимодействие слоев осуществляется через посредство функций межслойного интерфейса.
Отдельный модуль может либо выполнить свою работу самостоятельно, либо обратиться к другому модулю своего слоя, либо обратиться к нижележащему слою через межслойный интерфейс.
При таком подходе разработка системы осуществляется сверху вниз, от целей системы к их реализации. Сначала определяются функции слоев и межслойные интерфейсы, задающие общую структуру системы, а затем разрабатываются модули внутри слоев. Этот подход годится и для анализа сложных систем.
Вычислительную систему, работающую под управлением ОС на базе ядра, можно рассматривать как систему из трех иерархически упорядоченных слоев (рис. 5.2).
При такой организации ОС приложения могут взаимодействовать с аппаратурой только через слой ядра.
Многослойная структура ядра
Многослойный подход применим и к структуре ядра как сложного многофункционального комплекса. Обычно выделяют слои, приведенные на рис. 5.3, однако это разбиение достаточно условно.
Средства аппаратной поддержки ОС – аппаратные средства, прямо участвующие в организации вычислительных процессов: средства поддержки привилегированного режима, система прерываний, переключение контекстов процессов, трансляция адресов, защита памяти и т.п.
Машино-зависимые модули – программные модули, в которых отображается специфика аппаратной платформы компьютера. В идеале этот слой полностью экранирует вышележащие слои от особенностей аппаратуры, т.е. позволяет делать модули вышележащих слоев машинно-независимыми (пригодными для всех типов платформ, поддерживаемых данной ОС). Примером может служить слой HAL (Hardware Abstraction Layer) в Windows NT/2000. На уровне HAL работа с устройством определенного типа (накопитель, видеоплата, мышь и т.п.) всегда описывается при помощи одного и того же заранее определенного набора функций. В случае, если устройство имеет иной набор функций (например, устаревший 3d-ускоритель может не поддерживать многих современных функций), драйвер обязан эмулировать стандартные функции с тем, чтобы ОС могла не заботиться о том, какое конкретно устройство установлено.
Базовые механизмы ядра. Модули этого слоя не принимают решений о распределении ресурсов, а только отрабатывают принятые на более высоком уровне решения. Выполняются наиболее примитивные операции ядра: программное переключение контекстов процессов, перемещение страниц между памятью и диском, диспетчеризация прерываний и т.п.
Менеджеры ресурсов. Модули этого уровня реализуют управление основными ресурсами системы. Группировка модулей в менеджеры обычно осуществляется по функциям основных подсистем ОС: выделяются менеджеры процессов, ввода-вывода и файловой системы (могут быть объединены), оперативной памяти.
Интерфейс системных вызовов. Взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс ОС (API).
8. Аппаратная зависимость и переносимость операционных систем.
Совместимость операционных систем и множественные прикладные среды.
Аппаратная зависимость и переносимость операционных систем
Многие операционные системы успешно работают на различных аппаратных платформах благодаря тому, что в большинстве компьютеров средства аппаратной поддержки операционной системы приобрели типовые черты. В результате в операционных системах можно выделить достаточно компактный слой машинно-зависимых компонентов ядра, а остальные слои сделать общими для разных аппаратных платформ. Четкой границы между программной и аппаратной реализацией функций операционной системы не существует. Решение о том, какие функции операционной системы будут выполняться программно, а какие – аппаратно, принимается разработчиками аппаратного и программного обеспечения. Практически все современные аппаратные платформы имеют типичный набор средств аппаратной поддержки операционной системы.
1. Средства поддержки привилегированного режима обычно основаны на системном регистре процессора, называемом «словом состояния» машины или процессора. Регистр содержит признаки, определяющие режимы работы процессора, в том числе признак текущего режима привилегий. Смена режима привилегий выполняется за счет изменения слова-состояния машины в результате прерывания или выполнения привилегированной команды.
2. Средства трансляции адресов выполняют операции преобразования виртуальных адресов, которые содержатся в кодах процесса, в адреса физической памяти. Таблицы, предназначенные для трансляции адресов, имеют большой объем, поэтому для их хранения используются области оперативной памяти, а аппаратура процессора содержит только указатели на эти области. Средства трансляции адресов используют данные указатели для доступа к элементам таблиц и аппаратного выполнения алгоритма преобразования адреса, что значительно ускоряет процедуру трансляции по сравнению с ее чисто программной реализацией.
3. Средства переключения процессов предназначены для быстрого сохранения контекста приостанавливаемого процесса и восстановления контекста процесса, который становится активным. Содержимое контекста включает содержимое всех регистров общего назначения процессора, регистра флагов операций (флагов нуля, переноса, переполнения и т. п.), системных регистров и указателей, которые связаны с отдельным процессом, например, указателя на таблицу трансляции адресов процесса. Для хранения контекстов приостановленных процессов обычно используются области оперативной памяти, которые поддерживаются указателями процессора. Переключение контекста выполняется по определенным командам процессора, например, по команде перехода на новую задачу, которая вызывает автоматическую загрузку данных из сохраненного контекста в регистры процессора, после чего процесс продолжается с прерванного ранее места.
4. Система прерываний позволяет компьютеру реагировать на внешние события, синхронизировать выполнение процессов и работу устройств ввода-вывода, быстро переходить с одной программы на другую. Механизм прерываний нужен для того, чтобы оповестить процессор о возникновении в вычислительной системе некоторого непредсказуемого события или события, которое не синхронизировано с циклом работы процессора. Например, некорректное завершение арифметической операции, истечение интервала времени. При возникновении условий прерывания его источник (контроллер внешнего устройства, таймер, арифметический блок процессора и т. п.) выставляет определенный электрический сигнал. Этот сигнал прерывает выполнение процессором последовательности команд, задаваемой исполняемым кодом, и вызывает автоматический переход на заранее определенную процедуру обработки прерываний. В большинстве моделей процессоров отрабатываемый аппаратурой переход на процедуру обработки прерываний сопровождается заменой слова состояния машины (или даже всего контекста процесса), что позволяет одновременно с переходом по нужному адресу выполнить переход в привилегированный режим. После завершения обработки прерывания происходит возврат к исполнению прерванного кода.
5. Системный таймер, часто реализуемый в виде быстродействующего регистра-счетчика, необходим операционной системе для выдержки интервалов времени. Для этого в регистр таймера программно загружается значение требуемого интервала в условных единицах, из которого затем автоматически с определенной частотой начинает вычитаться по единице. Частота «тиков» таймера связана с частотой тактового генератора процессора. При достижении нулевого значения счетчика таймер инициирует прерывание, которое обрабатывается процедурой операционной системы. Операционная система использует прерывания от системного таймера для отслеживания временных затрат процессора на выполнение процессов. Например, в системе разделения времени при обработке очередного прерывания от таймера планировщик процессов может принудительно передать управление другому процессу, если данный процесс исчерпал выделенный ему квант времени.
6. Средства защиты областей памяти обеспечивают на аппаратном уровне проверку возможности программного кода осуществлять с данными определенной области памяти операции: чтение, запись или выполнение (при передачах управления). Если аппаратура компьютера поддерживает механизм трансляции адресов, то средства защиты областей памяти встраиваются в этот механизм. Функции аппаратуры по защите памяти обычно состоят в сравнении уровней привилегий текущего кода процессора и сегмента памяти, к которому производится обращение.
Для переносимости операционной системы с одной платформы на другую (например, на компьютеры, отличающиеся типом процессора или способом организации аппаратуры) ядро проектируется таким образом, чтобы только часть модулей была машинно-зависимой. Опыт разработки операционных систем показывает, что в хорошо структурированном ядре машинно-зависимые модули локализованы и образуют программный слой, примыкающий к слою аппаратуры, что существенно упрощает перенос операционной системы на другую аппаратную платформу.
Для уменьшения количества машинно-зависимых модулей производители операционных систем ограничивают универсальность машинно-независимых модулей. Это означает, что их независимость носит условный характер и распространяется только на несколько типов процессоров и созданных на их основе аппаратных платформ. Например, разработчики операционной системы Windows NT ограничили количество типов процессоров для своей системы четырьмя и поставляют различные варианты кодов ядра для однопроцессорных и многопроцессорных компьютеров.
Особое место среди модулей ядра занимают низкоуровневые драйверы внешних устройств. С одной стороны, они, как и высокоуровневые драйверы, входят в состав менеджера ввода-вывода, т. е. принадлежат слою ядра. С другой стороны – отражают все особенности управляемых внешних устройств, поэтому их можно отнести и к слою машинно-зависимых модулей. Такая двойственность низкоуровневых драйверов еще раз подтверждает схематичность модели ядра со строгой иерархией слоев.
Для компьютеров на основе процессоров Intel x86/Pentium разработка экранирующего машинно-зависимого слоя операционной системы несколько упрощается за счет встроенной в постоянную память компьютера базовой системы ввода-вывода – BIOS. BIOS содержит драйверы для всех устройств, входящих в базовую конфигурацию компьютера (жестких и гибких дисков, клавиатуры, дисплея и т. д.), которые выполняют примитивные операции с управляемыми устройствами. За счет этих операций экранируются различия аппаратных платформ компьютера и серверов на процессорах Intel разных производителей. Разработчики операционных систем могут пользоваться слоем драйверов BIOS как частью машинно-зависимого слоя операционной системы, а могут заменить все или часть драйверов BIOS компонентами операционной системы.
Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую операционную систему называют переносимой (portable), или мобильной. Для обеспечения свойства мобильности операционной системы, разработчики должны следовать следующим правилам:
1) большая часть кода должна быть написана на стандартизированном языке высокого уровня, трансляторы которого имеются на всех машинах. Большинство переносимых операционных систем написано на языке С. Операционная система, написанная на ассемблере, является переносимой только в тех случаях, когда перенос операционной системы планируется на компьютер, обладающий той же системой команд. В остальных случаях ассемблер используется только для тех непереносимых частей системы, которые должны непосредственно взаимодействовать с аппаратурой (например, обработчик прерываний), или для частей, которые требуют максимальной скорости (например, целочисленная арифметика повышенной точности);
2) объем машинно-зависимых частей кода, которые непосредственно взаимодействуют с аппаратными средствами, должен быть по возможности минимизирован. Для уменьшения аппаратной зависимости разработчики операционных систем должны исключить возможность использования по умолчанию стандартных конфигураций аппаратуры или их характеристик. Для осуществления действий по управлению аппаратурой должен быть написан набор аппаратно-зависимых функций. Каждый раз, когда какому-либо модулю операционной системы требуется выполнить некоторое действие, связанное с аппаратурой, он манипулирует абстрактными данными, используя соответствующую функцию из имеющегося набора. Когда операционная система переносится, то изменяются только эти данные и функции, которые ими манипулируют. Например, в операционной системе Windows NT диспетчер прерываний преобразует аппаратные уровни прерываний конкретного типа процессора в стандартный набор уровней прерываний IRQL, с которыми работают остальные модули операционной системы. Поэтому при переносе Windows NT на новую платформу нужно переписать коды диспетчера прерываний, которые занимаются отображением уровней прерывания на абстрактные уровни IRQL, а те модули операционной системы, которые пользуются этими абстрактными уровнями, изменений не потребуют.
3) аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях. Изоляции подлежат все части операционной системы, которые отражают специфику как процессора, так и аппаратной платформы в целом. Низкоуровневые компоненты операционной системы, имеющие доступ к процессорно-зависимым структурам данных и регистрам, должны быть оформлены в виде компактных модулей, которые могут быть заменены аналогичными модулями для других процессоров. Для снятия платформенной зависимости, возникающей из-за различий между компьютерами разных производителей, построенными на одном и том же процессоре (например, MIPS R4000), должен быть введен хорошо локализованный программный слой машинно-зависимых функций.
В идеале слой машинно-зависимых компонентов ядра полностью экранирует остальную часть операционной системы от конкретных деталей аппаратной платформы (кэши, контроллеры прерываний ввода-вывода и т. п.). В результате происходит подмена реальной аппаратуры унифицированной виртуальной машиной, одинаковой для всех вариантов аппаратной платформы. Все слои операционной системы, лежащие выше слоя машинно-зависимых компонентов, могут быть написаны для управления этой виртуальной аппаратурой. Таким образом, у разработчиков появляется возможность создавать один вариант машинно-независимой части операционной системы (включая компоненты ядра, утилиты, системные обрабатывающие программы) для всего набора поддерживаемых платформ.
Совместимость операционных систем и множественные прикладные среды
В то время как многие архитектурные особенности ОС непосредственно касаются только системных программистов, концепция множественных прикладных (операционных) средств непосредственно связана с нуждами конечных пользователей – возможностью операционной системы выполнять приложения, написанные для других операционных систем. Такое свойство операционной системы называется совместимостью.
Совместимость приложений может быть на двоичном уровне и на уровне исходных текстов [13]. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, если можно взять исполняемую программу и запустить ее на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличие соответствующего компилятора в составе программного обеспечения компьютера, на котором предполагается выполнить данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция исходных текстов приложения в новый исполняемый модуль.
Совместимость на уровне исходных текстов важна в основном для разработчиков приложений, в распоряжении которых эти исходные тексты имеются. Но для конечных пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут использовать один и тот же продукт в различных операционных системах и на различных машинах.
Вид возможной совместимости зависит от многих факторов. Самый главный из них – архитектура процессора. Если процессор применяет тот же набор команд (возможно, с добавлениями, как в случае IBM PC: стандартный набор + мультимедиа + графика + потоковые) и тот же диапазон адресов, то двоичная совместимость может быть достигнута достаточно просто. Для этого необходимо соблюдение следующих условий:
API, который использует приложение, должен поддерживаться данной ОС;
внутренняя структура исполняемого фала приложения должна соответствовать структуре исполняемых фалов данной ОС.
Если процессоры имеют разную архитектуру, то, кроме перечисленных условий, необходимо организовать эмуляцию двоичного кода. Например, широко используется эмуляция команд процессора Intel на процессоре Motorola 680×0 компьютера Macintosh. Программный эмулятор в этом случае последовательно выбирает двоичную инструкцию процессора Intel и выполняет эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как у процессора Motorola нет в точности таких же регистров, флагов, внутреннего АЛУ и др., как в процессорах Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти.
Это простая, но очень медленная работа, поскольку одна команда Intel выполняется значительно быстрее, чем эмулирующая ее последовательность команд процессора Motorola. Выходом в таких случаях является применение так называемых прикладных программных сред или операционных сред. Одной из составляющих такой среды является набор функций интерфейса прикладного программирования API, который ОС предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращение к библиотечным функциям.
Эффективность этого подхода связана с тем, что большинство сегодняшних программ работает под управлением GUI (графических интерфейсов пользователя) типа Windows, MAC или UNIX Motif, при этом приложения тратят 60-80% времени на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программ. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие библиотеки GUI, но написанные на родном коде. Таким образом, достигается существенное ускорение выполнения программ с API другой операционной системы. Иначе такой подход называют трансляцией – для того, чтобы отличить его от более медленного процесса эмулирования по одной команде за раз.
Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel производительность может быть очень низкой. Но когда производится вызов функции GUI, открытие окна и др., модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680×0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а, возможно, и превзойти) скорость работы на своём родном процессоре.
Чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечивать совместимость API. Концепции, положенные в основу разных ОС, могут входить в противоречия друг с другом. Например, в одной ОС приложению может быть разрешено управлять устройствами ввода-вывода, в другой – эти действия являются прерогативой ОС.
Каждая ОС имеет свои собственные механизмы защиты ресурсов, свои алгоритмы обработки ошибок и исключительных ситуаций, особую структуру процессора и схему управления памятью, свою семантику доступа к файлам и графический пользовательский интерфейс. Для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера.
Существуют различные варианты построения множественных прикладных сред, отличающиеся как особенностями архитектурных решений, так и функциональными возможностями, обеспечивающими разную степень переносимости приложений. Один из наиболее очевидных вариантов реализации множественных преклонных сред основывается на стандартной многоуровневой структуре ОС.
На рис. 1.9 ОС OS1 поддерживает кроме своих родных приложений приложения операционных систем OS2 и OS3. Для этого в её составе имеются специальные приложения, прикладные программные среды, которые транслируют интерфейсы чужих операционных систем API OS2 и API OS3 в интерфейс своей родной ОС – API OS1. Так, например, в случае если бы в качестве OS2 выступала ОС UNIX, а в качестве OS1 – OS/2, для выполнения системного вызова создания процесса fork () в UNIX-приложении программная среда должна обращаться к ядру операционной системы OS/2 с системным вызовом DOS ExecPgm ().
Рис. 1.9. Организация множественных прикладных сред
К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. Например, чтобы функция создания процесса в OS/2 Dos ExecPgm () полностью соответствовала функции создания процесса fork () в UNIX-подобных системах, её нужно было бы изменить и прописать новую функциональность: поддержку возможности копирования адресного пространства родительского процесса в пространство процесса-потомка [17].
Еще один способ построения множественных прикладных сред основан на микроядерном подходе. При этом очень важно отметить базовое, общее для всех прикладных сред отличие механизмов операционной системы от специфических для каждой из прикладных сред высокоуровневых функций, решающих стратегические задачи. В соответствии с микроядерной архитектурой все функции ОС реализуются микроядром и серверами пользовательского режима. Важно, что прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов.
Приложения, используя API , обращаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает приложению результат. В ходе выполнения запроса прикладной среде приходится, в свою очередь, обращаться к базовым механизмам ОС, реализуемым микроядром и другими серверами ОС.
Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микро ядерной архитектуры, в частности:
- очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микро ядерных ОС;
- при отказе одной из прикладных сред остальные сохраняют работоспособность, что способствует надежности и стабильности системы в целом;
- низкая производительность микроядерных ОС сказывается на скорости работы прикладных средств, а значит, и на скорости работы приложений.
В итоге следует отметить, что создание в рамках одной ОС нескольких прикладных средств для выполнения приложений различных ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее между различными операционными системами. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной ОС с приложениями, написанными для других ОС.
9. Подсистема управления процессами, основные задачи.
Понятие многозадачности. Многозадачность в системах пакетной обработки,
