Page MenuHomeFreeBSD
Files F157009373

D56936.diff
No OneTemporary
Actions

D56936.diff
View Options

diff --git a/documentation/content/ru/books/design-44bsd/_index.adoc b/documentation/content/ru/books/design-44bsd/_index.adoc
--- a/documentation/content/ru/books/design-44bsd/_index.adoc
+++ b/documentation/content/ru/books/design-44bsd/_index.adoc
@@ -63,7 +63,7 @@
Ядро 4.4BSD предоставляет четыре базовых подсистемы: процессы, файловую систему, коммуникации и запуск системы. Этот раздел перечисляет, в каком месте этой книги описана каждая из этих подсистем.
. Процессы образуют поток управления в адресном пространстве. Механизмы создания, завершения и другие управляющие процессы описаны в Главе 4. Для каждого процесса система мультиплексирует отдельное виртуальное адресное пространство; такое управление памятью обсуждается в Главе 5.
-. Механизм доступа пользователя к файловой системе и устройствам один и тот же; общие аспекты обсуждаются в Главе 6. Файловая система является набором именованных файлов, организованных в древовидную иерархию каталогов, а операции по управлению ими представлены в Главе 7. Файлы располагаются на таких физических носителях, как диски. 4.4BSD поддерживает несколько типов организации данных на диске, как описано далее в Главе 8. Доступ к файлам на удаленных машинах является предметом обсуждения в Главе 9. Для доступа к системе Терминалы используются терминалы; их функционированию посвящена глава 10.
+. Механизм доступа пользователя к файловой системе и устройствам один и тот же; общие аспекты обсуждаются в Главе 6. Файловая система является набором именованных файлов, организованных в древовидную иерархию каталогов, а операции по управлению ими представлены в Главе 7. Файлы располагаются на таких физических носителях, как диски. 4.4BSD поддерживает несколько типов организации данных на диске, как описано далее в Главе 8. Доступ к файлам на удалённых машинах является предметом обсуждения в Главе 9. Для доступа к системе Терминалы используются терминалы; их функционированию посвящена глава 10.
. Механизмы коммуникаций, предоставляемые традиционными UNIX-системами, включают однонаправленные потоки байтов между связанными процессами (смотрите материал о конвейерах в Разделе 11.1) и извещение об исключительных событиях (смотрите материал о сигналах в Разделе 4.7). В 4.4BSD имеется также механизм межпроцессного взаимодействия между процессами. Этот механизм, описываемый в Главе 11, использует способы доступа, отличающиеся от тех, что используются в файловой системе, но, как только соединение установлено, процесс может работать с ним, как будто это конвейер. Имеется и механизм работы с сетью, описываемый в Главе 12, который обычно используется как слой ниже механизма IPC. В Главе 13 даётся детальное описание конкретной реализации механизма работы с сетью.
. В любой операционной системе присутствуют вопросы управления, такие, как её запуск. Запуск и вопросы управления обсуждаются в Главе 14.
@@ -71,7 +71,7 @@
==== Ядро
-_Ядро_ является частью системы, которая работает в защищенном режиме и управляет доступом всех пользовательских программ к низкоуровнему аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) и программным компонентам (к примеру, файловой системе, сетевым протоколам). Ядро предоставляет основные подсистемы; оно создает процессы и управляет ими, предоставляет функции для доступа к файловой системе и службам связи. Такие функции, называемые _системными вызовами_, доступны процессам пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются единственным способом доступа к этим подсистемам. Подробно механизм работы системных вызовов даётся в Главе 3, вместе с описанием некоторых механизмов ядра, работа которых не является прямым результатом процесса, выполняющего системный вызов.
+_Ядро_ является частью системы, которая работает в защищенном режиме и управляет доступом всех пользовательских программ к низкоуровнему аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) и программным компонентам (к примеру, файловой системе, сетевым протоколам). Ядро предоставляет основные подсистемы; оно создаёт процессы и управляет ими, предоставляет функции для доступа к файловой системе и службам связи. Такие функции, называемые _системными вызовами_, доступны процессам пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются единственным способом доступа к этим подсистемам. Подробно механизм работы системных вызовов даётся в Главе 3, вместе с описанием некоторых механизмов ядра, работа которых не является прямым результатом процесса, выполняющего системный вызов.
_Ядро_, по традиционной терминологии операционных систем, является маленьким куском программного обеспечения, которое предоставляет только минимальный набор подсистем, необходимый для реализации дополнительных служб операционной системы. В современных исследовательских операционных системах — таких как 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]] - такое разделение функциональности выполнено не только логически. Такие службы, как файловые системы и сетевые протоколы, выполнены в виде прикладных процессов клиентов ядра или микроядра.
@@ -169,21 +169,21 @@
4.4BSD поддерживает многозадачность. Каждая задача или выполняющийся поток называется _процессом_. _Контекст_ процесса 4.4BSD состоит из состояния пользовательского уровня, включая содержимое его адресного пространства и окружения времени выполнения, и состояния уровня ядра, в который включаются параметры планировщика задач, управляющие ресурсы и идентифицирующая информация. В контекст включается все, что используется ядром при предоставлении своих сервисов процессу. Пользователи могут создавать процессы, управлять их выполнением и получать уведомления при изменении состояния выполнения процессов. Каждому процессу назначается уникальное число, называемое _идентификатором процесса_ (PID). Это число используется ядром для идентификации процесса при сообщении пользователю об изменении его состояния, и пользователем для указания процесса в системном вызове.
-Ядро создает процесс, дублируя контекст другого процесса. Новый процесс считается _порожденным процессом_ исходного _родительского процесса_. Контекст, копируемый в ходе создания процесса, включает как состояние выполнения процесса уровня пользователя, так и системное состояние процесса, управляемое ядром. Важные компоненты состояния ядра описаны в Главе 4.
+Ядро создаёт процесс, дублируя контекст другого процесса. Новый процесс считается _порождённым процессом_ исходного _родительского процесса_. Контекст, копируемый в ходе создания процесса, включает как состояние выполнения процесса уровня пользователя, так и системное состояние процесса, управляемое ядром. Важные компоненты состояния ядра описаны в Главе 4.
[[fig-process-lifecycle]]
.Жизненный цикл процесса
image:fig1.png[Жизненный цикл процесса]
-Жизненный цикл процесса изображен на рисунке crossref:design-44bsd[fig-process-lifecycle,Жизненный цикл процесса]. Процесс может создать новый процесс, который является копией исходного процесса с помощью системного вызова _fork_. Возврат из вызова _fork_ происходит два раза: один раз в родительском процессе, в котором возвращаемое значение является идентификатором порожденного процесса, и второй раз в порожденном процессе, в котором возвращаемое значение равно 0. Связь родитель-потомок порождает иерархическую структуру процессов в системе. Новый процесс имеет доступ ко всем ресурсам его родителя, таким как файловые дескрипторы, состояние обработки сигналов и распределение памяти.
+Жизненный цикл процесса изображён на рисунке crossref:design-44bsd[fig-process-lifecycle,Жизненный цикл процесса]. Процесс может создать новый процесс, который является копией исходного процесса с помощью системного вызова _fork_. Возврат из вызова _fork_ происходит два раза: один раз в родительском процессе, в котором возвращаемое значение является идентификатором порождённого процесса, и второй раз в порождённом процессе, в котором возвращаемое значение равно 0. Связь родитель-потомок порождает иерархическую структуру процессов в системе. Новый процесс имеет доступ ко всем ресурсам его родителя, таким как файловые дескрипторы, состояние обработки сигналов и распределение памяти.
Хотя есть ситуации, когда процесс должен быть копией своего родителя, наиболее типичным и полезным действием является загрузка и выполнение другой программы. Процесс может заместить себя образом памяти другой программы, передавая вновь созданному образу набор параметров, при помощи системного вызова _execve_. Одним из параметров является имя файла, содержимое которого имеет формате, распознаваемый системой - это либо двоичный выполняемый файл, либо файл, который приводит к запуску указанной программы интерпретации для обработки его содержимого.
Процесс может завершить работу, выполнив системный вызов _exit_, посылающий 8-битовое значение состояния завершения своему родителю. Если процесс хочет передать родительскому процессу информацию, превышающую один байт, он должен либо создать канал межпроцессных коммуникаций при помощи конвейеров или сокетов, или при помощи промежуточного файла. Коммуникации между процессами подробно обсуждаются в Главе 11.
-Процесс может приостановить выполнение до тех пор, пока не завершит работу любой из порожденных им процессов, при помощи системного вызова _wait_, который возвращает PID и статус завершения выполненного дочернего процесса. Родительский процесс может быть настроен на получение сигнала в случае, когда порожденный процесс завершает работу или аварийно прекращает выполнение. При помощи системного вызова _wait4_ родитель может получить информацию о событии, приведшем к завершению порожденного процесса и о ресурсах, использованных процессом за время его работы. Если процесс становится сиротой из-за того, что процесс, его породивший, завершил работу до окончания работы потомка, то ядро перенаправляет состояние завершения порожденного процесса особому системному процессу _init_: обратитесь к разделам 3.1 и 14.6).
+Процесс может приостановить выполнение до тех пор, пока не завершит работу любой из порождённых им процессов, при помощи системного вызова _wait_, который возвращает PID и статус завершения выполненного дочернего процесса. Родительский процесс может быть настроен на получение сигнала в случае, когда порождённый процесс завершает работу или аварийно прекращает выполнение. При помощи системного вызова _wait4_ родитель может получить информацию о событии, приведшем к завершению порождённого процесса и о ресурсах, использованных процессом за время его работы. Если процесс становится сиротой из-за того, что процесс, его породивший, завершил работу до окончания работы потомка, то ядро перенаправляет состояние завершения порождённого процесса особому системному процессу _init_: обратитесь к разделам 3.1 и 14.6).
-Подробное описание того, как ядро создает и уничтожает процессы, даётся в Главе 5.
+Подробное описание того, как ядро создаёт и уничтожает процессы, даётся в Главе 5.
Планирование выполнения процессов осуществляется согласно параметру _приоритетности процесса_. Этот приоритет управляется алгоритмом планирования задач в ядре. Пользователи могут влиять на выполнение процесса, задавая этот параметр (_nice_), который влияет на суммарный приоритет, но ограничен использованием ресурсов CPU согласно алгоритму планировщика задач ядра.
@@ -205,18 +205,18 @@
Процессы организованы в _группы управления_. Группы управления используются для управления доступом к терминалам и для обеспечения передачи сигналов наборам связанных процессов. Процесс наследует группу управления от своего родительского процесса. Ядром обеспечиваются механизмы, позволяющие процессу изменять свою группу управления или группу управления своих наследников. Создание новой группы управления просто; значение, соответствующее новой группе управления, обычно является идентификатором создающего её процесса.
-Группу процессов в группе управления иногда называют _заданием_ и оно управляется высокоуровневым системным программным обеспечением, таким как командный процессор. Типичным примером задания, созданного командным процессором, является _конвейер_ из нескольких связанных процессов, так что выходной поток первого процесса является входным потоком для второго, выходной поток второго процесса является входным потоком для третьего, и так далее. Командный процессор создает такое задание, порождая процесс для каждого участка конвейера, а затем помещая все эти процессы в отдельную группу обработки.
+Группу процессов в группе управления иногда называют _заданием_ и оно управляется высокоуровневым системным программным обеспечением, таким как командный процессор. Типичным примером задания, созданного командным процессором, является _конвейер_ из нескольких связанных процессов, так что выходной поток первого процесса является входным потоком для второго, выходной поток второго процесса является входным потоком для третьего, и так далее. Командный процессор создаёт такое задание, порождая процесс для каждого участка конвейера, а затем помещая все эти процессы в отдельную группу обработки.
Пользовательский процесс может послать сигнал как всем процессам в группе управления, так и конкретному процессу. Процесс в заданной группе управления может получать программные прерывания, отражающиеся на группе, приводящие к приостановке или продолжению выполнения, или к прерыванию или завершению работы.
Терминалу ставится в соответствие идентификатор группы управления. Этот идентификатор обычно равен идентификатору группы управления, соответствующей терминалу. Управляющий заданиями командный процессор может создать несколько групп управления, связанных с одним и тем же терминалом; терминал является _управляющим терминалом_ для каждого процесса в этих группах. Процесс может выполнять чтение из дескриптора своего управляющего терминала, если только идентификатор группы управления соответствует идентификатору группы этого процесса. Если идентификаторы не совпадают, процесс будет блокирован при попытке чтения с терминала. Изменяя идентификатор группы управления терминала, командный процессор может распределять терминал между несколькими различными заданиями. Такое распределение называется _управлением заданиями_ и описывается вместе с группами управления в Разделе 4.8.
-Так же, как и наборы связанных процессов могут объединяться в группы управления, набор групп управления может быть объединен в _сеанс_. Основное назначение сеансов заключается создании изолированного окружения для процесса-даемона и порожденных им процессов, а также для объединения начального командного процессора пользователя и заданий, которые он порождает.
+Так же, как и наборы связанных процессов могут объединяться в группы управления, набор групп управления может быть объединен в _сеанс_. Основное назначение сеансов заключается создании изолированного окружения для процесса-даемона и порождённых им процессов, а также для объединения начального командного процессора пользователя и заданий, которые он порождает.
[[overview-memory-management]]
=== Управление памятью
-Каждый процесс имеет собственное адресное пространство. Адресное пространство изначально разделяется на три логических сегмента: _код_, _данные_ и _стек_. Сегмент кода доступен только для чтения и содержит машинные коды программы. Сегменты данных и стека оба доступны как для чтения, так и для записи. Сегмент данных содержит как инициализированные, так и неинициализированные области данных программы, когда как стековый сегмент представляет собой стек программы на этапе выполнения. На большинстве машин сегмент стека автоматически расширяется ядром в процессе работы программы. Процесс может расширять или уменьшать свой сегмент данных, выполняя системный вызов, когда как размер сегмента кода процесс может изменить только когда содержимое сегмента перекрывается данными файловой системы или в процессе отладки. Начальное содержимое сегментов порожденного процесса копируется из сегментов родительского процесса.
+Каждый процесс имеет собственное адресное пространство. Адресное пространство изначально разделяется на три логических сегмента: _код_, _данные_ и _стек_. Сегмент кода доступен только для чтения и содержит машинные коды программы. Сегменты данных и стека оба доступны как для чтения, так и для записи. Сегмент данных содержит как инициализированные, так и неинициализированные области данных программы, когда как стековый сегмент представляет собой стек программы на этапе выполнения. На большинстве машин сегмент стека автоматически расширяется ядром в процессе работы программы. Процесс может расширять или уменьшать свой сегмент данных, выполняя системный вызов, когда как размер сегмента кода процесс может изменить только когда содержимое сегмента перекрывается данными файловой системы или в процессе отладки. Начальное содержимое сегментов порождённого процесса копируется из сегментов родительского процесса.
Для выполнения процесса вовсе не обязательно постоянно хранить в памяти полное содержимое его адресного пространства. Если процесс обращается к области адресного пространства, которая не присутствует в оперативной памяти, то система _подгружает страницу_ с необходимой информацией в память. Когда возникает нехватка системных ресурсов, то система использует двухуровневый подход к управлению имеющимися ресурсами. Если не хватает памяти, то система будет забирать ресурсы памяти от процессов, если они давно не использовались. Если ресурсов не хватает очень сильно, то система будет прибегать к _выгрузке_ всего контекста процесса во вторичную подсистему хранения данных. _Постраничная подгрузка по требованию_ и _выгрузка_ выполняются системой абсолютно незаметно для процессов. Процесс может, однако, указать системе объём памяти, который будет использоваться, в качестве помощи.
@@ -259,8 +259,8 @@
Дескрипторы представляют низкоуровневые объекты, поддерживаемые ядром, и создаваемые системными вызовами, специфичными для каждого типа объектов. В 4.4BSD дескрипторы могут представлять три типа таких объектов: файлы, каналы и сокеты.
* _Файл_ представляет собой линейную последовательность байт, имеющую по крайней мере одно имя. Файл существует, пока все его имена не удалены и ни один из процессов не хранит его дескриптор. Процесс получает дескриптор файла, открывая имя файла посредством системного вызова _open_. Работа с устройствами ввода/вывода осуществляется как с файлами.
-* _Каналом_ является линейная последовательность байт, такая же, как файл, но используемая исключительно как поток ввода/вывода, причем однонаправленный. У канала нет имени, и поэтому он не может быть открыт при помощи _open_. Вместо этого он создается посредством системного вызова _pipe_, который возвращает два дескриптора, один из которых принимает входные данные, без искажений, без повторений и в той же самой последовательности посылаемый на другой дескриптор. Система также поддерживает именованный канал, или FIFO. FIFO имеет те же самые свойства, что и канал, за исключением того, что он располагается в файловой системе; поэтому он может быть открыт системным вызовом _open_. Процессы, которые хотят обмениваться данными, открывают FIFO: Один процесс открывает его для чтения, а другой для записи.
-* _Сокет_ является промежуточным объектом, который используется для межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит дескриптор, ссылающийся на него. Сокет создается системным вызовом _socket_, который возвращает его дескриптор. Имеется несколько типов сокетов, которые поддерживают различные коммуникационные возможности, такие, как надёжную доставку данных, сохранение последовательности передаваемых сообщений, и сохранение границ сообщений.
+* _Каналом_ является линейная последовательность байт, такая же, как файл, но используемая исключительно как поток ввода/вывода, причем однонаправленный. У канала нет имени, и поэтому он не может быть открыт при помощи _open_. Вместо этого он создаётся посредством системного вызова _pipe_, который возвращает два дескриптора, один из которых принимает входные данные, без искажений, без повторений и в той же самой последовательности посылаемый на другой дескриптор. Система также поддерживает именованный канал, или FIFO. FIFO имеет те же самые свойства, что и канал, за исключением того, что он располагается в файловой системе; поэтому он может быть открыт системным вызовом _open_. Процессы, которые хотят обмениваться данными, открывают FIFO: Один процесс открывает его для чтения, а другой для записи.
+* _Сокет_ является промежуточным объектом, который используется для межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит дескриптор, ссылающийся на него. Сокет создаётся системным вызовом _socket_, который возвращает его дескриптор. Имеется несколько типов сокетов, которые поддерживают различные коммуникационные возможности, такие, как надёжную доставку данных, сохранение последовательности передаваемых сообщений, и сохранение границ сообщений.
В системах, предшествующих 4.2BSD, каналы были реализованы в файловой системе, когда в 4.2BSD появились сокеты, то каналы были повторно реализованы как сокеты.
@@ -278,7 +278,7 @@
Каналы позволяют выводу одной программы становиться вводом другой программы без переписывания и даже перекомпоновки программ. Вместо того, чтобы дескриптор 1 (стандартный вывод) исходной программы был настроен на запись на терминал, он настраивается на входной дескриптор канала. Аналогично дескриптор 0 (стандартный ввод) принимающей программы настраивается на обращение к выводу канала, а не к клавиатуре терминала. Результирующий набор двух процессов и соединяющий канал называется _конвейером_. Конвейеры могут быть весьма большими последовательностями процессов, соединенных каналами.
-Системные вызовы _open_, _pipe_ и _socket_ порождают новые дескрипторы с наименьшим неиспользуемым номером, подходящим для дескриптора. Для того, чтобы конвейеры могли работать, должен существовать механизм для отображения таких дескрипторов в 0 и 1. Системный вызов _dup_ создает копию дескриптора, которая указывает на ту же самую запись в таблице файлов. Новый дескриптор также является наименьшим неиспользуемым, но если нужный дескриптор сначала закрыть, то _dup_ можно использовать для выполнения нужного отображения. Однако здесь требуется некоторая осторожность: если нужен дескриптор 1, а дескриптор 0 уже закрыт, то в результате получится дескриптор 0. Во избежание этой проблемы в системе имеется системный вызов _dup2_; он похож на _dup_, но воспринимает дополнительный аргумент, указывающий номер нужного дескриптора (если нужный дескриптор уже открыт, то _dup2_ его закроет перед повторным использованием).
+Системные вызовы _open_, _pipe_ и _socket_ порождают новые дескрипторы с наименьшим неиспользуемым номером, подходящим для дескриптора. Для того, чтобы конвейеры могли работать, должен существовать механизм для отображения таких дескрипторов в 0 и 1. Системный вызов _dup_ создаёт копию дескриптора, которая указывает на ту же самую запись в таблице файлов. Новый дескриптор также является наименьшим неиспользуемым, но если нужный дескриптор сначала закрыть, то _dup_ можно использовать для выполнения нужного отображения. Однако здесь требуется некоторая осторожность: если нужен дескриптор 1, а дескриптор 0 уже закрыт, то в результате получится дескриптор 0. Во избежание этой проблемы в системе имеется системный вызов _dup2_; он похож на _dup_, но воспринимает дополнительный аргумент, указывающий номер нужного дескриптора (если нужный дескриптор уже открыт, то _dup2_ его закроет перед повторным использованием).
==== Устройства
@@ -312,10 +312,10 @@
==== Поддержка нескольких файловых систем
-Вместе с распространением сетевых вычислений возникла потребность в поддержке как локальных, так и удаленных файловых систем. Для облегчения поддержки нескольких файловых систем разработчики добавили в ядро интерфейс виртуальных узлов файловой системы, или интерфейс _vnode_. Набор операций, экспортируемых через интерфейс vnode, похож на операции файловой системы, ранее поддерживаемые локальной файловой системой. Однако они могут поддерживаться широким спектром типов файловых систем:
+Вместе с распространением сетевых вычислений возникла потребность в поддержке как локальных, так и удалённых файловых систем. Для облегчения поддержки нескольких файловых систем разработчики добавили в ядро интерфейс виртуальных узлов файловой системы, или интерфейс _vnode_. Набор операций, экспортируемых через интерфейс vnode, похож на операции файловой системы, ранее поддерживаемые локальной файловой системой. Однако они могут поддерживаться широким спектром типов файловых систем:
* Локальные файловые системы, использующие диск
-* Файлы, импортируемые при помощи разнообразных протоколов удаленных файловых систем
+* Файлы, импортируемые при помощи разнообразных протоколов удалённых файловых систем
* Файловые системы CD-ROM, доступные только для чтения
* Файловые системы, предоставляющие специализированные услуги - к примеру, файловая система [.filename]#/proc#
@@ -400,13 +400,13 @@
[[overview-nfs]]
=== Сетевая файловая система
-Изначально сетевые возможности использовались для передачи данных от одной машины к другой. Позже это получило свое развитие в обеспечении подключения пользователей удаленно к другим машинам. Следующим логическим шагом было предоставление данных пользователю, а не приближение пользователя к данным - так родились сетевые файловые системы. Пользователи, работающие локально, не ощущают сетевых задержек при каждом нажатии клавиши, так что они получают более удобное рабочее окружение.
+Изначально сетевые возможности использовались для передачи данных от одной машины к другой. Позже это получило свое развитие в обеспечении подключения пользователей удалённо к другим машинам. Следующим логическим шагом было предоставление данных пользователю, а не приближение пользователя к данным - так родились сетевые файловые системы. Пользователи, работающие локально, не ощущают сетевых задержек при каждом нажатии клавиши, так что они получают более удобное рабочее окружение.
-Подключение файловой системы к локальной машине было одним из первых основных клиент-серверных приложений. _Сервер_ является удаленной машиной, которая экспортирует одну или более своих файловых систем. _Клиентом_ является локальная машина, которая импортирует эти файловые системы. С точки зрения локального клиента, смонтированные удаленные файловые системы появляются в пространстве имён дерева файлов, как любая другая локально смонтированная файловая система. Локальные клиенты могут перемещаться в каталоги на удаленной файловой системе, и могут осуществлять чтение, запись и выполнение двоичных файлов на удаленной файловой системе точно так же, как они выполняют эти операции на локальной файловой системе.
+Подключение файловой системы к локальной машине было одним из первых основных клиент-серверных приложений. _Сервер_ является удалённой машиной, которая экспортирует одну или более своих файловых систем. _Клиентом_ является локальная машина, которая импортирует эти файловые системы. С точки зрения локального клиента, смонтированные удалённые файловые системы появляются в пространстве имён дерева файлов, как любая другая локально смонтированная файловая система. Локальные клиенты могут перемещаться в каталоги на удалённой файловой системе, и могут осуществлять чтение, запись и выполнение двоичных файлов на удалённой файловой системе точно так же, как они выполняют эти операции на локальной файловой системе.
-Когда локальный клиент выполняет операцию на удаленной файловой системе, оформляется и посылается запрос к серверу. Сервер выполняет запрошенную операцию и возвращает либо запрошенную информацию, либо ошибку, почему запрос был отклонен. Для получения удовлетворительной производительности, клиент должен кэшировать данные, к которым доступ осуществляется часто. Сложность удаленных файловых систем отражается на поддержке соответствия между сервером и множеством его клиентов.
+Когда локальный клиент выполняет операцию на удалённой файловой системе, оформляется и посылается запрос к серверу. Сервер выполняет запрошенную операцию и возвращает либо запрошенную информацию, либо ошибку, почему запрос был отклонен. Для получения удовлетворительной производительности, клиент должен кэшировать данные, к которым доступ осуществляется часто. Сложность удалённых файловых систем отражается на поддержке соответствия между сервером и множеством его клиентов.
-Хотя за эти годы было разработано множество протоколов работы с удаленными файловыми системами, самой распространённой на системах UNIX является сетевая файловая система Network Filesystem (NFS), которая была спроектирована и реализована в Sun Microsystems. Ядро 4.4BSD поддерживает протокол NFS, хотя его реализация была выполнена независимо от спецификаций протокола crossref:design-44bsd[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]]
=== Терминалы
@@ -433,7 +433,7 @@
Межпроцессные коммуникации в 4.4BSD организованы в _коммуникационные домены_. К поддерживаемым на данный момент доменам относятся _локальный домен_ для взаимодействия между процессами, выполняющимися на одной и той же машине; _межсетевой домен_ для связи между процессами посредством набора протоколов TCP/IP (возможно, в сети Интернет); семейство протоколов ISO/OSI для взаимодействия между сайтами, которым нужна именно такая связь, и _домен XNS_ для коммуникаций между процессами при помощи протоколов XEROX Network Systems (XNS).
-В пределах домена соединения имеют место между конечными точками связи, также называемыми _сокетами_. Как отмечено в Разделе 2.6, системный вызов _socket_ создает сокет и возвращает дескриптор; другие системные вызовы IPC описаны в Главе 11. Каждый сокет имеет тип, определяющий его коммуникационные свойства; к ним относятся такие характеристики, как надёжность, сохранение последовательности передаваемой информации и предупреждение дублирования сообщений.
+В пределах домена соединения имеют место между конечными точками связи, также называемыми _сокетами_. Как отмечено в Разделе 2.6, системный вызов _socket_ создаёт сокет и возвращает дескриптор; другие системные вызовы IPC описаны в Главе 11. Каждый сокет имеет тип, определяющий его коммуникационные свойства; к ним относятся такие характеристики, как надёжность, сохранение последовательности передаваемой информации и предупреждение дублирования сообщений.
с каждым сокетом связан некоторый _коммуникационный протокол_. Этот протокол обеспечивает выполнение операций, требуемых сокету, согласно его типу. Приложения могут задавать нужный протокол при создании сокета или могут разрешить системе выбрать протокол, который соответствует типу создаваемого сокета.
diff --git a/documentation/content/ru/books/design-44bsd/_index.po b/documentation/content/ru/books/design-44bsd/_index.po
--- a/documentation/content/ru/books/design-44bsd/_index.po
+++ b/documentation/content/ru/books/design-44bsd/_index.po
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: FreeBSD Documentation VERSION\n"
"POT-Creation-Date: 2024-12-29 08:29-0500\n"
-"PO-Revision-Date: 2026-03-04 20:01+0000\n"
+"PO-Revision-Date: 2026-04-05 04:45+0000\n"
"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
"documentation/booksdesign-44bsd_index/ru/>\n"
@@ -92,7 +92,7 @@
"операции по управлению ими представлены в Главе 7. Файлы располагаются на "
"таких физических носителях, как диски. 4.4BSD поддерживает несколько типов "
"организации данных на диске, как описано далее в Главе 8. Доступ к файлам на "
-"удаленных машинах является предметом обсуждения в Главе 9. Для доступа к "
+"удалённых машинах является предметом обсуждения в Главе 9. Для доступа к "
"системе Терминалы используются терминалы; их функционированию посвящена "
"глава 10."
@@ -169,7 +169,7 @@
"управляет доступом всех пользовательских программ к низкоуровнему "
"аппаратному обеспечению (к примеру, ЦПУ, дискам, терминалам, сетевым связям) "
"и программным компонентам (к примеру, файловой системе, сетевым протоколам). "
-"Ядро предоставляет основные подсистемы; оно создает процессы и управляет "
+"Ядро предоставляет основные подсистемы; оно создаёт процессы и управляет "
"ими, предоставляет функции для доступа к файловой системе и службам связи. "
"Такие функции, называемые _системными вызовами_, доступны процессам "
"пользователей в виде библиотечных подпрограмм. Эти системные вызовы являются "
@@ -1094,8 +1094,8 @@
"execution state of the process and the process's system state managed by the "
"kernel. Important components of the kernel state are described in Chapter 4."
msgstr ""
-"Ядро создает процесс, дублируя контекст другого процесса. Новый процесс "
-"считается _порожденным процессом_ исходного _родительского процесса_. "
+"Ядро создаёт процесс, дублируя контекст другого процесса. Новый процесс "
+"считается _порождённым процессом_ исходного _родительского процесса_. "
"Контекст, копируемый в ходе создания процесса, включает как состояние "
"выполнения процесса уровня пользователя, так и системное состояние процесса, "
"управляемое ядром. Важные компоненты состояния ядра описаны в Главе 4."
@@ -1124,12 +1124,12 @@
"its parent's resources, such as file descriptors, signal-handling status, "
"and memory layout."
msgstr ""
-"Жизненный цикл процесса изображен на рисунке crossref:design-44bsd[fig-"
+"Жизненный цикл процесса изображён на рисунке crossref:design-44bsd[fig-"
"process-lifecycle,Жизненный цикл процесса]. Процесс может создать новый "
"процесс, который является копией исходного процесса с помощью системного "
"вызова _fork_. Возврат из вызова _fork_ происходит два раза: один раз в "
"родительском процессе, в котором возвращаемое значение является "
-"идентификатором порожденного процесса, и второй раз в порожденном процессе, "
+"идентификатором порождённого процесса, и второй раз в порождённом процессе, "
"в котором возвращаемое значение равно 0. Связь родитель-потомок порождает "
"иерархическую структуру процессов в системе. Новый процесс имеет доступ ко "
"всем ресурсам его родителя, таким как файловые дескрипторы, состояние "
@@ -1188,16 +1188,16 @@
"Sections 3.1 and 14.6)."
msgstr ""
"Процесс может приостановить выполнение до тех пор, пока не завершит работу "
-"любой из порожденных им процессов, при помощи системного вызова _wait_, "
+"любой из порождённых им процессов, при помощи системного вызова _wait_, "
"который возвращает PID и статус завершения выполненного дочернего процесса. "
"Родительский процесс может быть настроен на получение сигнала в случае, "
-"когда порожденный процесс завершает работу или аварийно прекращает "
+"когда порождённый процесс завершает работу или аварийно прекращает "
"выполнение. При помощи системного вызова _wait4_ родитель может получить "
-"информацию о событии, приведшем к завершению порожденного процесса и о "
+"информацию о событии, приведшем к завершению порождённого процесса и о "
"ресурсах, использованных процессом за время его работы. Если процесс "
"становится сиротой из-за того, что процесс, его породивший, завершил работу "
"до окончания работы потомка, то ядро перенаправляет состояние завершения "
-"порожденного процесса особому системному процессу _init_: обратитесь к "
+"порождённого процесса особому системному процессу _init_: обратитесь к "
"разделам 3.1 и 14.6)."
#. type: Plain text
@@ -1206,7 +1206,7 @@
"The details of how the kernel creates and destroys processes are given in "
"Chapter 5."
msgstr ""
-"Подробное описание того, как ядро создает и уничтожает процессы, даётся в "
+"Подробное описание того, как ядро создаёт и уничтожает процессы, даётся в "
"Главе 5."
#. type: Plain text
@@ -1371,7 +1371,7 @@
"процессором, является _конвейер_ из нескольких связанных процессов, так что "
"выходной поток первого процесса является входным потоком для второго, "
"выходной поток второго процесса является входным потоком для третьего, и так "
-"далее. Командный процессор создает такое задание, порождая процесс для "
+"далее. Командный процессор создаёт такое задание, порождая процесс для "
"каждого участка конвейера, а затем помещая все эти процессы в отдельную "
"группу обработки."
@@ -1429,7 +1429,7 @@
"Так же, как и наборы связанных процессов могут объединяться в группы "
"управления, набор групп управления может быть объединен в _сеанс_. Основное "
"назначение сеансов заключается создании изолированного окружения для "
-"процесса-даемона и порожденных им процессов, а также для объединения "
+"процесса-даемона и порождённых им процессов, а также для объединения "
"начального командного процессора пользователя и заданий, которые он "
"порождает."
@@ -1467,7 +1467,7 @@
"работы программы. Процесс может расширять или уменьшать свой сегмент данных, "
"выполняя системный вызов, когда как размер сегмента кода процесс может "
"изменить только когда содержимое сегмента перекрывается данными файловой "
-"системы или в процессе отладки. Начальное содержимое сегментов порожденного "
+"системы или в процессе отладки. Начальное содержимое сегментов порождённого "
"процесса копируется из сегментов родительского процесса."
#. type: Plain text
@@ -1886,7 +1886,7 @@
"_Каналом_ является линейная последовательность байт, такая же, как файл, но "
"используемая исключительно как поток ввода/вывода, причем однонаправленный. "
"У канала нет имени, и поэтому он не может быть открыт при помощи _open_. "
-"Вместо этого он создается посредством системного вызова _pipe_, который "
+"Вместо этого он создаётся посредством системного вызова _pipe_, который "
"возвращает два дескриптора, один из которых принимает входные данные, без "
"искажений, без повторений и в той же самой последовательности посылаемый на "
"другой дескриптор. Система также поддерживает именованный канал, или FIFO. "
@@ -1907,7 +1907,7 @@
msgstr ""
"_Сокет_ является промежуточным объектом, который используется для "
"межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит "
-"дескриптор, ссылающийся на него. Сокет создается системным вызовом _socket_, "
+"дескриптор, ссылающийся на него. Сокет создаётся системным вызовом _socket_, "
"который возвращает его дескриптор. Имеется несколько типов сокетов, которые "
"поддерживают различные коммуникационные возможности, такие, как надёжную "
"доставку данных, сохранение последовательности передаваемых сообщений, и "
@@ -2070,7 +2070,7 @@
"Системные вызовы _open_, _pipe_ и _socket_ порождают новые дескрипторы с "
"наименьшим неиспользуемым номером, подходящим для дескриптора. Для того, "
"чтобы конвейеры могли работать, должен существовать механизм для отображения "
-"таких дескрипторов в 0 и 1. Системный вызов _dup_ создает копию дескриптора, "
+"таких дескрипторов в 0 и 1. Системный вызов _dup_ создаёт копию дескриптора, "
"которая указывает на ту же самую запись в таблице файлов. Новый дескриптор "
"также является наименьшим неиспользуемым, но если нужный дескриптор сначала "
"закрыть, то _dup_ можно использовать для выполнения нужного отображения. "
@@ -2375,7 +2375,7 @@
"types:"
msgstr ""
"Вместе с распространением сетевых вычислений возникла потребность в "
-"поддержке как локальных, так и удаленных файловых систем. Для облегчения "
+"поддержке как локальных, так и удалённых файловых систем. Для облегчения "
"поддержки нескольких файловых систем разработчики добавили в ядро интерфейс "
"виртуальных узлов файловой системы, или интерфейс _vnode_. Набор операций, "
"экспортируемых через интерфейс vnode, похож на операции файловой системы, "
@@ -2391,7 +2391,7 @@
#: documentation/content/en/books/design-44bsd/_index.adoc:548
msgid "Files imported using a variety of remote filesystem protocols"
msgstr ""
-"Файлы, импортируемые при помощи разнообразных протоколов удаленных файловых "
+"Файлы, импортируемые при помощи разнообразных протоколов удалённых файловых "
"систем"
#. type: Plain text
@@ -3034,7 +3034,7 @@
msgstr ""
"Изначально сетевые возможности использовались для передачи данных от одной "
"машины к другой. Позже это получило свое развитие в обеспечении подключения "
-"пользователей удаленно к другим машинам. Следующим логическим шагом было "
+"пользователей удалённо к другим машинам. Следующим логическим шагом было "
"предоставление данных пользователю, а не приближение пользователя к данным - "
"так родились сетевые файловые системы. Пользователи, работающие локально, не "
"ощущают сетевых задержек при каждом нажатии клавиши, так что они получают "
@@ -3054,14 +3054,14 @@
"do these operations on a local filesystem."
msgstr ""
"Подключение файловой системы к локальной машине было одним из первых "
-"основных клиент-серверных приложений. _Сервер_ является удаленной машиной, "
+"основных клиент-серверных приложений. _Сервер_ является удалённой машиной, "
"которая экспортирует одну или более своих файловых систем. _Клиентом_ "
"является локальная машина, которая импортирует эти файловые системы. С точки "
-"зрения локального клиента, смонтированные удаленные файловые системы "
+"зрения локального клиента, смонтированные удалённые файловые системы "
"появляются в пространстве имён дерева файлов, как любая другая локально "
"смонтированная файловая система. Локальные клиенты могут перемещаться в "
-"каталоги на удаленной файловой системе, и могут осуществлять чтение, запись "
-"и выполнение двоичных файлов на удаленной файловой системе точно так же, как "
+"каталоги на удалённой файловой системе, и могут осуществлять чтение, запись "
+"и выполнение двоичных файлов на удалённой файловой системе точно так же, как "
"они выполняют эти операции на локальной файловой системе."
#. type: Plain text
@@ -3075,12 +3075,12 @@
"filesystems lies in maintaining cache consistency between the server and its "
"many clients."
msgstr ""
-"Когда локальный клиент выполняет операцию на удаленной файловой системе, "
+"Когда локальный клиент выполняет операцию на удалённой файловой системе, "
"оформляется и посылается запрос к серверу. Сервер выполняет запрошенную "
"операцию и возвращает либо запрошенную информацию, либо ошибку, почему "
"запрос был отклонен. Для получения удовлетворительной производительности, "
"клиент должен кэшировать данные, к которым доступ осуществляется часто. "
-"Сложность удаленных файловых систем отражается на поддержке соответствия "
+"Сложность удалённых файловых систем отражается на поддержке соответствия "
"между сервером и множеством его клиентов."
#. type: Plain text
@@ -3094,7 +3094,7 @@
"specification crossref:design-44bsd[biblio-macklem, [Macklem, 1994]]. The "
"NFS protocol is described in Chapter 9."
msgstr ""
-"Хотя за эти годы было разработано множество протоколов работы с удаленными "
+"Хотя за эти годы было разработано множество протоколов работы с удалёнными "
"файловыми системами, самой распространённой на системах UNIX является "
"сетевая файловая система Network Filesystem (NFS), которая была "
"спроектирована и реализована в Sun Microsystems. Ядро 4.4BSD поддерживает "
@@ -3267,7 +3267,7 @@
msgstr ""
"В пределах домена соединения имеют место между конечными точками связи, "
"также называемыми _сокетами_. Как отмечено в Разделе 2.6, системный вызов "
-"_socket_ создает сокет и возвращает дескриптор; другие системные вызовы IPC "
+"_socket_ создаёт сокет и возвращает дескриптор; другие системные вызовы IPC "
"описаны в Главе 11. Каждый сокет имеет тип, определяющий его "
"коммуникационные свойства; к ним относятся такие характеристики, как "
"надёжность, сохранение последовательности передаваемой информации и "

File Metadata

Mime Type
text/plain
Expires
Mon, May 18, 10:45 PM (13 h, 26 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
33219567
Default Alt Text
D56936.diff (75 KB)

Event Timeline