git: 3ad76742d6 - main - update translation of books/design-44bsd to Russian

The branch main has been updated by vladlen:

URL: https://cgit.FreeBSD.org/doc/commit/?id=3ad76742d622215a60dbab44eb9328b6c62176b3

commit 3ad76742d622215a60dbab44eb9328b6c62176b3
Author:     Vladlen Popolitov <[email protected]>
AuthorDate: 2025-10-03 15:14:15 +0000
Commit:     Vladlen Popolitov <[email protected]>
CommitDate: 2025-10-03 15:14:15 +0000

    update translation of books/design-44bsd to Russian
    
    Reviewed by: maxim (mentor)
    Approved by: maxim (mentor)
    Differential Revision: https://reviews.freebsd.org/D52015
---
 .../content/ru/books/design-44bsd/_index.adoc      |  235 +-
 .../content/ru/books/design-44bsd/_index.po        | 3677 ++++++++++++++++++++
 2 files changed, 3754 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-44
 bsd[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:desig
 n-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 символов. Эти имена хранятся в файле особого типа, который называется _каталогом_. Информация о файле в каталоге называется _записью каталога_ и включает, кроме имени файла, указатель на сам файл. Записи каталога могут ссылаться как на другие каталоги, так и на обычные файлы. Таким образом формируется иерархия каталогов и файлов, которая и называется файловой системой _fil
 esystem_;
 
-[[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# располагается каталог [.fil
 ename]#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_ и _un
 link_. Имелось три причины для добавления системных вызовов специально для создания и удаления каталогов:
 
+[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 для взаимодействия между сайтами, которым нужна именно такая связь, и _домен XN
 S_ для коммуникаций между процессами при помощи протоколов 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
 
diff --git a/documentation/content/ru/books/design-44bsd/_index.po b/documentation/content/ru/books/design-44bsd/_index.po
new file mode 100644
index 0000000000..e94660b26e
--- /dev/null
+++ b/documentation/content/ru/books/design-44bsd/_index.po
@@ -0,0 +1,3677 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Vladlen Popolitov <[email protected]>, 2025.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2025-10-03 18:09+0300\n"
+"PO-Revision-Date: 2025-10-03 04:45+0000\n"
+"Last-Translator: Vladlen Popolitov <[email protected]>\n"
+"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
+"documentation/booksdesign-44bsd_index/ru/>\n"
+"Language: ru\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && "
+"n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"
+"X-Generator: Weblate 4.17\n"
+
+#. type: Yaml Front Matter Hash Value: description
+#: documentation/content/en/books/design-44bsd/_index.adoc:1
+#, no-wrap
+msgid "Donated by Addison-Wesley, provides a design overview of 4.4BSD, from which FreeBSD was originally derived"
+msgstr "Предоставлено издательством Addison-Wesley и предоставляет обзор архитектуры 4.4BSD, от которой изначально произошел FreeBSD"
+
+#. type: Title =
+#: documentation/content/en/books/design-44bsd/_index.adoc:1
+#: documentation/content/en/books/design-44bsd/_index.adoc:16
+#, no-wrap
+msgid "The Design and Implementation of the 4.4BSD Operating System"
+msgstr "Архитектура и реализация операционной системы 4.4BSD"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:50
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/books/design-44bsd/_index.adoc:54
+#, no-wrap
+msgid "Design Overview of 4.4BSD"
+msgstr "Обзор архитектуры 4.4BSD"
+
+#. type: Title ===
+#: documentation/content/en/books/design-44bsd/_index.adoc:57
+#, no-wrap
+msgid "4.4BSD Facilities and the Kernel"
+msgstr "Подсистемы и ядро 4.4BSD"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:61
+msgid ""
+"The 4.4BSD kernel provides four basic facilities: processes, a filesystem, "
+"communications, and system startup.  This section outlines where each of "
+"these four basic services is described in this book."
+msgstr ""
+"Ядро 4.4BSD предоставляет четыре базовых подсистемы: процессы, файловую "
+"систему, коммуникации и запуск системы. Этот раздел перечисляет, в каком "
+"месте этой книги описана каждая из этих подсистем."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:63
+msgid ""
+"Processes constitute a thread of control in an address space. Mechanisms for "
+"creating, terminating, and otherwise controlling processes are described in "
+"Chapter 4. The system multiplexes separate virtual-address spaces for each "
+"process; this memory management is discussed in Chapter 5."
+msgstr ""
+"Процессы образуют поток управления в адресном пространстве. Механизмы "
+"создания, завершения и другие управляющие процессы описаны в Главе 4. Для "
+"каждого процесса система мультиплексирует отдельное виртуальное адресное "
+"пространство; такое управление памятью обсуждается в Главе 5."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:64
+msgid ""
+"The user interface to the filesystem and devices is similar; common aspects "
+"are discussed in Chapter 6. The filesystem is a set of named files, "
+"organized in a tree-structured hierarchy of directories, and of operations "
+"to manipulate them, as presented in Chapter 7. Files reside on physical "
+"media such as disks. 4.4BSD supports several organizations of data on the "
+"disk, as set forth in Chapter 8. Access to files on remote machines is the "
+"subject of Chapter 9. Terminals are used to access the system; their "
+"operation is the subject of Chapter 10."
+msgstr ""
+"Механизм доступа пользователя к файловой системе и устройствам один и тот "
+"же; общие аспекты обсуждаются в Главе 6. Файловая система является набором "
+"именованных файлов, организованных в древовидную иерархию каталогов, а "
+"операции по управлению ими представлены в Главе 7. Файлы располагаются на "
+"таких физических носителях, как диски. 4.4BSD поддерживает несколько типов "
+"организации данных на диске, как описано далее в Главе 8. Доступ к файлам на "
+"удаленных машинах является предметом обсуждения в Главе 9. Для доступа к "
+"системе Терминалы используются терминалы; их функционированию посвящена "
+"глава 10."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:65
+msgid ""
+"Communication mechanisms provided by traditional UNIX systems include "
+"simplex reliable byte streams between related processes (see pipes, Section "
+"11.1), and notification of exceptional events (see signals, Section 4.7). "
+"4.4BSD also has a general interprocess-communication facility. This "
+"facility, described in Chapter 11, uses access mechanisms distinct from "
+"those of the filesystem, but, once a connection is set up, a process can "
+"access it as though it were a pipe. There is a general networking framework, "
+"discussed in Chapter 12, that is normally used as a layer underlying the IPC "
+"facility. Chapter 13 describes a particular networking implementation in "
+"detail."
+msgstr ""
+"Механизмы коммуникаций, предоставляемые традиционными UNIX-системами, "
+"включают однонаправленные потоки байтов между связанными процессами "
+"(смотрите материал о конвейерах в Разделе 11.1) и извещение об "
+"исключительных событиях (смотрите материал о сигналах в Разделе 4.7). В "
+"4.4BSD имеется также механизм межпроцессного взаимодействия между "
+"процессами. Этот механизм, описываемый в Главе 11, использует способы "
+"доступа, отличающиеся от тех, что используются в файловой системе, но, как "
+"только соединение установлено, процесс может работать с ним, как будто это "
+"конвейер. Имеется и механизм работы с сетью, описываемый в Главе 12, который "
+"обычно используется как слой ниже механизма IPC. В Главе 13 дается детальное "
+"описание конкретной реализации механизма работы с сетью."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:66
+msgid ""
+"Any real operating system has operational issues, such as how to start it "
+"running. Startup and operational issues are described in Chapter 14."
+msgstr ""
+"В любой операционной системе присутствуют вопросы управления, такие, как ее "
+"запуск. Запуск и вопросы управления обсуждаются в Главе 14."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:70
+msgid ""
+"Sections 2.3 through 2.14 present introductory material related to Chapters "
+"3 through 14.  We shall define terms, mention basic system calls, and "
+"explore historical developments.  Finally, we shall give the reasons for "
+"many major design decisions."
+msgstr ""
+"Разделы с 2.3 по 2.14 представляют собой вводный материал, относящийся к "
+"главам с 3 по 14. Мы определим понятия, коснемся основных системных вызовов "
+"и рассмотрим исторические разработки. Наконец, мы расскажем о причинах "
+"многих ключевых архитектурных решений."
+
+#. type: Title ====
+#: documentation/content/en/books/design-44bsd/_index.adoc:71
+#, no-wrap
+msgid "The Kernel"
+msgstr "Ядро"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:78
+msgid ""
+"The _kernel_ is the part of the system that runs in protected mode and "
+"mediates access by all user programs to the underlying hardware (e.g., CPU, "
+"disks, terminals, network links) and software constructs (e.g., filesystem, "
+"network protocols).  The kernel provides the basic system facilities; it "
+"creates and manages processes, and provides functions to access the "
+"filesystem and communication facilities.  These functions, called _system "
+"calls_ appear to user processes as library subroutines.  These system calls "
+"are the only interface that processes have to these facilities.  Details of "
+"the system-call mechanism are given in Chapter 3, as are descriptions of "
+"several kernel mechanisms that do not execute as the direct result of a "
+"process doing a system call."
+msgstr ""
+"_Ядро_ является частью системы, которая работает в защищенном режиме и "
+"управляет доступом всех пользовательских программ к низкоуровнему "
+"аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) "
+"и программным компонентам (к примеру, файловой системе, сетевым протоколам). "
+"Ядро предоставляет основные подсистемы; оно создает процессы и управляет "
+"ими, предоставляет функции для доступа к файловой системе и службам связи. "
+"Такие функции, называемые _системными вызовами_, доступны процессам "
+"пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются "
+"единственным способом доступа к этим подсистемам. Подробно механизм работы "
+"системных вызовов дается в Главе 3, вместе с описанием некоторых механизмов "
+"ядра, работа которых не является прямым результатом процесса, выполняющего "
+"системный вызов."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:84
+msgid ""
+"A _kernel_ in traditional operating-system terminology, is a small nucleus "
+"of software that provides only the minimal facilities necessary for "
+"implementing additional operating-system services.  In contemporary research "
+"operating systems -- such as 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]], and the V Kernel crossref:design-44bsd[biblio-cheriton, [Cheriton, "
+"1988]] -- this division of functionality is more than just a logical one.  "
+"Services such as filesystems and networking protocols are implemented as "
+"client application processes of the nucleus or kernel."
+msgstr ""
+"_Ядро_, по традиционной терминологии операционных систем, является маленьким "
+"куском программного обеспечения, которое предоставляет только минимальный "
+"набор подсистем, необходимый для реализации дополнительных служб "
+"операционной системы. В современных исследовательских операционных системах "
+"— таких, как 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]]  - такое разделение "
+"функциональности выполнено не только логически. Такие службы, как файловые "
+"системы и сетевые протоколы, выполнены в виде прикладных процессов клиентов "
+"ядра или микроядра."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:93
+msgid ""
+"The 4.4BSD kernel is not partitioned into multiple processes.  This basic "
+"design decision was made in the earliest versions of UNIX.  The first two "
+"implementations by Ken Thompson had no memory mapping, and thus made no "
+"hardware-enforced distinction between user and kernel space "
+"crossref:design-44bsd[biblio-ritchie, [Ritchie, 1988]].  A message-passing "
+"system could have been implemented as readily as the actually implemented "
+"model of kernel and user processes.  The monolithic kernel was chosen for "
+"simplicity and performance.  And the early kernels were small; the inclusion "
+"of facilities such as networking into the kernel has increased its size.  "
+"The current trend in operating-systems research is to reduce the kernel size "
+"by placing such services in user space."
+msgstr ""
+"Ядро 4.4BSD не разбивается на несколько процессов. Это основополагающее "
+"архитектурное решение было сделано в самых ранних версиях UNIX. В первых "
+"двух реализациях Кена Томпсона (Ken Thompson) не было отображаемой памяти, и "
+"поэтому не было аппаратного различия между адресным пространством "
+"пользователя и ядра crossref:design-44bsd[biblio-ritchie, [Ritchie, 1988]]. "
+"Могла бы быть придумана система обмена сообщениями как реально реализуемая "
+"модель процессов ядра и пользователя. Для простоты и увеличения "
+"производительности было выбрано монолитное ядро. К тому же ранние ядра были "
+"маленькими; включение таких подсистем, как сетевые коммуникации, в ядро "
+"увеличило его размер. Современные тенденции в области операционных систем "
+"сводятся к уменьшению размера ядра за счет перевода таких служб в "
+"пользовательское адресное пространство."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:97
+msgid ""
+"Users ordinarily interact with the system through a command-language "
+"interpreter, called a _shell_, and perhaps through additional user "
+"application programs.  Such programs and the shell are implemented with "
+"processes.  Details of such programs are beyond the scope of this book, "
+"which instead concentrates almost exclusively on the kernel."
+msgstr ""
+"Пользователи обычно общаются с системой через интерпретатор языка команд, "
+"называемый оболочкой (_shell_), и, может быть, через дополнительные "
+"прикладные пользовательские программы. Такие программы и оболочка "
+"реализованы в виде процессов. Подробное описание таких программ выходит за "
+"рамки этой книги, которая практически полностью посвящена работе ядра."
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:100
+msgid ""
+"Sections 2.3 and 2.4 describe the services provided by the 4.4BSD kernel, "
+"and give an overview of the latter's design.  Later chapters describe the "
+"detailed design and implementation of these services as they appear in "
+"4.4BSD."
+msgstr ""
+"В разделах 2.3 и 2.4 описываются сервисы, предоставляемые ядром 4.4BSD, и "
+"дается обзор их архитектуры. Последующие главы описывают подробности "
+"архитектуры и реализации этих сервисов в 4.4BSD."
+
+#. type: Title ===
+#: documentation/content/en/books/design-44bsd/_index.adoc:102
+#, no-wrap
+msgid "Kernel Organization"
+msgstr "Организация ядра"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:105
+msgid ""
+"In this section, we view the organization of the 4.4BSD kernel in two ways:"
+msgstr ""
+"В этом разделе мы рассматриваем организацию ядра 4.4BSD с двух точек зрения:"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:108
+msgid ""
+"As a static body of software, categorized by the functionality offered by "
+"the modules that make up the kernel"
+msgstr ""
+"Как статический блок программного обеспечения, категоризуемый по "
+"функциональности модулей, составляющих ядро"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:109
+msgid ""
+"By its dynamic operation, categorized according to the services provided to "
+"users"
+msgstr ""
+"В его динамике, категоризуемой по услугам, предоставляемым пользователям"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:112
+msgid ""
+"The largest part of the kernel implements the system services that "
+"applications access through system calls.  In 4.4BSD, this software has been "
+"organized according to the following:"
+msgstr ""
+"Самая большая часть ядра реализует системные услуги, к которым приложения "
+"обращаются через системные вызовы. В 4.4BSD это программное обеспечение "
+"организуется по следующим принципам:"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:114
+msgid ""
+"Basic kernel facilities: timer and system-clock handling, descriptor "
+"management, and process management"
+msgstr ""
+"Базовые подсистемы ядра: обработка таймеров и системного таймера, управление "
+"дескрипторами и процессами"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:115
+msgid "Memory-management support: paging and swapping"
+msgstr "Поддержка управления памятью: подкачка и выгрузка"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:116
+msgid ""
+"Generic system interfaces: the I/O, control, and multiplexing operations "
+"performed on descriptors"
+msgstr ""
+"Общесистемные интерфейсы: ввод/вывод, управление и мультиплексирование "
+"операций, выполняемых над дескрипторами"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:117
+msgid ""
+"The filesystem: files, directories, pathname translation, file locking, and "
+"I/O buffer management"
+msgstr ""
+"Файловая система: файлы, каталоги, преобразование маршрутов, блокировка "
+"файлов и управление буфером ввода/вывода"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:118
+msgid ""
+"Terminal-handling support: the terminal-interface driver and terminal line "
+"disciplines"
+msgstr ""
+"Поддержка работы с терминалами: драйвер терминального интерфейса и режимы "
+"работы терминального канала"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:119
+msgid "Interprocess-communication facilities: sockets"
+msgstr "Подсистемы межпроцессного взаимодействия: сокеты"
+
+#. type: Plain text
+#: documentation/content/en/books/design-44bsd/_index.adoc:120
+msgid ""
+"Support for network communication: communication protocols and generic "
+"network facilities, such as routing"
+msgstr ""
+"Поддержка сетевых коммуникаций: коммуникационные протоколы и общесетевые "
+"подсистемы, такие, как маршрутизация"
+
+#. type: Block title
+#: documentation/content/en/books/design-44bsd/_index.adoc:121
+#, no-wrap
+msgid "Machine-independent software in the 4.4BSD kernel"
+msgstr "Машинно-независимое программное обеспечение в ядре 4.4BSD"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:125
+#: documentation/content/en/books/design-44bsd/_index.adoc:165
+#, no-wrap
+msgid "Category"
+msgstr "Категория"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:125
+#: documentation/content/en/books/design-44bsd/_index.adoc:165
+#, no-wrap
+msgid "Lines of code"
+msgstr "Строк кода"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:126
+#: documentation/content/en/books/design-44bsd/_index.adoc:166
+#, no-wrap
+msgid "Percentage of kernel"
+msgstr "Процент от строк ядра"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:126
+#, no-wrap
+msgid "headers"
+msgstr "заголовки"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:126
+#, no-wrap
+msgid "9,393"
+msgstr "9,393"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:127
+#, no-wrap
+msgid "4.6"
+msgstr "4.6"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:127
+#, no-wrap
+msgid "initialization"
+msgstr "инициализация"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:127
+#, no-wrap
+msgid "1,107"
+msgstr "1,107"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:128
+#, no-wrap
+msgid "0.6"
+msgstr "0.6"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:128
+#, no-wrap
+msgid "kernel facilities"
+msgstr "подсистемы ядра"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:128
+#, no-wrap
+msgid "8,793"
+msgstr "8,793"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:129
+#, no-wrap
+msgid "4.4"
+msgstr "4.4"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:129
+#, no-wrap
+msgid "generic interfaces"
+msgstr "универсальные интерфейсы"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:129
+#, no-wrap
+msgid "4,782"
+msgstr "4,782"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:130
+#, no-wrap
+msgid "2.4"
+msgstr "2.4"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:130
+#, no-wrap
+msgid "interprocess communication"
+msgstr "межпроцессное взаимодействие"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:130
+#, no-wrap
+msgid "4,540"
+msgstr "4,540"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:131
+#: documentation/content/en/books/design-44bsd/_index.adoc:136
+#, no-wrap
+msgid "2.2"
+msgstr "2.2"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:131
+#, no-wrap
+msgid "terminal handling"
+msgstr "работа с терминалом"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:131
+#, no-wrap
+msgid "3,911"
+msgstr "3,911"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:132
+#, no-wrap
+msgid "1.9"
+msgstr "1.9"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:132
+#: documentation/content/en/books/design-44bsd/_index.adoc:169
+#, no-wrap
+msgid "virtual memory"
+msgstr "Виртуальная память"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:132
+#, no-wrap
+msgid "11,813"
+msgstr "11,813"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:133
+#, no-wrap
+msgid "5.8"
+msgstr "5.8"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:133
+#, no-wrap
+msgid "vnode management"
+msgstr "управление vnode"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:133
+#, no-wrap
+msgid "7,954"
+msgstr "7,954"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:134
+#, no-wrap
+msgid "3.9"
+msgstr "3.9"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:134
+#, no-wrap
+msgid "filesystem naming"
+msgstr "имена в файловой системы"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:134
+#, no-wrap
+msgid "6,550"
+msgstr "6,550"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:135
+#, no-wrap
+msgid "3.2"
+msgstr "3.2"
+
+#. type: Table
+#: documentation/content/en/books/design-44bsd/_index.adoc:135
+#, no-wrap
+msgid "fast filestore"
+msgstr "быстрое хранилище файлов"
+
*** 3125 LINES SKIPPED ***