diff options
Diffstat (limited to 'documentation/content/ru/books/design-44bsd/_index.adoc')
| -rw-r--r-- | documentation/content/ru/books/design-44bsd/_index.adoc | 235 |
1 files changed, 77 insertions, 158 deletions
diff --git a/documentation/content/ru/books/design-44bsd/_index.adoc b/documentation/content/ru/books/design-44bsd/_index.adoc index 439f26d9c2..7146569e37 100644 --- a/documentation/content/ru/books/design-44bsd/_index.adoc +++ b/documentation/content/ru/books/design-44bsd/_index.adoc @@ -1,13 +1,20 @@ --- -title: Архитектура и реализация операционной системы 4.4BSD authors: - - author: Marshall Kirk McKusick - - author: Keith Bostic - - author: Michael J. Karels - - author: John S. Quarterman -copyright: 1996 Addison-Wesley Longman, Inc + - + author: 'Marshall Kirk McKusick' + - + author: 'Keith Bostic' + - + author: 'Michael J. Karels' + - + author: 'John S. Quarterman' +bookOrder: 60 +copyright: '1996 Addison-Wesley Longman, Inc' +description: 'Предоставлено издательством Addison-Wesley и предоставляет обзор архитектуры 4.4BSD, от которой изначально произошел FreeBSD' +layout: single +tags: ["4.4BSD", "design", "operating system", "BSD", "UNIX"] +title: 'Архитектура и реализация операционной системы 4.4BSD' trademarks: ["design-44bsd"] -isIndex: true --- = Архитектура и реализация операционной системы 4.4BSD @@ -51,9 +58,9 @@ toc::[] == Обзор архитектуры 4.4BSD [[overview-facilities]] -=== Системные сервисы 4.4BSD и ядро +=== Подсистемы и ядро 4.4BSD -Ядро 4.4BSD предоставляет четыре основных системных сервиса: процессы, файловую систему, коммуникации и запуск системы. Этот раздел перечисляет, в каком месте этой книги описана каждая из этих служб. +Ядро 4.4BSD предоставляет четыре базовых подсистемы: процессы, файловую систему, коммуникации и запуск системы. Этот раздел перечисляет, в каком месте этой книги описана каждая из этих подсистем. . Процессы образуют поток управления в адресном пространстве. Механизмы создания, завершения и другие управляющие процессы описаны в Главе 4. Для каждого процесса система мультиплексирует отдельное виртуальное адресное пространство; такое управление памятью обсуждается в Главе 5. . Механизм доступа пользователя к файловой системе и устройствам один и тот же; общие аспекты обсуждаются в Главе 6. Файловая система является набором именованных файлов, организованных в древовидную иерархию каталогов, а операции по управлению ими представлены в Главе 7. Файлы располагаются на таких физических носителях, как диски. 4.4BSD поддерживает несколько типов организации данных на диске, как описано далее в Главе 8. Доступ к файлам на удаленных машинах является предметом обсуждения в Главе 9. Для доступа к системе Терминалы используются терминалы; их функционированию посвящена глава 10. @@ -64,11 +71,11 @@ toc::[] ==== Ядро -_Ядро_ является частью системы, которая работает в защищенном режиме и управляет доступом всех пользовательских программ к низкоуровнему аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) и программным компонентам (к примеру, файловой системе, сетевым протоколам). Ядро предоставляет основные системные услуги; оно создает процессы и управляет ими, предоставляет функции для доступа к файловой системе и службам связи. Такие функции, называемые _системными вызовами_, доступны процессам пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются единственным способом доступа к таким услугам. Подробно механизм работы системных вызовов дается в Главе 3, вместе с описанием некоторых механизмов ядра, работа которых не является прямым результатом процесса, выполняющего системный вызов. +_Ядро_ является частью системы, которая работает в защищенном режиме и управляет доступом всех пользовательских программ к низкоуровнему аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) и программным компонентам (к примеру, файловой системе, сетевым протоколам). Ядро предоставляет основные подсистемы; оно создает процессы и управляет ими, предоставляет функции для доступа к файловой системе и службам связи. Такие функции, называемые _системными вызовами_, доступны процессам пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются единственным способом доступа к этим подсистемам. Подробно механизм работы системных вызовов дается в Главе 3, вместе с описанием некоторых механизмов ядра, работа которых не является прямым результатом процесса, выполняющего системный вызов. -_Ядро_, по традиционной терминологии операционных систем, является маленьким куском программного обеспечения, которое предоставляет только минимальный набор услуг, необходимый для реализации дополнительных служб операционной системы. В современных исследовательских операционных системах - таких, как Chorus <<biblio-rozier, [Rozier et al, 1988]>>, Mach <<biblio-accetta, [Accetta et al, 1986]>>, Tunis <<biblio-ewens, [Ewens et al, 1985]>>, и V Kernel <<biblio-cheriton, [Cheriton, 1988]>> - такое разделение функциональности выполнено не только логически. Такие службы, как файловые системы и сетевые протоколы, выполнены в виде прикладных процессов клиентов ядра или микроядра. +_Ядро_, по традиционной терминологии операционных систем, является маленьким куском программного обеспечения, которое предоставляет только минимальный набор подсистем, необходимый для реализации дополнительных служб операционной системы. В современных исследовательских операционных системах — таких, как Chorus crossref:design-44bsd[biblio-rozier, [Rozier et al, 1988]], Mach crossref:design-44bsd[biblio-accetta, [Accetta et al, 1986]], Tunis crossref:design-44bsd[biblio-ewens, [Ewens et al, 1985]], и V Kernel crossref:design-44bsd[biblio-cheriton, [Cheriton, 1988]] - такое разделение функциональности выполнено не только логически. Такие службы, как файловые системы и сетевые протоколы, выполнены в виде прикладных процессов клиентов ядра или микроядра. -Ядро 4.4BSD не разбивается на несколько процессов. Это основополагающее архитектурное решение было сделано в самых ранних версиях UNIX. В первых двух реализациях Кена Томпсона (Ken Thompson) не было отображаемой памяти, и поэтому не было аппаратного различия между адресным пространством пользователя и ядра <<biblio-ritchie, [Ritchie, 1988]>>. Могла бы быть придумана система обмена сообщениями как реально реализуемая модель процессов ядра и пользователя. Для простоты и увеличения производительности было выбрано монолитное ядро. К тому же ранние ядра были маленькими; включение таких служб, как сетевые коммуникации, в ядро увеличило его размер. Современные тенденции в области операционных систем сводятся к уменьшению размера ядра за счет перевода таких служб в пользовательское адресное пространство. +Ядро 4.4BSD не разбивается на несколько процессов. Это основополагающее архитектурное решение было сделано в самых ранних версиях UNIX. В первых двух реализациях Кена Томпсона (Ken Thompson) не было отображаемой памяти, и поэтому не было аппаратного различия между адресным пространством пользователя и ядра crossref:design-44bsd[biblio-ritchie, [Ritchie, 1988]]. Могла бы быть придумана система обмена сообщениями как реально реализуемая модель процессов ядра и пользователя. Для простоты и увеличения производительности было выбрано монолитное ядро. К тому же ранние ядра были маленькими; включение таких подсистем, как сетевые коммуникации, в ядро увеличило его размер. Современные тенденции в области операционных систем сводятся к уменьшению размера ядра за счет перевода таких служб в пользовательское адресное пространство. Пользователи обычно общаются с системой через интерпретатор языка команд, называемый оболочкой (_shell_), и, может быть, через дополнительные прикладные пользовательские программы. Такие программы и оболочка реализованы в виде процессов. Подробное описание таких программ выходит за рамки этой книги, которая практически полностью посвящена работе ядра. @@ -79,109 +86,45 @@ _Ядро_, по традиционной терминологии операц В этом разделе мы рассматриваем организацию ядра 4.4BSD с двух точек зрения: +[arabic] . Как статический блок программного обеспечения, категоризуемый по функциональности модулей, составляющих ядро . В его динамике, категоризуемой по услугам, предоставляемым пользователям Самая большая часть ядра реализует системные услуги, к которым приложения обращаются через системные вызовы. В 4.4BSD это программное обеспечение организуется по следующим принципам: -* Базовые услуги ядра: обработка таймеров и системного таймера, управление дескрипторами и процессами +* Базовые подсистемы ядра: обработка таймеров и системного таймера, управление дескрипторами и процессами * Поддержка управления памятью: подкачка и выгрузка * Общесистемные интерфейсы: ввод/вывод, управление и мультиплексирование операций, выполняемых над дескрипторами * Файловая система: файлы, каталоги, преобразование маршрутов, блокировка файлов и управление буфером ввода/вывода * Поддержка работы с терминалами: драйвер терминального интерфейса и режимы работы терминального канала -* Службы межпроцессного взаимодействия: сокеты -* Поддержка сетевых коммуникаций: коммуникационные протоколы и общесетевые службы, такие, как маршрутизация +* Подсистемы межпроцессного взаимодействия: сокеты +* Поддержка сетевых коммуникаций: коммуникационные протоколы и общесетевые подсистемы, такие, как маршрутизация -[[table-mach-indep]] .Машинно-независимое программное обеспечение в ядре 4.4BSD -[cols="1,1,1", frame="none", options="header,footer"] +[[table-mach-indep]] +[cols=",,", options="header"] |=== -| Категория -| Количество строк кода -| Процент от всего ядра - -|файлы заголовков -|9,393 -|4.6 - -|инициализация -|1,107 -|0.6 - -|службы ядра -|8,793 -|4.4 - -|общесистемные интерфейсы -|4,782 -|2.4 - -|межпроцессное взаимодействие -|4,540 -|2.2 - -|работа с терминалами -|3,911 -|1.9 - -|виртуальная память -|11,813 -|5.8 - -|управление vnode -|7,954 -|3.9 - -|именование файловой системы -|6,550 -|3.2 - -|хранение файлов -|4,365 -|2.2 - -|хранение log-структур -|4,337 -|2.1 - -|хранение на основе памяти -|645 -|0.3 - -|файловая система cd9660 -|4,177 -|2.1 - -|различные файловые системы (10) -|12,695 -|6.3 - -|сетевая файловая система -|17,199 -|8.5 - -|сетевое взаимодействие -|8,630 -|4.3 - -|протоколы internet -|11,984 -|5.9 - -|протоколы ISO -|23,924 -|11.8 - -|протоколы X.25 -|10,626 -|5.3 - -|протоколы XNS -|5,192 -|2.6 -| всего машинно-независимая часть -| 162,617 -| 80.4 +|Категория |Строк кода |Процент от строк ядра +|заголовки |9,393 |4.6 +|инициализация |1,107 |0.6 +|подсистемы ядра |8,793 |4.4 +|универсальные интерфейсы |4,782 |2.4 +|межпроцессное взаимодействие |4,540 |2.2 +|работа с терминалом |3,911 |1.9 +|Виртуальная память |11,813 |5.8 +|управление vnode |7,954 |3.9 +|имена в файловой системы |6,550 |3.2 +|быстрое хранилище файлов |4,365 |2.2 +|логическая структура файлового хранилища |4,337 |2.1 +|хранилище файлов в памяти |645 |0.3 +|cd9660 файловая система |4,177 |2.1 +|различные файловые системы (10) |12,695 |6.3 +|сетевая файловая система |17,199 |8.5 +|сетевое взаимодействие |8,630 |4.3 +|интернет-протоколы |11,984 |5.9 +|протоколы ISO |23,924 |11.8 +|протоколы X.25 |10,626 |5.3 +|протоколы XNS |5,192 |2.6 |=== Большая часть программного обеспечения в этих категориях является машинно-независимой и переносима между различными аппаратными архитектурами. @@ -194,47 +137,21 @@ _Ядро_, по традиционной терминологии операц * Конфигурация и инициализация аппаратных устройств * Поддержка устройств ввода/вывода во время работы -[[table-mach-dep]] .Машинно-зависимое программное обеспечение для HP300 в ядре 4.4BSD -[cols="1,1,1", frame="none", options="header,footer"] +[[table-mach-dep]] +[cols=",,", options="header"] |=== -| Категория -| Количество строк кода -| Процент от всего ядра - -|машинно-зависимые заголовки -|1,562 -|0.8 - -|заголовки драйверов устройств -|3,495 -|1.7 - -|исходные тексты драйверов устройств -|17,506 -|8.7 - -|виртуальная память -|3,087 -|1.5 - -|остальная машинно-зависимая часть -|6,287 -|3.1 - -|процедуры на ассемблере -|3,014 -|1.5 - -|совместимость с HP/UX -|4,683 -|2.3 -| всего машинно-зависимая часть -| 39,634 -| 19.6 +|Категория |Строк кода |Процент от строк ядра +|заголовочные файлы, зависимые от машины |1,562 |0.8 +|заголовочные файлы драйверов устройств |3,495 |1.7 +|исходный код драйверов устройств |17,506 |8.7 +|Виртуальная память |3,087 |1.5 +|код, зависящий от других машин |6,287 |3.1 +|подпрограммы на языке ассемблера |3,014 |1.5 +|совместимость с HP/UX |4,683 |2.3 |=== -<<table-mach-indep>> суммаризует машинно-независимый код, который составляет ядро 4.4BSD для HP300. Числа во второй колонке обозначают количество строк исходного кода на языке C, заголовочных файлов и ассемблерного кода. Практически весь код ядра написан на языке программирования C; менее двух процентов написано на языке ассемблера. Как показывает статистика в <<table-mach-dep>>, машинно-зависимый код, не включающий поддержку HP/UX и устройств, составляет менее 6.9 процента ядра. +crossref:design-44bsd[table-mach-indep, Машинно-независимое программное обеспечение в ядре 4.4BSD] показывает статистику машинно-независимого кода, который составляет ядро 4.4BSD для HP300. Числа во второй колонке обозначают количество строк исходного кода на языке C, заголовочных файлов и ассемблерного кода. Практически весь код ядра написан на языке программирования C; менее двух процентов написано на языке ассемблера. Как показывает статистика в crossref:design-44bsd[table-mach-dep, Машинно-зависимое программное обеспечение для HP300 в ядре 4.4BSD], машинно-зависимый код, не включающий поддержку HP/UX и устройств, составляет менее 6.9 процента ядра. Лишь малая часть ядра отвечает за инициализацию системы. Этот код используется при _начальной загрузке_ системы для перехода в рабочий режим и отвечает за настройку аппаратного и программного окружения ядра (обратитесь к Главе 14). Некоторые операционные системы (особенно те, что ограничены объемом физической памяти) выполняют действия по выгрузке или _перекрытию_ программного кода, выполняющего эти функции, после окончания его работы. Ядро 4.4BSD не работает повторно с памятью, использованной начальным кодом, потому что этот объем памяти составляет менее 0.5 процентов ресурсов ядра, используемых на типичной машине. Также начальный код не находится только в одном месте ядра - он рассредоточен везде, и обычно появляется там, где логически связан с объектом инициализации. @@ -256,9 +173,9 @@ _Ядро_, по традиционной терминологии операц [[fig-process-lifecycle]] .Жизненный цикл процесса -image::fig1.png[Системные вызовы управления процессами] +image:fig1.png[Жизненный цикл процесса] -Жизненный цикл процесса изображен на <<fig-process-lifecycle>>. Процесс может создать новый процесс, который является копией исходного процесса с помощью системного вызова _fork_. Возврат из вызова _fork_ происходит два раза: один раз в родительском процессе, в котором возвращаемое значение является идентификатором порожденного процесса, и второй раз в порожденном процессе, в котором возвращаемое значение равно 0. Связь родитель-потомок порождает иерархическую структуру процессов в системе. Новый процесс имеет доступ ко всем ресурсам его родителя, таким, как файловые дескрипторы, состояние обработки сигналов и распределение памяти. +Жизненный цикл процесса изображен на рисунке crossref:design-44bsd[fig-process-lifecycle,Жизненный цикл процесса]. Процесс может создать новый процесс, который является копией исходного процесса с помощью системного вызова _fork_. Возврат из вызова _fork_ происходит два раза: один раз в родительском процессе, в котором возвращаемое значение является идентификатором порожденного процесса, и второй раз в порожденном процессе, в котором возвращаемое значение равно 0. Связь родитель-потомок порождает иерархическую структуру процессов в системе. Новый процесс имеет доступ ко всем ресурсам его родителя, таким, как файловые дескрипторы, состояние обработки сигналов и распределение памяти. Хотя есть ситуации, когда процесс должен быть копией своего родителя, наиболее типичным и полезным действием является загрузка и выполнение другой программы. Процесс может заместить себя образом памяти другой программы, передавая вновь созданному образу набор параметров, при помощи системного вызова _execve_. Одним из параметров является имя файла, содержимое которого имеет формате, распознаваемый системой - это либо двоичный выполняемый файл, либо файл, который приводит к запуску указанной программы интерпретации для обработки его содержимого. @@ -268,7 +185,7 @@ image::fig1.png[Системные вызовы управления проце Подробное описание того, как ядро создает и уничтожает процессы, дается в Главе 5. -Планирование выполнения процессов осуществляется согласно параметру _приоритетности процесса_. Этот приоритет управляется алгоритмом планирования задач в ядре. Пользователи могут влиять на выполнение процесса, задавая этот параметр (_nice_), который влияет на суммарный приоритет, но но ограничен использованием ресурсов CPU согласно алгоритму планировщика задач ядра. +Планирование выполнения процессов осуществляется согласно параметру _приоритетности процесса_. Этот приоритет управляется алгоритмом планирования задач в ядре. Пользователи могут влиять на выполнение процесса, задавая этот параметр (_nice_), который влияет на суммарный приоритет, но ограничен использованием ресурсов CPU согласно алгоритму планировщика задач ядра. ==== Сигналы @@ -307,11 +224,11 @@ image::fig1.png[Системные вызовы управления проце В 4.2BSD требовалось реализовать поддержку больших несвязанных адресных пространств, отображаемых в память файлов и совместно используемой памяти. Был спроектирован интерфейс, который назвали _mmap_, позволяющий несвязанным процессам запрашивать отображение в их адресное пространство файла в режиме совместного использования. Если несколько процессов отображают в свое адресное пространство один и тот же файл, то изменение адресного пространства процесса, соответствующего файлу, в одном процессе, будет отображено в области отображения этого файла в другом процессе, а также и в самом файле. Однако в конце концов 4.2BSD была выпущена без интерфейса _mmap_ из-за необходимости сделать в первую очередь другие возможности, такие, как работа с сетью. -Затем разработка интерфейса _mmap_ продолжалась во время работы над 4.3BSD. Более 40 компаний и исследовательских групп принимали участие в обсуждениях, которые привели к появлению обновленной концепции, описанной в Berkeley Software Architecture Manual <<biblio-mckusick-1, [McKusick et al, 1994]>>. Несколько компаний реализовали этот обновленный интерфейс <<biblio-gingell, [Gingell et al, 1987]>>. +Затем разработка интерфейса _mmap_ продолжалась во время работы над 4.3BSD. Более 40 компаний и исследовательских групп принимали участие в обсуждениях, которые привели к появлению обновленной концепции, описанной в Berkeley Software Architecture Manual crossref:design-44bsd[biblio-mckusick-1, [McKusick et al, 1994]]. Несколько компаний реализовали этот обновленный интерфейс crossref:design-44bsd[biblio-gingell, [Gingell et al, 1987]]. И снова сроки разработки не позволили включить в 4.3BSD реализацию этого интерфейса. Хотя позже она могла быть встроена в имеющуюся подсистему виртуальной памяти 4.3BSD, разработчики решили не включать ее сюда. потому что этой реализации было уже более 10 лет. Более того, оригинальная архитектура виртуальной памяти была основана на предположении, что компьютерная память мала и дорога, а диски подключены непосредственно к компьютеру, быстры и дешевы. Поэтому подсистема виртуальной памяти была разработана с упором на бережное использование памяти ценой более частых обращений к диску. Вдобавок реализация в 4.3BSD была пронизана зависимостями от аппаратной системы управления памятью машин VAX, что препятствовало ее переносу на другие аппаратные платформы. И наконец, подсистема виртуальной памяти не была предназначена для поддержки связных многопроцессорных систем, которые сейчас становятся все более распространенными и необходимыми. -Попытки постепенно усовершенствовать старую реализацию заведомо были обречены на неудачу. Полностью новая архитектура, с другой стороны, могла бы использовать большие объемы памяти, уменьшить дисковые операции и обеспечивать работу с несколькими процессорами. Наконец, система виртуальной памяти в 4.4BSD была полностью изменена. Система виртуальной памяти 4.4BSD основана на системе виртуальной памяти (VM) Mach 2.0 <<biblio-tevanian, [Tevanian, 1987]>> с заимствованиями из Mach 2.5 и Mach 3.0. В ней была эффективная поддержка совместного использования, полное разделение машинно-зависимой и машинно-независимой частей, а также (сейчас не используемая) поддержка работы с несколькими процессорами. Процессы могут отображать файлы в любую область своего адресного пространства. Они могут совместно использовать части своих адресных пространств посредством отображения в память одного и того же файла. Изменения, сделанные одним процессом, видны в адресном пространстве другого процесса, а также записываются и в сам файл. Процессы могут также запрашивать эксклюзивное отображение файла в память, при котором любые изменения, сделанные процессом, не видны другим процессам, которые отображают файл в память и не записываются обратно в файл. +Попытки постепенно усовершенствовать старую реализацию заведомо были обречены на неудачу. Полностью новая архитектура, с другой стороны, могла бы использовать большие объемы памяти, уменьшить дисковые операции и обеспечивать работу с несколькими процессорами. Наконец, система виртуальной памяти в 4.4BSD была полностью изменена. Система виртуальной памяти 4.4BSD основана на системе виртуальнй памяти (VM) crossref:design-44bsd[biblio-tevanian, [Tevanian, 1987]] с заимствованиями из Mach 2.5 и Mach 3.0. В ней была эффективная поддержка совместного использования, полное разделение машинно-зависимой и машинно-независимой частей, а также (сейчас не используемая) поддержка работы с несколькими процессорами. Процессы могут отображать файлы в любую область своего адресного пространства. Они могут совместно использовать части своих адресных пространств посредством отображения в память одного и того же файла. Изменения, сделанные одним процессом, видны в адресном пространстве другого процесса, а также записываются и в сам файл. Процессы могут также запрашивать эксклюзивное отображение файла в память, при котором любые изменения, сделанные процессом, не видны другим процессам, которые отображают файл в память и не записываются обратно в файл. Еще одной проблемой с системой виртуальной памяти является способ, которым информация передается ядру при выполнении системного вызова. 4.4BSD всегда копирует данные из адресного пространства процесса в буфер ядра. Для операций чтения и записи, при которых передаются большие объемы данных, выполнение копирования может оказаться занимающим время процессом. Альтернативным способом является манипуляции с адресным пространством процесса в ядре. Ядро 4.4BSD всегда копирует данные о нескольким причинам: @@ -326,14 +243,14 @@ image::fig1.png[Системные вызовы управления проце Ядро часто выполняет выделение памяти, которое нужно только для выполнения единственного системного вызова. В пользовательском процессе такая кратковременно используемая память будет выделяться в стеке во время выполнения. Так как ядро имеет ограниченный объем стека времени выполнения, то неэффективно выделять в нем даже блоки памяти среднего размера. Таким образом, такая память должна выделяться посредством более гибкого механизма. Например, когда системный вызов должен преобразовать имя каталога, он должен выделить буфер размером 1 Кбайт для хранения имени. Другие блоки памяти должны выделяться на более продолжительный срок, чем один системный вызов, и поэтому не могут выделяться в стеке, даже если там есть место. В качестве примера можно взять блоки управления протоколами, которые существуют на всем протяжении сетевого соединения. -Необходимость в динамическом выделении памяти в ядре становилась все более острой вместе с добавлением количества сервисов. Общий механизм выделения памяти уменьшает сложность написания кода в ядре. Поэтому в 4.4BSD ядро имеет единый механизм выделения памяти, который может использоваться в любой части системы. У него есть интерфейс, похожий на функции библиотеки языка C _malloc_ и _free_, которые обеспечивают выделение памяти в прикладных программах <<biblio-mckusick-2, [McKusick & Karels, 1988]>>. Как интерфейс библиотеки языка C, функция выделения памяти получает параметр, указывающий на размер памяти, который необходим. Диапазон запрашиваемых объемов выделяемой памяти не ограничен; однако выделяемая физическая память не подвергается постраничной подгрузке. Функции освобождения памяти передается указатель на освобождаемый участок памяти, но указывать размер освобождаемого участка памяти не нужно. +Необходимость в динамическом выделении памяти в ядре становилась все более острой вместе с добавлением количества сервисов. Общий механизм выделения памяти уменьшает сложность написания кода в ядре. Поэтому в 4.4BSD ядро имеет единый механизм выделения памяти, который может использоваться в любой части системы. У него есть интерфейс, похожий на функции библиотеки языка C _malloc_ и _free_, которые обеспечивают выделение памяти в прикладных программах crossref:design-44bsd[biblio-mckusick-2, [McKusick & Karels, 1988]]. Как интерфейс библиотеки языка C, функция выделения памяти получает параметр, указывающий на размер памяти, который необходим. Диапазон запрашиваемых объемов выделяемой памяти не ограничен; однако выделяемая физическая память не подвергается постраничной подгрузке. Функции освобождения памяти передается указатель на освобождаемый участок памяти, но указывать размер освобождаемого участка памяти не нужно. [[overview-io-system]] === Система ввода/вывода Базовой моделью системы ввода/вывода UNIX является последовательность байт, доступ к которым может осуществляться как последовательно, так и в в произвольном порядке. В типичном пользовательском процессе UNIX нет таких понятий, как _методы доступа_ или _управляющие блоки_. -Различные программы используют разнообразные структуры данных, но ядро не связывает ввод/вывод с используемыми структурами. Например, текстовым файлом считается файл из строк символов набора ASCII, которые разделены одним символом новой строки (символ ASCII перевода строки), но ядро не знает ничего об этом соглашении. Для удовлетворения потребностей большинства программ модель еще более упрощена и сводится к потоку байт данных, или _потоку ввода/вывода_. Такое единое представление данных позволяет работать характерному для UNIX подходу на основе инструментов <<biblio-kernighan, [Kernighan & Pike, 1984]>>. Поток ввода/вывода одной программы может быть подан в качестве входной информации практически любой другой программе. (Этот тип традиционных для UNIX потоков ввода/выводы не нужно путать с потоковой системой ввода/вывода из Eighth Edition или с потоками из System V, Release 3 (STREAMS), оба из которых доступны как обычные потоки ввода/вывода.) +Различные программы используют разнообразные структуры данных, но ядро не связывает ввод/вывод с используемыми структурами. Например, текстовым файлом считается файл из строк символов набора ASCII, которые разделены одним символом новой строки (символ ASCII перевода строки), но ядро не знает ничего об этом соглашении. Для удовлетворения потребностей большинства программ модель еще более упрощена и сводится к потоку байт данных, или _потоку ввода/вывода_. Такое единое представление данных позволяет работать характерному для UNIX подходу на основе инструментов crossref:design-44bsd[biblio-kernighan, [Kernighan & Pike, 1984]]. Поток ввода/вывода одной программы может быть подан в качестве входной информации практически любой другой программе. (Этот тип традиционных для UNIX потоков ввода/выводы не нужно путать с потоковой системой ввода/вывода из Eighth Edition или с потоками из System V, Release 3 (STREAMS), оба из которых доступны как обычные потоки ввода/вывода.) ==== Дескрипторы и ввод/вывод @@ -367,7 +284,7 @@ image::fig1.png[Системные вызовы управления проце Аппаратные устройства имеют связанные с ними имена файлов, и к ним может обращаться пользователь при помощи тех же самых системных вызовов, что используются для обычных файлов. Ядро может различать _специальный файл устройства_ или просто _специальный файл_, и может определять, к какому устройству он относится, но большинство процессов не выполняют такого распознавания. Терминалы, принтеры и стримеры все доступны как последовательности байт, как дисковые файлы 4.4BSD. Таким образом, особенности работы устройств максимально скрываются ядром, и даже в ядре большинство из них отличаются в драйверах. -Аппаратные устройства могут быть разделены на _структурированные_ или _неструктурированные_; они известны под названиями _блочные_ и _посимвольные_, соответственно. Как правило, процессы обращаются к устройствам посредством _специальных файлов_ в файловой системе. Операции ввода/вывода, выполняемые с такими файлами, обрабатываются постоянно находящимися в ядре программными модулями, называемыми _драйверами устройств_. Большинство аппаратных устройств для сетевых коммуникаций доступны только при помощи механизмов межпроцессного взаимодействия, и не имеют специальных устройств в пространстве имен файловой системы, так как интерфейс _низкоуровневых сокетов_ дает более естественный интерфейс, чем специальный файл. +Аппаратные устройства могут быть разделены на _структурированные_ или _неструктурированные_; они известны под названиями _блочные_ и _посимвольные_, соответственно. Как правило, процессы обращаются к устройствам посредством _специальных файлов_ в файловой системе. Операции ввода/вывода, выполняемые с такими файлами, обрабатываются постоянно находящимися в ядре программными модулями, называемыми _драйверами устройств_. Большинство аппаратных устройств для сетевых коммуникаций доступны только при помощи подсистемы межпроцессного взаимодействия, и не имеют специальных устройств в пространстве имен файловой системы, так как интерфейс _низкоуровневых сокетов_ дает более естественный интерфейс, чем специальный файл. Структурированные или блочные устройства разделяются на диски и магнитные ленты и включают в себя большинство устройств с произвольным доступом. Ядро поддерживает операции буферизации типа чтение-изменение-запись с блочными структурированными устройствами для того, чтобы разрешить последним осуществлять чтение и запись полностью произвольным образом, как с обычными файлами. Файловые системы создаются на блочных устройствах. @@ -411,17 +328,17 @@ System V предоставляет механизм локального меж Компонент под названием _имя файла_ является строкой длиной до 255 символов. Эти имена хранятся в файле особого типа, который называется _каталогом_. Информация о файле в каталоге называется _записью каталога_ и включает, кроме имени файла, указатель на сам файл. Записи каталога могут ссылаться как на другие каталоги, так и на обычные файлы. Таким образом формируется иерархия каталогов и файлов, которая и называется файловой системой _filesystem_; -[[fig-small-fs]] .Небольшая файловая система -image::fig2.png[Дерево небольшой файловой системы] +[[fig-small-fs]] +image:fig2.png[Дерево небольшой файловой системы] -Одна небольшая файловая система показана на <<fig-small-fs>>. Каталоги могут содержать подкаталоги, и нет ограничений вложенности одного каталога в другой по глубине. Для соблюдения целостности файловой системы, ядро не позволяет процессу производить запись непосредственно в каталоги. Файловая система может хранить не только обычные файлы и каталоги, но также ссылки на другие объекты, такие, как устройства и сокеты. +Одна небольшая файловая система показана на crossref:design-44bsd[fig-small-fs, A small filesystem]. Каталоги могут содержать подкаталоги, и нет ограничений вложенности одного каталога в другой по глубине. Для соблюдения целостности файловой системы, ядро не позволяет процессу производить запись непосредственно в каталоги. Файловая система может хранить не только обычные файлы и каталоги, но также ссылки на другие объекты, такие, как устройства и сокеты. Файловая система образует дерево, начало которого находится в _корневом каталоге_, иногда называемому по имени _слэш_, которое соответствует символу одинарной наклонной черты (/). Корневой каталог содержит файлы; в нашем примере на Рисунке 2.2, он содержит [.filename]#vmunix#, копию выполнимого объектного файла ядра. В нем также расположены каталоги; в этом примере он содержит каталог [.filename]#usr#. Внутри каталога [.filename]#usr# располагается каталог [.filename]#bin#, который в основном содержит выполнимый объектный код программ, таких, как [.filename]#ls# и [.filename]#vi#. Процесс обращается к файлу, указывая _путь_ до него, который является строкой, состоящей из нескольких или ни одного имен файлов, разделенных символами слэша (/). С каждым процессом ядро связывает два каталога, при помощи которых можно интерпретировать маршруты до файлов. _Корневой каталог_ процесса является самой верхней точкой файловой системы, которую может достичь процесс; обычно он соответствует корневому каталогу всей файловой системы. Маршрут, начинающийся с символа слэша, называется _абсолютным маршрутом_, и интерпретируется ядром, начиная с корневого каталога процесса. -Имя пути, которое не начинается со слэша, называется _относительным маршрутом_, и интерпретируется относительно _текущего рабочего каталога_ процесса. (Этот каталог кратко также называют _текущим каталогом_ или _рабочим каталогом_.) Текущий каталог сам по себе можно обозначить непосредственно по имени _dot_, что соответствует одной точке ([.filename]#.#). Имя файла _dot-dot_ ([.filename]#..#) обозначает родительский каталог текущего каталога. Корневой каталог является предком самому себе. +Имя пути, которое не начинается со слэша, называется _относительным маршрутом_, и интерпретируется относительно _текущего рабочего каталога_ процесса. (Этот каталог кратко также называют _текущим каталогом_ или _рабочим каталогом_.) Текущий каталог сам по себе можно обозначить непосредственно по имени _dot_, что соответствует одной точке (`.`). Имя файла _dot-dot_ (`..`) обозначает родительский каталог текущего каталога. Корневой каталог является предком самому себе. Процесс может задать собственный корневой каталог при помощи системного вызова _chroot_, и установить текущий каталог системным вызовом _chdir_. Каждый процесс может в любой момент выполнить вызов _chdir_, но _chroot_ позволено выполнять только процессу с административными привилегиями. _Chroot_ обычно используется для ограничения доступа к системе. @@ -435,6 +352,7 @@ image::fig2.png[Дерево небольшой файловой системы] Файлы организованы иерархически в _каталоги_. Каталог является типом файла, но, в отличие от обычных файлов, каталог имеет структуру, определяемую системой. Процесс может читать каталог, как будто это обычный файл, но только ядру разрешено изменять каталог. Каталоги создаются системным вызовом _mkdir_ и удаляются системным вызовом _rmdir_. До 4.2BSD системные вызовы _mkdir_ и _rmdir_ были реализованы как последовательность системных вызовов _link_ и _unlink_. Имелось три причины для добавления системных вызовов специально для создания и удаления каталогов: +[arabic] . Операция может быть сделана атомарной. Если система завершила работу аварийно, то каталог не может оставаться в промежуточном состоянии, что может случиться при последовательном вызове серии операций. . При работе сетевой файловой системы создание и удаление файлов и каталогов должны выполняться атомарно, чтобы могли выполняться последовательно. . При реализации поддержки не-UNIX файловых систем, таких, как файловая система MS-DOS, на другом разделе диска, может оказаться, что эта файловая система не поддерживает ссылочных операций. Хотя другие файловые системы могут поддерживать концепцию каталогов, скорее всего, они не будут создавать и удалять каталоги со ссылками, как это делается в файловой системе UNIX. Соответственно они могут создавать и и удалять каталоги только при наличии явных запросов на удаление или создание каталогов. @@ -447,6 +365,7 @@ image::fig2.png[Дерево небольшой файловой системы] Вновь создаваемым файлам присваивается идентификатор пользователя процесса, который их создал, и идентификатор группы каталога, в котором они были созданы. Для защиты файлов применяется трехуровневый механизм управления доступом. Эти три уровня определяют доступность файла для +[arabic] . Пользователя, который является владельцем файла . Группы, которая приписана файлу . Всех остальных @@ -457,7 +376,7 @@ image::fig2.png[Дерево небольшой файловой системы] Ранние версии UNIX имели ограничение в 14 символов на имя файла. Это ограничение зачастую вызывало проблемы. Например, кроме естественного желания пользователей давать файлам длинные описательные имена, распространенным способом формировать имена файлов является использование формата [.filename]#basename.extension#, где расширение (указывающее на тип файла, скажем, `.c` для исходного года на языке C или `.o` для промежуточного двоичного объекта) имеет длину от одного до трех символов, оставляя от 10 до 12 символов на имя файла. Системы управления исходным кодом и редакторы обычно используют дополнительно два символа для своих целей, для префикса или суффикса имени файла, при этом остается от восьми до 10 символов. В качестве имени файла легко использовать от 10 до 12 символов одного английского слова (например, `multiplexer`). -Можно смириться с этими ограничениями, но это непоследовательно и даже опасно, потому что другие системы UNIX могут работать со строками, превышающими этот лимит, при создании файлов, но затем имя будет _обрезано_. Исходный файл с именем [.filename]#multiplexer.c#, содержащий исходный код на языке C, (уже 13 символов) может иметь соответствующий файл из системы управления исходным кодом с префиксом `s.`, при этом получается имя файла [.filename]#s.multiplexer#, которое не не будет отличаться от файла системы управления исходным кодом для файла [.filename]#multiplexer.ms#, содержащего исходный код `troff` для документации программы на языке C. Содержимое двух оригинальных файлов может оказаться перепутанным без каких-либо предупреждений от системы управления исходным кодом. При тщательном кодировании эту проблему можно обнаружить, но поддержка длинных имен файлов, впервые появившаяся в 4.2BSD, практически полностью ликвидировала эту проблему. +Можно смириться с этими ограничениями, но это непоследовательно и даже опасно, потому что другие системы UNIX могут работать со строками, превышающими этот лимит, при создании файлов, но затем имя будет _обрезано_. Исходный файл с именем [.filename]#multiplexer.c#, содержащий исходный код на языке C, (уже 13 символов) может иметь соответствующий файл из системы управления исходным кодом с префиксом `s.`, при этом получается имя файла [.filename]#s.multiplexer#, которое не будет отличаться от файла системы управления исходным кодом для файла [.filename]#multiplexer.ms#, содержащего исходный код `troff` для документации программы на языке C. Содержимое двух оригинальных файлов может оказаться перепутанным без каких-либо предупреждений от системы управления исходным кодом. При тщательном кодировании эту проблему можно обнаружить, но поддержка длинных имен файлов, впервые появившаяся в 4.2BSD, практически полностью ликвидировала эту проблему. [[overview-filestore]] === Размещение файлов @@ -467,7 +386,7 @@ image::fig2.png[Дерево небольшой файловой системы] Другой частью локальной файловой системы является организация и управление данными на носителях информации. Размещение содержимого файлов на носителях является вопросом хранилища файлов. В 4.4BSD поддерживает три различных типа хранилищ файлов: * Традиционная файловая система Berkeley Fast Filesystem -* Журналируемая файловая система, основанная на архитектуре операционной системы Sprite <<biblio-rosenblum, [Rosenblum & Ousterhout, 1992]>> +* Журналируемая файловая система, основанная на архитектуре операционной системы Sprite crossref:design-44bsd[biblio-rosenblum, [Rosenblum & Ousterhout, 1992]] * Файловая система в памяти Хотя организация этих хранилищ совершенно различна, эти различия скрыты от процессов, использующих файловые системы. @@ -487,7 +406,7 @@ image::fig2.png[Дерево небольшой файловой системы] Когда локальный клиент выполняет операцию на удаленной файловой системе, оформляется и посылается запрос к серверу. Сервер выполняет запрошенную операцию и возвращает либо запрошенную информацию, либо ошибку, почему запрос был отклонен. Для получения удовлетворительной производительности, клиент должен кэшировать данные, к которым доступ осуществляется часто. Сложность удаленных файловых систем отражается на поддержке соответствия между сервером и множеством его клиентов. -Хотя за эти годы было разработано множество протоколов работы с удаленными файловыми системами, самой распространенной на системах UNIX является сетевая файловая система Network Filesystem (NFS), которая была спроектирована и реализована в Sun Microsystems. Ядро 4.4BSD поддерживает протокол NFS, хотя его реализация была выполнена независимо от спецификаций протокола <<biblio-macklem, [Macklem, 1994]>>. Протокол NFS описан в Главе 9. +Хотя за эти годы было разработано множество протоколов работы с удаленными файловыми системами, самой распространенной на системах UNIX является сетевая файловая система Network Filesystem (NFS), которая была спроектирована и реализована в Sun Microsystems. Ядро 4.4BSD поддерживает протокол NFS, хотя его реализация была выполнена независимо от спецификаций протокола crossref:design-44bsd[biblio-macklem, [Macklem, 1994]]. Протокол NFS описан в Главе 9. [[overview-terminal]] === Терминалы @@ -510,7 +429,7 @@ image::fig2.png[Дерево небольшой файловой системы] Каждый из этих сервисов преобразования может быть независимо выключен процессом при помощи управляющих запросов. [[overview-ipc]] -=== Коммуникации между процессами +=== Межпроцессное взаимодействие Межпроцессные коммуникации в 4.4BSD организованы в _коммуникационные домены_. К поддерживаемым на данный момент доменам относятся _локальный домен_ для взаимодействия между процессами, выполняющимися на одной и той же машине; _межсетевой домен_ для связи между процессами посредством набора протоколов TCP/IP (возможно, в сети Интернет); семейство протоколов ISO/OSI для взаимодействия между сайтами, которым нужна именно такая связь, и _домен XNS_ для коммуникаций между процессами при помощи протоколов XEROX Network Systems (XNS). @@ -520,7 +439,7 @@ image::fig2.png[Дерево небольшой файловой системы] Сокеты могут иметь адреса, связанные с ними. Формат и смысл адресов сокетов зависят от коммуникационного домена, в котором был создан сокет. Привязка имени к сокету в локальном домене приводит к созданию файла в файловой системе. -Обычные данные, передаваемые и получаемые при помощи сокетов, не имеют типа. Вопросы представления данных зависят от библиотек, которые находятся на верху коммуникационных сервисов. Вдобавок к передаче обычных данных, коммуникационные домены могут поддерживать передачу и прием специальных типов данных, которые называются _правами доступа_. Например, локальный домен использует эту возможность для передачи дескрипторов между процессами. +Обычные данные, передаваемые и получаемые при помощи сокетов, не имеют типа. Вопросы представления данных зависят от библиотек, которые находятся на верху коммуникационной подсистемы. Вдобавок к передаче обычных данных, коммуникационные домены могут поддерживать передачу и прием специальных типов данных, которые называются _правами доступа_. Например, локальный домен использует эту возможность для передачи дескрипторов между процессами. До 4.2BSD сетевые реализации в UNIX обычно работали через интерфейсы символьных устройств. Одной из целей создания интерфейса сокетов было обеспечение работы простеньким программам без изменения на потоковых соединениях. Такие программы могут работать, если только не меняются системные вызовы _read_ и _write_. Соответственно, оригинальные интерфейсы не трогались, но были исправлены для работы с потоковыми сокетами. Для более сложных сокетов, таких, как те, что используются для посылки датаграмм и в которых при каждом вызове _send_ должен указываться адрес назначения, был добавлен новый интерфейс. @@ -553,7 +472,7 @@ image::fig2.png[Дерево небольшой файловой системы] [bibliography] [[references]] -== Ссылки +== Список литературы [[biblio-accetta]] Accetta et al, 1986 Mach: A New Kernel Foundation for UNIX Development" M.Accetta R.Baron W.Bolosky D.Golub R.Rashid A.Tevanian M.Young 93-113 USENIX Association Conference Proceedings USENIX Association June 1986 |