|
|
Close Help | ||||||||||||||
Лекция 10
Говоря о двойной буферизации, следует сказать и о многоуровневой буферизации — когда ВЗУ само обладает некоторой оперативной памятью с помощью которой обеспечивает еще один уровень буферов.
При многоуровневой буферизации реальный обмен и мнимый происходят с некоторой задержкой, это может плохо сказаться на функционировании процессов.
Следует отметить, что Unix максимально экономит число обращений к внешним устройствам:
Продолжим рассматривать файловую систему Unix
Атрибуты файлов
Мы говорили об организации пользователей системы, она имеет иерархическую трехуровневую структуру
Любой пользователь, присутствующий в системе, принадлежит некоторой группе. В соответствии с иерархией пользователей определена иерархия защиты файлов. Определено понятие владельца файла. Изначально владельцем файла является пользователь (процесс пользователя), который создал этот файл. Атрибут “владелец файла” может быть изменен командой “chown”. Каждый файл имеет атрибуты защиты, причем они также иерархичны:
Изменение прав доступа можно осуществить с помощью команды “chmod”.
Кроме атрибутов доступа каждый файл может иметь некоторые признаки, так называемые:
Предположим, имеется исполняемый файл “file”, он каким-то образом работает с файлом “file2”, в котором находится конфиденциальная (недоступная всем) информация, предположим, “file” корректирует “file2”, где хранится, например, информация обо всех пользователях. И, в частности, он может менять пароль пользователя в системе. Если мы запустим “file” от имени пользователя “mash”, то доступ к “file2” будет заблокирован, так как “mash” не имеет права доступа к этому файлу. В противном случае, “file2” не имел бы никакой защиты. В этом случае как раз и работает s-bit, его суть в том, что владелец “file” — пользователь “root”, предположим, что его захотел запустить пользователь “mash”, если у него файла нет s-bit’а, то владельцем файла является “root”, а владельцем процесса — “mash” и в этом случае файла, которые недоступны пользователю “mash” будут недоступны процессу. Например, при таком раскладе изменить пользователю собственный пароль будет весьма затруднительно. А s-bit позволяет продлить права владельца файла на права владельца процесса. И на время работы с этим файлом процесс будет иметь все нужные права доступа. Но надо отметить, что, рассматривая наш пример, доступ к “file2” может быть осуществлен только через “file”. Напрямую “mash” по-прежнему ничего не сможет сделать.
Для установки s- и t-bit’а также существует определенная команда системы.
Итак, мы разобрались с доступом к конкретным файлам, а как же быть с каталогами? Как интерпретируются права доступа к каталогам?
Предположим, мы исполняем команду “ls */mash*”. Это означает, что мы ищем в текущем каталоге подкаталоги, внутри которых есть файлы, начинающиеся с “mash”. При этом выполняется поиск файлов. Это и есть тот поиск, который ассоциируется с выполнением файла-каталога.
Структура файловой системы с точки зрения пользователя
Сразу следует отметить, что мы будем рассматривать некоторую более общую файловую систему, потому что на сегодняшний день она может изменяться от версии к версии.
Файлы “\”:
“unix” — этот файл запускается программным загрузчиком и в итоге формирует ядро системы;
“passwd” — все пользователи зарегистрированы в этом файле, то есть каждому пользователю соответствует строка в этом файле, которая содержит набор некоторых данных, разделенных между собой некоторым разделителем. В частности, эта строка содержит номер группы пользователя, она может содержать закодированный пароль на вход пользователя. Однако, современные unix’ы хранят пароли обычно в специальной защищенной базе данных, так как находятся умельцы, которые с помощью переборных задач (алгоритм кодирования паролей известен) подбирают пароли. Далее, строка содержит ФИО пользователя, его статус, домашний каталог (каталог, который устанавливается при входе пользователя), тип интерпретатора команд, с которым будет работать пользователь.
“rc” — в этом файле в текстовом виде находится набор команд, которые будут выполнены при загрузке ОС.
И так далее...
Следует заметить, что Unix подавляющее большинство своей системной информации содержит в обыкновенных текстовых файлах. Это позволяет легко изменять многие параметры ОС без использования специальных средств.
В этом же каталоге находятся еще полезные команды, которые позволяют: изменять пароли, ремонтировать файловую систему (локальную), запускать процесс тестирования и коррекции файловой системы “fsch” и т.д.
Каталоги:
“etc” — содержит стандартные файлы данных системы и команды, обеспечивающие управление некоторым уровнем функционирования системы;
“bin” — здесь находится подавляющее число команд, доступных пользователю, таких как: “rm”,”ls”,...
“mnt” — каталог, к которому можно “примонтировать” локальные файловые системы. Мы говорили об организации файловой системы на одном внешнем устройстве, но реально для систем этого мало. Обычно требуется иметь основную файловую систему и любое число локальных, расположенных на других устройствах. Они монтируются с помощью команды “mount”. Это означает, что корень локальной файловой системы после монтирования ассоциируется с этим каталогом, и доступ к любому файлу из локальной файловой системы есть лишь указание пути от корня файловой системы до соответствующего узла через каталог “mnt”.
“dev” — в этом каталоге размещаются файлы, ассоциированные с конкретными драйверами внешних устройств. К примеру, “tty01”, “tty02”, “consolp”, ... Как было сказано ранее — эти файлы не имеют содержимого, но имеют специальные поля в ИД, определяющие ссылки на таблицу драйверов и некоторую другую информацию.
“usr”: “lib” — содержит библиотеки группового пользования, как то — компилятор Си, например.
“bin” — каталог для размещения команд. Есть некоторые негласные правила, которые определяют — стоит положить команду в “\bin” или в “\usr\bin”. Обычно в “\bin” кладут стандартные команды.
“include” — здесь лежат файлы заголовков, которые, например, используются компилятором Си, когда мы употребляем команду “include <stdio.h>” файл “stdio.h” ищется как раз в “\usr\include”. Также интерес представляет подкаталог “\usr\include\sys” — здесь лежат файлы-заголовки, которые несут в себе информацию о системных функциях.
На этом мы заканчиваем рассмотрение файловой системы Unix. Подведем итог —
Файловая система Unix:
Лекция 11
Управление процессами. Ядро системы.
Мы говорили о том, что вторым по значимости понятием в ОС является понятие процесса. Процесс — вещь, которая определяется по-разному. Это может быть — “упорядоченный набор команд и принадлежащих ему ресурсов”. С точки зрения ОС Unix процесс — это объект, зарегистрированный в специальной таблице процессов. Структура этой таблицы следующая: она позиционна (как практически и все таблице в Unix), то есть номер записи в таблице — есть идентификатор процесса “PID”. Формируются процесс с 0, до N-1, где N — предельное число процессов, которые система может одновременно обрабатывать. Это параметр настройки ОС.
Рассмотрим информативную нагрузку таблицы.
В строке (записи) таблицы находится ссылка на контекст процесса, там же находится ссылка на тело процесса.
Телом процесса мы будем называть набор команд и данных, которыми оперирует процесс.
Контекст процесса — атрибут, который присутствует практически во всех ОС, в разных ОС он может называться по-разному. Контексты всех процессов размещаются в адресном пространстве ОС и содержат оперативную информацию о состоянии процесса и текущую информацию, связанную с процессом и его запуском.
Контекст содержит:
номера пользователя и группы;
указатель на ИД текущего каталога;
специфические условия работы процесса:
- обработка сигналов;
Рассмотрим это подробнее. В ОС Unix каждый процесс может послать другому процессу некоторое воздействие, которое называют “сигнал”, соответственно, если процесс-отправитель имеет право передать сигнал процессу-получателю, то при выполнении передачи в последнем возникает событие, связанное с сигналом.
Это событие очень похоже на прерывание, возникающее в аппаратуре вычислительной системы. В ОС имеется набор сигналов, которые могут передавать процессы друг другу. Перечень сигналов описан в файле “signal.h”, отправитель может подать некоторым образом команду ОС, что он передает сигнал с заданным номером процессу-получателю, процесс-получатель может прореагировать на сигнал тремя способами: прекращение выполнения и причиной завершения является пришедший сигнал; игнорирование сигнала (здесь следует отметить, что игнорировать можно далеко не все сигналы); вызывается предопределенная процессом функция, которая может выполнить какие-то действия и возврат из этой функции есть возврат в точку прихода сигнала.
- информация об открытых в процессе файлах;
- информация о текущем состоянии процесса на случай его приостановки;
Тогда, когда процесс остановлен, ОС “упрятывает” в соответствующий контекст информацию, нужную для его продолжения: режимы программы в момент приостановки, состояние регистров, адрес точки прерывания.
Тело процесса — как уже было сказано, его можно представить в виде объединения сегмента текста (кода) и сегмента данных. Развитые ОС позволяют размещать сегменты текста и данных в различных, не зависящих друг от друга местах оперативной памяти. Это хорошо, так как вместоодного большого куска памяти нам требуется два маленьких. Но еще лучше следующее — такая организация позволяет использовать повторно входимый код. Суть его в том, что допускается существование в системе еще одного процесса с собственным контекстом, сегментом данных, но у которого общий с другими процессами сегмент текста.
Если K пользователей вызывают один текстовой редактор, то в системе находится одна копия этого редактора и K копий сегмента данных и контекстов (копии, надо заметить, не идентичные). Это вещь полезная, так как отсюда сразу же можно увеличить “разум” планировщика откачки (он может, например, откачивать сегмент данных, а не сегмент текста).
Мы перечислили не все содержимое контекста, и в дальнейшем эта информация будет дополняться и уточняться.
Мы говорили, каким образом в Unix можно создать копию текущего процесса — это функция fork(), она работает следующим образом:
fork(): >0 PID сыновнего процесса (мы находимся в процессе-отце)
=0 (мы находимся в процессе-сыне)
=-1 ошибка — невозможность создать новый процесс (остаемся в процессе-отце), эта ошибка может возникнуть при недостатке места в таблице процессов, при нехватке места в системных областях данных и т.п.
Система поддерживает родственные взаимоотношения между процессами, это означает, что существуют некоторые функции, характерные для работы с процессами, которые доступны только процессам, являющимся родственниками.
При порождении сыновнего процесса с использованием fork() порожденный процесс наследует:
Не наследуется при создании нового процесса идентификатор процесса (почему — очевидно).
Возвращаясь к функции fork(), следует заметить, что она сама по себе бессмысленна, ибо применение такому созданию точной копии процесса найти весьма сложно. Поэтому функция fork() используется совместно с группой функций exec(...). Эта группа объединяет в себе функции, которые частью своего имени имеют слово “exec” и имеют по сути дела похожее назначение, отличающееся лишь деталями (набором или интерпретацией параметров).
Суть exec в следующем: при обращении к ней происходит замена тела текущего процесса, оно заменяется в соответствии с именем исполняемого файла, указанного одним из параметров функции. Функция возвращает: -1, если действие не выполнено и код отличный от -1, если операция прошла успешно. Здесь следует отметить следующий факт — в Unix при работе с системными вызовами иногда возникают диагностические сообщения в виде кода ответа, которые невозможно разделить на конкретные причины, вызвавшие возврат этого кода. Примером этого являются коды “-1” для fork() и exec(...). Для того, чтобы обойти это неудобство, следует включить в программу файл “errno.h”, и после этого при возникновении отказов в выполнении системных вызовов в переменной “errno” будет код конкретной причины отказа выполнения заказа. Всевозможные коды отказа описаны в самом “errno.h”.
Давайте приведем небольшой пример:
Мы напишем программу, которая будет запускать файлы, имена которых перечислены при вызове.
main(argc, argv)
int argc;
char **argv;
{ int i, pid;
for (i=1; i<argc; i++) {
if (pid=fork()) continue; /* отец*/
execlp(argv[i], argv[i], (char *) 0);
}
}
Здесь, в случае, если pid=0, то мы замещаем тело процесса-сына процессом, имя файла которого нам передается в качестве параметра. Если же pid>0, то есть мы находимся в процессе-отце, то продолжаем создавать сыновьи процессы пока есть аргументы.
В качестве иллюстрации работы fork() можно привести следующую картинку:
Здесь процесс с PID=105 создается процессом с PID=101.
Также следует отметить, что если убивается процесс-отец, то новым отцом становится 1ый процесс ОС.
Связка fork-exec по своей мощности сильнее, чем если бы была единая функция, которая сразу бы создавала новый процесс и замещала бы его содержимое. А fork-exec позволяют вставить между ними вставить еще некоторую программу, которая будет содержать какие-то полезные действия.
Мы начали рассматривать организацию процессов. Мы на пальцах показали, как размещается информация в ОС.
В принципе, вся информация, которая отражает оперативное состояние ОС, а также программы ОС, которые управляют этой информацией, которые управляют наиболее важными устройствами составляют ядро ОС.
Ядро ОС — программа, функцией которой является управления базовыми объектами системы (для Unix это два объекта — файл и процесс). Ядро в своем теле размещает необходимые таблицы данных. И вообще ядро считается некоторой неразделяемой частью ОС. Ядро обычно работает в режиме супервизора, все остальные функции ОС могут работать и в других режимах.
Лекция 12
На прошлой лекции мы начали говорить о процессах в операционной системе UNIX. Можно однозначно говорить о том, что процессы и механизмы управления процессами в операционной системе это есть одна из принципиальных особенностей операционной системы UNIX, т.е. тех особенностей, которые отличали систему при создании и отличают ее до сих пор. Более того, несмотря на старания господина Гейтса ситуация такова, что Гейтс повторяет те программные интерфейсы, которые используются для взаимодействия управления процессами, а не фирмы разработчики UNIX-ов повторяют те интерфейсы которые появились в Windows. Очевидно, первенство операционной системы UNIX.
Мы говорили о том, что процесс в UNIX-е это есть нечто, что зарегистрировано в таблице процессов. Соответственно каждая запись в таблице процессов имеет номер. Номера идут от нуля до некоторого предельного значения, которое предопределено при установке системы. Номер в таблице процессов это есть так называемый идентификатор процесса, который в системе обозначается PID. Соответственно, подавляющее большинство действий, которые можно выполнить с процессом, выполняются при помощи указания на идентификатор процесса. Каждый процесс характеризуется контекстом процесса. Это блок данных, характеризующий состояние процесса, в том числе в этом блоке данных указывается информация об открытых файлах, о правилах обработки событий, возникающих в процессе. В этом наборе данных хранится информация, которая образуется при полном упрятывании процесса при переключении системы с процесса на процесс. Т.е., когда происходит по той или иной причине переключение выполнения с одного процесса на другой, для того, чтобы можно было восстановить работу процесса, некий набор данных размещается в контексте процесса. Этот набор данных представляет из себя содержимое регистровой памяти, некоторые режимы, которые установила программа и в которые пришел процессор (например, содержимое регистра результата), точку возврата из прерывания. Плюс контекст содержит много полезной информации, о которой мы будем говорить.
Мы говорили о том. что в некотором смысле определено понятие тела процесса. Тело процесса состоит из двух сегментов — сегмента текста и сегмента данных. Сегмент текста это часть данных процесса, которые включают в себя код исполняемой программы. Сегмент данных это те пространства оперативной памяти, которые могут статически содержать данные. Мы говорили, что имеется возможность в системе иметь разделенные сегменты текста и сегменты данных. В свою очередь,система позволяет с одним сегментом текста связывать достаточно произвольную группу сегментов данных. Это, в частности, бывает полезно, когда в системе одновременно работают несколько одинаковых процессов.
Важная и принципиальная вещь, связанная с организацией управлением процессами — механизм fork/exec. При обращении к функции fork происходит создание нового процесса, который является копией текущего процесса. Незначительные отличия этих процессов есть в идентификаторе процессов. Возможны некоторые отличия в содержимом контекста процесса.
Функция exec позволяет заменять тело процесса, т.е. при обращении к этой функции, в случае успешного выполнения ее, тело процесса меняется на новое содержимое, которое указано в виден аргументов функции exec, точнее в виде имени некоторого файла. Мы говорили о том, что сама по себе функция fork почти бессмысленна. Смысл функции exec можно уловить, т.е. можно выполнять в рамках одного процесса несколько задач. Возникает вопрос: почему формирование этого процесса раздроблено на две функции fork и exec, чем это обосновано? Во многих системах есть одна функция, формирующая процесс с заданным содержимым. Дело в том, что при обращении к функции fork, как уже неоднократно было сказано, создается копия процесса, в том числе процесс сын наследует все те файлы, которые были открыты в процессе отце и многие другие права и привилегии. Бывает ситуация, когда не хотелось бы, чтобы наследник наследовал все особенности отца. И есть возможность между выполнением функций fork и exec выполнить какие-то действия по закрытию файлов, открытию новых файлов, по переопределению чего-то, и т.д. В частности, вы при практических занятиях должны освоить отладчик системы deb. Какова суть его работы?
Пусть есть процесс-отладчик deb, запускается процесс, который отлаживается, и передавая некоторою информацию от отладчика к отлаживаемому процессу происходит процесс отладки. Но отлаживать процесс можно только тот, который разрешил себя отлаживать. Как раз здесь используется раздвоение fork/exec. Сначала я делаю копию своего процесса deb’ , после этого я разрешаю проводить трассировку текущего процесса, а после этого я запускаю функцию exec с отлаживаемой программой. Получается ситуация, что в процессе образуется именно та программа, которую надо отладить, и она, не зная ничего, уже работает в режиме отладки.
Загрузка операционной системы и образование начальных процессов.
Сегодня мы с вами поговорим о загрузке операционной системы и образовании начальных процессов. При включении вычислительной системы, из ПЗУ запускается аппаратный загрузчик. Осуществляется чтение нулевого блока системного устройства. Из этого нулевого блока запускается программный загрузчик ОС UNIX. этот программный загрузчик осуществляет поиск и запуск файла с именем unix, который является ядром операционной системы. В начальный момент происходят действия ядра по инициализации системы. Это означает, что в соответствии с параметрами настройки системы, формируются необходимые таблицы, инициализируются некоторые аппаратные интерфейсы (инициализация диспетчера памяти, часов, и т.д.). После этого ядро системы создает процесс №0. При этом нулевой процесс является вырожденным процессом с точки зрения организации остальных процессов. Нулевой процесс не имеет кода, он содержит только контекст процесса. Считается, что нулевой процесс активен, когда работает ядро, и пассивен во всех остальных случаях.
К моменту образования нулевого процесса в системе уже образованы таблицы, произведена необходимая инициализация, и система близка к готовности работать. Затем ядро копирует нулевой процесс в первый процесс. При этом под первый процесс уже резервируются те ресурсы, которые необходимы для полноценного процесса. Т.е. для него резервируются сегмент контекста процесса, и для него резервируется память для размещения тела процесса. После этого в первый процесс загружается программа init. При этом запускается диспетчер процессов. И ситуация такова: существует единственный процесс реально готовый к выполнению. Процесса init реально завершает запуск системы.
Запуск системы может происходить в двух режимах. Первый режим — это однопользовательский режим. В этом случае процесс init загружает интерпретатор команд shell и ассоциирует его с консольным терминалом, а также запускает стартовый командный файл /etc/rc. Этот файлсодержит произвольные команды, которые может устанавливать администратор системы, которые он считает необходимым выполнить при старте системы. Это могут быть команды, предположим, запуска программы тестирования целостности файловой системы. Это могут бытькоманды проверки расписания и в зависимости от расписания запуска процесса, который будет архивировать файловую систему и т.д. Т.е. в этом командном плане в общем случае могут быть произвольные команды, установленные администратором системы. При этом, если запускается система в однопользовательском режиме, на консольный терминал запускается интерпретатор команд shell и считается, что консольный терминал находится в режиме супервизора (суперпользователя) со всеми правами, которые можно предоставить администратору системы.
Второй режим — многопользовательский режим. Если однопользовательский режим обычно используется в ситуациях, когда в системе произошла аварийная ситуация и необходимы действия администратора системы или системного программиста, то многопользовательский режим — это штатный режим, который работает в нормальной ситуации. При многопользовательском режиме процесс init запускает для каждого активного терминала процесс getty. Список терминалов берется из некоторого текстового файла, а активностьили его пассивность — это прерогатива аппаратных свойств конкретного терминала и драйвера, который обслуживает данный терминал (когда вы включаете терминал, идет сигнал по соответствующему интерфейсу о включении нового устройства, система осуществляет идентификацию этого устройства в соответствии с портом, к которому подключен этот терминал).
Процесс getty при запуске запрашивает сразу же login. Копия процесса getty работает на один сеанс работы с пользователем, т.е. пользователь подтвердил свое имя и пароль, выполняет какие-то действия, и когда он выполняет команду завершения работы, то копия процесса getty завершает свою работу. И после завершения работы процесса getty, связанного с конкретным терминалом, запускается новая копия процесса getty.
Вот такая схема. Это те нетрадиционные формы формирования процессов в UNIX-е. Нетрадиционно формируется нулевой процесс (и он сам по себе нетрадиционен), нетрадиционно формируется первый процесс (который также нетрадиционен). Все остальные процессы работают по схеме fork/exec.
Эффективные и реальные идентификаторы процесса.
С каждым процессом связано три идентификатора процесса. Первый — идентификатор самого процесса, который был получен при формировании. Второй — это т.н. эффективный идентификатор (ЭИ). ЭИ — это идентификатор, связанный с пользователем, запустившем этот процесс. Реальный идентификатор (РИ) — это идентификатор, связанный с запущенным в виде процесса файлом (если я запускаю свой файл, то ЭИ и РИ будут одинаковы, если я запускаю чужой файл, и у этого файла есть s-бит, то в этом случае РИ будет идентификатором владельца файла и это означает, что этому процессу будут делегированы права этого владельца).
Планирование процессов в ОС UNIX.
Планирование основывается на понятии приоритета. Чем выше числовое значение приоритета, тем меньше приоритет. Приоритет процесса — это параметр, который размещен в контексте процесса, и по значению этого параметра осуществляется выбор очередного процесса для продолжения работы или выбор процесса для его приостановки. В вычислении приоритета используются две составляющие — P_NICE и P_CPU. P_NICE — это пользовательская составляющая приоритета. Она наследуется от родителя и может изменяться по воле процесса. Изменяться она может только в сторону увеличения значения (до некоторого предельного значения). Т.е. пользователь может снижать приоритет своих процессов. P_CPU — это системная составляющая. Она формируется системой следующим образом: по таймеру через предопределенные периоды времени P_CPU увеличивается на единицу для процесса, работающего с процессором (когда процесс откачивается на ВЗУ, то P_CPU обнуляется).
Процессор выделяется тому процессу, у которого приоритет является наименьшим. Упрощенная формула вычисления приоритета такова:
ПРИОРИТЕТ = P_USER + P_NICE + P_CPU
Константа P_USER различается для процессов операционной системы и остальных пользовательских процессов. Для процессов операционной системы она равна нулю, для процессов пользователей она равна некоторому значению (т.е. “навешиваются гирьки на ноги” процессам пользователя, что бы они не “задавливали” процессы системы). Это позволяет априори повысить приоритет системных процессов.
Схема планирования свопинга.
Мы говорили о том что в системе определенным образом выделяется пространство для области свопинга. Имеется проблема. Есть пространство оперативной памяти в котором находятся процессы, обрабатываемые системой в режиме мультипрограммирования. Есть область на ВЗУ предназначенная для откачки этих процессов. В ОС UNIX (в модельном варианте) свопирование осуществляется всем процессом, т.е. откачивается не часть процесса а весь. Это правило действует в подавляющем числе UNIX-ов, т.е. свопинг в UNIX-е в общем не эффективен. Упрощенная схема планирования подкачки основывается на использовании некоторого приоритета, который называется P_TIME, и который также находится в контексте процесса. В этом параметре аккумулируется время пребывания процесса в состоянии мультипрограммной обработки или в области свопинга.
При перемещении процесса из оперативной памяти в область свопинга или обратно, система обнуляет значение параметра P_TIME. Для загрузки процесса в память из области свопинга выбирается процесс с максимальным значением P_TIME. Если для загрузки этого процесса нет свободного пространства оперативной памяти, тосистема ищет среди процессов в оперативной памяти процесс, ожидающий ввода/вывода, и имеющий максимальное значение P_TIME (т.е. тот, который находился в оперативной памяти дольше всех). Если такого процесса нет то выбирается просто процесс с максимальным значением P_TIME.
Эта схема не совсем эффективна. Первая неэффективность — это то, что обмены из оперативной памяти в область свопинга происходят всем процессом. Вторая неэффективность (связанная с первой) заключается в том, что если процесс закрыт по причине заказа на обмен, то этот обмен реально происходит не со свопированным процессом. Т.е. для того чтобы обмен нормально завершился весь процесс должен быть возвращен в оперативную память. Это тоже плохо, потому что если бы свопинг происходил блоками памяти, то можно было бы откачать процесс без той страницы, с которой надо меняться, а после обмена докачать из области свопинга весь процесс обратно в оперативную память. Современные UNIX-ы имеют возможность свопирования не всего процесса, а какой-то его части.
