D53717.id.diff
No OneTemporary
Actions

Size

207 KB

Referenced Files

None

Subscribers

None

D53717.id.diff
View Options

	diff --git a/documentation/content/ru/books/arch-handbook/_index.adoc b/documentation/content/ru/books/arch-handbook/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/_index.adoc
	@@ -52,6 +52,6 @@

	Добро пожаловать в Руководство по архитектуре FreeBSD. Это руководство находится _в стадии разработки_ и создаётся усилиями многих участников. Многие разделы пока не написаны, а существующие могут требовать обновления. Если вы хотите помочь в работе над этим проектом, напишите на электронную почту списка рассылки {freebsd-doc}.

	-Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/[сервера загрузок FreeBSD] или одного из многочисленных зеркал extref:{handbook}mirrors/[mirror sites, mirrors].
	+Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/[сервера загрузок FreeBSD] или одного из многочисленных зеркал extref:{handbook}mirrors[mirror sites, mirrors].

	'''
	diff --git a/documentation/content/ru/books/arch-handbook/_index.po b/documentation/content/ru/books/arch-handbook/_index.po
	--- a/documentation/content/ru/books/arch-handbook/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/_index.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-08-16 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-11 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbook_index/ru/>\n"
	@@ -22,9 +22,7 @@
	#: documentation/content/en/books/arch-handbook/_index.adoc:1
	#, no-wrap
	msgid "For FreeBSD system developers. This book covers the architectural details of many important FreeBSD kernel subsystems"
	-msgstr ""
	-"Для разработчиков систем FreeBSD. В этой книге рассматриваются архитектурные "
	-"особенности многих важных подсистем ядра FreeBSD"
	+msgstr "Для разработчиков систем FreeBSD. В этой книге рассматриваются архитектурные особенности многих важных подсистем ядра FreeBSD"

	#. type: Title =
	#: documentation/content/en/books/arch-handbook/_index.adoc:1
	@@ -55,17 +53,17 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/_index.adoc:55
	msgid ""
	-"The latest version of this document is always available from the "
	-"link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be "
	+"The latest version of this document is always available from the link:"
	+"https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be "
	"downloaded in a variety of formats and compression options from the https://"
	"download.freebsd.org/doc/[FreeBSD download server] or one of the numerous "
	-"extref:{handbook}[mirror sites, mirrors]."
	+"extref:{handbook}mirrors[mirror sites, mirrors]."
	msgstr ""
	"Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/"
	"[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных "
	"форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/["
	"сервера загрузок FreeBSD] или одного из многочисленных зеркал "
	-"extref:{handbook}mirrors/[mirror sites, mirrors]."
	+"extref:{handbook}mirrors[mirror sites, mirrors]."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/_index.adoc:56
	diff --git a/documentation/content/ru/books/arch-handbook/book.adoc b/documentation/content/ru/books/arch-handbook/book.adoc
	--- a/documentation/content/ru/books/arch-handbook/book.adoc
	+++ b/documentation/content/ru/books/arch-handbook/book.adoc
	@@ -50,7 +50,7 @@

	Добро пожаловать в Руководство по архитектуре FreeBSD. Это руководство находится _в стадии разработки_ и создаётся усилиями многих участников. Многие разделы пока не написаны, а существующие могут требовать обновления. Если вы хотите помочь в работе над этим проектом, напишите на электронную почту списка рассылки {freebsd-doc}.

	-Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/[сервера загрузок FreeBSD] или одного из многочисленных зеркал extref:{handbook}mirrors/[mirror sites, mirrors].
	+Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/[сервера загрузок FreeBSD] или одного из многочисленных зеркал extref:{handbook}mirrors[mirror sites, mirrors].

	'''

	diff --git a/documentation/content/ru/books/arch-handbook/book.po b/documentation/content/ru/books/arch-handbook/book.po
	--- a/documentation/content/ru/books/arch-handbook/book.po
	+++ b/documentation/content/ru/books/arch-handbook/book.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2022-07-07 23:22-0300\n"
	-"PO-Revision-Date: 2025-08-16 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-11 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookbook/ru/>\n"
	@@ -22,9 +22,7 @@
	#: documentation/content/en/books/arch-handbook/book.adoc:1
	#, no-wrap
	msgid "For FreeBSD system developers. This book covers the architectural details of many important FreeBSD kernel subsystems"
	-msgstr ""
	-"Для разработчиков систем FreeBSD. В этой книге рассматриваются архитектурные "
	-"особенности многих важных подсистем ядра FreeBSD"
	+msgstr "Для разработчиков систем FreeBSD. В этой книге рассматриваются архитектурные особенности многих важных подсистем ядра FreeBSD"

	#. type: Title =
	#: documentation/content/en/books/arch-handbook/book.adoc:1
	@@ -59,13 +57,13 @@
	"https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be "
	"downloaded in a variety of formats and compression options from the https://"
	"download.freebsd.org/doc/[FreeBSD download server] or one of the numerous "
	-"extref:{handbook}[mirror sites, mirrors]."
	+"extref:{handbook}mirrors[mirror sites, mirrors]."
	msgstr ""
	"Актуальная версия этого документа всегда доступна на https://www.FreeBSD.org/"
	"[официальном веб-сервере FreeBSD]. Его также можно загрузить в различных "
	"форматах и с разными вариантами сжатия с https://download.freebsd.org/doc/["
	"сервера загрузок FreeBSD] или одного из многочисленных зеркал "
	-"extref:{handbook}mirrors/[mirror sites, mirrors]."
	+"extref:{handbook}mirrors[mirror sites, mirrors]."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/book.adoc:55
	diff --git a/documentation/content/ru/books/arch-handbook/boot/_index.adoc b/documentation/content/ru/books/arch-handbook/boot/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/boot/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/boot/_index.adoc
	@@ -189,7 +189,7 @@
	....

	.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-entrypoint]]
	-Этот первый блок кода является точкой входа программы. Именно сюда BIOS передаёт управление. Сначала он гарантирует, что строковые операции автоматически увеличивают указатели операндов (инструкция `cld`) footnote:[В случае сомнений мы отсылаем читателя к официальным руководствам Intel, где описана точная семантика каждой инструкции: .]. Затем, не делая предположений о состоянии сегментных регистров, он их инициализирует. Наконец, он устанавливает регистр указателя стека (`%sp`) в ($LOAD = адрес `0x7c00`), чтобы обеспечить работоспособный стек.
	+Этот первый блок кода является точкой входа программы. Именно сюда BIOS передаёт управление. Сначала он гарантирует, что строковые операции автоматически увеличивают указатели операндов (инструкция `cld`) footnote:[В случае сомнений мы отсылаем читателя к официальным руководствам Intel, где описана точная семантика каждой инструкции.]. Затем, не делая предположений о состоянии сегментных регистров, он их инициализирует. Наконец, он устанавливает регистр указателя стека (`%sp`) в ($LOAD = адрес `0x7c00`), чтобы обеспечить работоспособный стек.

	Следующий блок отвечает за перемещение и последующий переход к перемещенному коду.

	@@ -368,7 +368,7 @@
	* BIOS выполнил первоначальную инициализацию оборудования, включая POST. MBR ([.filename]#boot0#) был загружен по адресу `0x7c00` из абсолютного сектора один с диска. Управление выполнением было передано по этому адресу.
	* [.filename]#boot0# переместил себя по адресу, по которому он был скомпонован для выполнения (`0x600`), после чего выполнил переход для продолжения выполнения в соответствующем месте. В завершение, [.filename]#boot0# загрузил первый сектор диска из раздела FreeBSD по адресу `0x7c00`. Управление выполнением было передано по этому адресу.

	-[.filename]#boot1# — это следующий шаг в последовательности загрузки. Это первая из трех стадий загрузки. Обратите внимание, что до сих пор мы работали исключительно с секторами диска. Действительно, BIOS загружает самый первый сектор, а [.filename]#boot0# загружает первый сектор раздела FreeBSD. Обе загрузки происходят по адресу `0x7c00`. Мы можем концептуально представлять эти секторы диска как содержащие файлы [.filename]#boot0# и [.filename]#boot1#, соответственно, но на самом деле это не совсем верно для [.filename]#boot1#. Строго говоря, в отличие от [.filename]#boot0#, [.filename]#boot1# не является частью загрузочных блоков footnote:[Файл /boot/boot1 существует, но он не записывается в начало раздела FreeBSD. Вместо этого он объединяется с boot2, формируя файл boot, который записывается в начало раздела FreeBSD и считывается во время загрузки.]. Вместо этого, единый полноценный файл [.filename]#boot# ([.filename]#/boot/boot#) в итоге записывается на диск. Этот файл представляет собой комбинацию [.filename]#boot1#, [.filename]#boot2# и `Boot Extender` (или BTX). Этот единый файл превышает размер одного сектора (больше 512 байт). К счастью, [.filename]#boot1# занимает _ровно_ первые 512 байт этого файла, поэтому, когда [.filename]#boot0# загружает первый сектор раздела FreeBSD (512 байт), он фактически загружает [.filename]#boot1# и передает ему управление.
	+[.filename]#boot1# — это следующий шаг в последовательности загрузки. Это первая из трех стадий загрузки. Обратите внимание, что до сих пор мы работали исключительно с секторами диска. Действительно, BIOS загружает самый первый сектор, а [.filename]#boot0# загружает первый сектор раздела FreeBSD. Обе загрузки происходят по адресу `0x7c00`. Мы можем концептуально представлять эти секторы диска как содержащие файлы [.filename]#boot0# и [.filename]#boot1#, соответственно, но на самом деле это не совсем верно для [.filename]#boot1#. Строго говоря, в отличие от [.filename]#boot0#, [.filename]#boot1# не является частью загрузочных блоков footnote:[Файл /boot/boot1 существует, но он не записывается в начало раздела FreeBSD. Вместо этого он объединяется с boot2, формируя файл boot, который записывается в начало раздела FreeBSD и считывается во время загрузки.]. Вместо этого, единый полноценный файл [.filename]#boot# ([.filename]#/boot/boot#) в итоге записывается на диск. Этот файл представляет собой комбинацию [.filename]#boot1#, [.filename]#boot2# и `Boot Extender` (или BTX). Этот единый файл превышает размер одного сектора (больше 512 байт). К счастью, [.filename]#boot1# занимает _ровно_ первые 512 байт этого файла, поэтому, когда [.filename]#boot0# загружает первый сектор раздела FreeBSD (512 байт), он фактически загружает [.filename]#boot1# и передаёт ему управление.

	Основная задача [.filename]#boot1# — загрузить следующий этап загрузки. Этот следующий этап несколько сложнее. Он состоит из сервера под названием "Boot Extender" (BTX) и клиента под названием [.filename]#boot2#. Как мы увидим, последний этап загрузки, [.filename]#loader#, также является клиентом сервера BTX.

	@@ -528,7 +528,7 @@

	Начиная с адреса `0x9000` находится начало сервера BTX, и сразу за ним следует клиент [.filename]#boot2#. Сервер BTX действует как ядро и выполняется в защищённом режиме с наивысшим уровнем привилегий. В отличие от этого, клиенты BTX (например, [.filename]#boot2#) выполняются в пользовательском режиме. Мы увидим, как это реализовано, в следующем разделе. Код после вызова `nread` находит начало [.filename]#boot2# в буфере памяти и копирует его по адресу `0xc000`. Это связано с тем, что сервер BTX размещает [.filename]#boot2# для выполнения в сегменте, начинающемся с `0xa000`. Мы подробно рассмотрим это в следующем разделе.

	-Последний блок кода в [.filename]#boot1# разрешает доступ к памяти выше 1MB footnote:[Это необходимо по историческим причинам. Заинтересованные читатели могут обратиться к .] и завершается переходом к начальной точке сервера BTX:
	+Последний блок кода в [.filename]#boot1# разрешает доступ к памяти выше 1MB footnote:[Это необходимо по историческим причинам.] и завершается переходом к начальной точке сервера BTX:

	[.programlisting]
	....
	@@ -851,7 +851,7 @@
	[[boot2]]
	== Этап загрузки boot2

	-`boot2` определяет важную структуру, `struct bootinfo`. Эта структура инициализируется `boot2` и передается загрузчику, а затем ядру. Некоторые узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта структура, среди прочей информации, содержит имя файла ядра, геометрию жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, доступную физическую память, указатель `envp` и т.д. Ее определение выглядит так:
	+`boot2` определяет важную структуру, `struct bootinfo`. Эта структура инициализируется `boot2` и передаётся загрузчику, а затем ядру. Некоторые узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта структура, среди прочей информации, содержит имя файла ядра, геометрию жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, доступную физическую память, указатель `envp` и т.д. Ее определение выглядит так:

	[.programlisting]
	....
	@@ -906,7 +906,7 @@
	[[boot-kernel]]
	== Инициализация ядра

	-Давайте рассмотрим команду, которая компонует ядро. Это поможет определить точное местоположение, где загрузчик передает выполнение ядру. Это местоположение является фактической точкой входа ядра. Данная команда теперь исключена из [.filename]#sys/conf/Makefile.i386#. Интересующее нас содержимое можно найти в [.filename]#/usr/obj/usr/src/i386.i386/sys/GENERIC/#.
	+Давайте рассмотрим команду, которая компонует ядро. Это поможет определить точное местоположение, где загрузчик передаёт выполнение ядру. Это местоположение является фактической точкой входа ядра. Данная команда теперь исключена из [.filename]#sys/conf/Makefile.i386#. Интересующее нас содержимое можно найти в [.filename]#/usr/obj/usr/src/i386.i386/sys/GENERIC/#.

	[.programlisting]
	....
	@@ -1193,7 +1193,7 @@
	}
	....

	-Хотя фреймворк sysinit описан в link:/books/developers-handbook[Руководстве разработчика], я рассмотрю его внутреннее устройство.
	+Хотя фреймворк sysinit описан в extref:{developers-handbook}[Руководстве разработчика], я рассмотрю его внутреннее устройство.

	Каждый объект инициализации системы (объект sysinit) создается путем вызова макроса SYSINIT(). Возьмем, к примеру, объект sysinit `announce`. Этот объект выводит сообщение об авторских правах:

	diff --git a/documentation/content/ru/books/arch-handbook/boot/_index.po b/documentation/content/ru/books/arch-handbook/boot/_index.po
	--- a/documentation/content/ru/books/arch-handbook/boot/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/boot/_index.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-07-02 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookboot_index/ru/>\n"
	@@ -92,8 +92,8 @@
	"allows the HOST OS to communicate details about what to boot that go beyond "
	"a simple partition as was possible in the past. But UEFI is more relevant "
	"than the CSM these days. The example that follows shows booting an x86 "
	-"computer from an MBR-partitioned hard drive with the FreeBSD "
	-"[.filename]#boot0# multi-boot loader stored in the very first sector. That "
	+"computer from an MBR-partitioned hard drive with the FreeBSD [."
	+"filename]#boot0# multi-boot loader stored in the very first sector. That "
	"boot code starts the FreeBSD three-stage boot process."
	msgstr ""
	"Процесс загрузки — это операция, крайне зависимая от оборудования. Не только "
	@@ -101,9 +101,9 @@
	"существовать различные типы загрузки в рамках одной архитектуры. Например, "
	"список файлов в каталоге [.filename]#stand# показывает большое количество "
	"кода, зависящего от архитектуры. Для каждой из поддерживаемых архитектур "
	-"существует отдельный каталог. FreeBSD поддерживает стандарт загрузки CSM ("
	-"Compatibility Support Module). Таким образом, CSM поддерживается (как с GPT, "
	-"так и с MBR разметкой), а также загрузка через UEFI (GPT полностью "
	+"существует отдельный каталог. FreeBSD поддерживает стандарт загрузки CSM "
	+"(Compatibility Support Module). Таким образом, CSM поддерживается (как с "
	+"GPT, так и с MBR разметкой), а также загрузка через UEFI (GPT полностью "
	"поддерживается, MBR — в основном). Также поддерживается загрузка файлов с "
	"ext2fs, MSDOS, UFS и ZFS. FreeBSD поддерживает функцию загрузочного "
	"окружения ZFS, которая позволяет основной ОС передавать детали о том, что "
	@@ -117,8 +117,8 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:82
	msgid ""
	"The key to understanding this process is that it is a series of stages of "
	-"increasing complexity. These stages are [.filename]#boot1#, "
	-"[.filename]#boot2#, and [.filename]#loader# (see man:boot[8] for more "
	+"increasing complexity. These stages are [.filename]#boot1#, [."
	+"filename]#boot2#, and [.filename]#loader# (see man:boot[8] for more "
	"detail). The boot system executes each stage in sequence. The last stage, "
	"[.filename]#loader#, is responsible for loading the FreeBSD kernel. Each "
	"stage is examined in the following sections."
	@@ -179,9 +179,7 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:104
	#, no-wrap
	msgid "`boot2` footnote:[This prompt will appear if the user presses a key just after selecting an OS to boot at the boot0 stage.]"
	-msgstr ""
	-"`boot2` footnote:[Это приглашение появится, если пользователь нажмет клавишу "
	-"сразу после выбора ОС для загрузки на этапе boot0.]"
	+msgstr "`boot2` footnote:[Это приглашение появится, если пользователь нажмет клавишу сразу после выбора ОС для загрузки на этапе boot0.]"

	#. type: Table
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:113
	@@ -236,8 +234,7 @@
	"Console internal video/keyboard\n"
	"(root@releng1.nyi.freebsd.org, Fri Apr 9 04:04:45 UTC 2021)\n"
	"Loading /boot/defaults/loader.conf\n"
	-"/boot/kernel/kernel text=0xed9008 data=0x117d28+0x176650 "
	-"syms=[0x8+0x137988+0x8+0x1515f8]\n"
	+"/boot/kernel/kernel text=0xed9008 data=0x117d28+0x176650 syms=[0x8+0x137988+0x8+0x1515f8]\n"
	"...."

	#. type: Table
	@@ -267,12 +264,9 @@
	"Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994\n"
	" The Regents of the University of California. All rights reserved.\n"
	"FreeBSD is a registered trademark of The FreeBSD Foundation.\n"
	-"FreeBSD 13.0-RELEASE 0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:04:45 "
	-"UTC 2021\n"
	-" root@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC "
	-"i386\n"
	-"FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11"
	-".0.1-0-g43ff75f2c3fe)\n"
	+"FreeBSD 13.0-RELEASE 0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:04:45 UTC 2021\n"
	+" root@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386\n"
	+"FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)\n"
	"...."

	#. type: Title ==
	@@ -305,8 +299,8 @@
	"битное значение `0xfffffff0`. Регистр указателя команд (также известный как "
	"Счётчик Команд) указывает на код, который должен быть выполнен процессором. "
	"Ещё один важный регистр — это 32-битный управляющий регистр `cr0`, и его "
	-"значение сразу после перезагрузки равно `0`. Один из битов ``cr0``, бит PE ("
	-"Protection Enabled, Защита Включена), указывает, работает ли процессор в 32-"
	+"значение сразу после перезагрузки равно `0`. Один из битов ``cr0``, бит PE "
	+"(Protection Enabled, Защита Включена), указывает, работает ли процессор в 32-"
	"битном защищённом режиме или 16-битном реальном режиме. Поскольку этот бит "
	"сброшен при загрузке, процессор запускается в 16-битном реальном режиме. "
	"Реальный режим означает, среди прочего, что линейные и физические адреса "
	@@ -339,9 +333,9 @@
	"jump instruction to the BIOS's POST routines."
	msgstr ""
	"BIOS (Basic Input Output System) — это микросхема на материнской плате, "
	-"которая содержит относительно небольшой объем памяти только для чтения (ROM)"
	-". Эта память включает различные низкоуровневые процедуры, специфичные для "
	-"оборудования, поставляемого с материнской платой. Процессор сначала "
	+"которая содержит относительно небольшой объем памяти только для чтения "
	+"(ROM). Эта память включает различные низкоуровневые процедуры, специфичные "
	+"для оборудования, поставляемого с материнской платой. Процессор сначала "
	"переходит по адресу 0xfffffff0, который фактически находится в памяти BIOS. "
	"Обычно по этому адресу содержится инструкция перехода к процедурам POST BIOS."

	@@ -376,15 +370,15 @@
	"MBR, or Master Boot Record. The remaining sectors on the first track are "
	"never used."
	msgstr ""
	-"Самым последним действием в POST является инструкция `INT 0x19`. Обработчик `"
	-"INT 0x19` считывает 512 байт из первого сектора загрузочного устройства в "
	+"Самым последним действием в POST является инструкция `INT 0x19`. Обработчик "
	+"`INT 0x19` считывает 512 байт из первого сектора загрузочного устройства в "
	"память по адресу `0x7c00`. Термин _первый сектор_ происходит из архитектуры "
	"жёстких дисков, где магнитная пластина разделена на множество цилиндрических "
	"дорожек. Дорожки нумеруются, и каждая дорожка разделена на несколько (обычно "
	"64) секторов. Нумерация дорожек начинается с 0, но нумерация секторов "
	"начинается с 1. Дорожка 0 находится на внешней стороне магнитной пластины, а "
	-"сектор 1, первый сектор, имеет особое назначение. Он также называется MBR ("
	-"Master Boot Record) или Главная Загрузочная Запись. Остальные секторы на "
	+"сектор 1, первый сектор, имеет особое назначение. Он также называется MBR "
	+"(Master Boot Record) или Главная Загрузочная Запись. Остальные секторы на "
	"первой дорожке не используются."

	#. type: Plain text
	@@ -407,17 +401,17 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:194
	msgid ""
	-"After control is received from the BIOS at memory address `0x7c00`, "
	-"[.filename]#boot0# starts executing. It is the first piece of code under "
	+"After control is received from the BIOS at memory address `0x7c00`, [."
	+"filename]#boot0# starts executing. It is the first piece of code under "
	"FreeBSD control. The task of [.filename]#boot0# is quite simple: scan the "
	"partition table and let the user choose which partition to boot from. The "
	"Partition Table is a special, standard data structure embedded in the MBR "
	"(hence embedded in [.filename]#boot0#) describing the four standard PC "
	-"\"partitions\". [.filename]#boot0# resides in the filesystem as "
	-"[.filename]#/boot/boot0#. It is a small 512-byte file, and it is exactly "
	-"what FreeBSD's installation procedure wrote to the hard disk's MBR if you "
	-"chose the \"bootmanager\" option at installation time. Indeed, "
	-"[.filename]#boot0# _is_ the MBR."
	+"\"partitions\". [.filename]#boot0# resides in the filesystem as [."
	+"filename]#/boot/boot0#. It is a small 512-byte file, and it is exactly what "
	+"FreeBSD's installation procedure wrote to the hard disk's MBR if you chose "
	+"the \"bootmanager\" option at installation time. Indeed, [.filename]#boot0# "
	+"_is_ the MBR."
	msgstr ""
	"После получения управления от BIOS по адресу памяти `0x7c00` начинает "
	"выполняться [.filename]#boot0#. Это первый код, который управляется FreeBSD. "
	@@ -435,8 +429,8 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:197
	msgid ""
	"As mentioned previously, we're calling the BIOS `INT 0x19` to load the MBR "
	-"([.filename]#boot0#) into memory at address `0x7c00`. The source file for "
	-"[.filename]#boot0# can be found in [.filename]#stand/i386/boot0/boot0.S# - "
	+"([.filename]#boot0#) into memory at address `0x7c00`. The source file for [."
	+"filename]#boot0# can be found in [.filename]#stand/i386/boot0/boot0.S# - "
	"which is an awesome piece of code written by Robert Nordier."
	msgstr ""
	"Как упоминалось ранее, мы вызываем прерывание BIOS `INT 0x19` для загрузки "
	@@ -451,8 +445,8 @@
	"_partition table_. It has four records of 16 bytes each, called _partition "
	"records_, which represent how the hard disk is partitioned, or, in FreeBSD's "
	"terminology, sliced. One byte of those 16 says whether a partition (slice) "
	-"is bootable or not. Exactly one record must have that flag set, otherwise "
	-"[.filename]#boot0#'s code will refuse to proceed."
	+"is bootable or not. Exactly one record must have that flag set, otherwise [."
	+"filename]#boot0#'s code will refuse to proceed."
	msgstr ""
	"Особая структура, начинающаяся со смещения `0x1be` в MBR, называется "
	"_таблицей разделов_. Она содержит четыре записи по 16 байт каждая, "
	@@ -545,26 +539,26 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:230
	msgid ""
	-"It is worth looking at the [.filename]#Makefile# for [.filename]#boot0# "
	-"([.filename]#stand/i386/boot0/Makefile#), as it defines some of the run-time "
	+"It is worth looking at the [.filename]#Makefile# for [.filename]#boot0# ([."
	+"filename]#stand/i386/boot0/Makefile#), as it defines some of the run-time "
	"behavior of [.filename]#boot0#. For instance, if a terminal connected to "
	"the serial port (COM1) is used for I/O, the macro `SIO` must be defined (`-"
	"DSIO`). `-DPXE` enables boot through PXE by pressing kbd:[F6]. "
	"Additionally, the program defines a set of _flags_ that allow further "
	-"modification of its behavior. All of this is illustrated in the "
	-"[.filename]#Makefile#. For example, look at the linker directives which "
	+"modification of its behavior. All of this is illustrated in the [."
	+"filename]#Makefile#. For example, look at the linker directives which "
	"command the linker to start the text section at address `0x600`, and to "
	"build the output file \"as is\" (strip out any file formatting):"
	msgstr ""
	-"Стоит взглянуть на [.filename]#Makefile# для [.filename]#boot0# ([.filename]#"
	-"stand/i386/boot0/Makefile#), так как он определяет некоторые аспекты "
	-"поведения [.filename]#boot0# во время выполнения. Например, если для ввода-"
	-"вывода используется терминал, подключённый к последовательному порту (COM1), "
	-"необходимо определить макрос `SIO` (`-DSIO`). `-DPXE` включает загрузку "
	-"через PXE при нажатии kbd:[F6]. Кроме того, программа определяет набор "
	-"_флагов_, которые позволяют дополнительно настроить её поведение. Всё это "
	-"проиллюстрировано в [.filename]#Makefile#. Например, обратите внимание на "
	-"директивы компоновщика, которые предписывают ему начинать секцию текста с "
	+"Стоит взглянуть на [.filename]#Makefile# для [.filename]#boot0# ([."
	+"filename]#stand/i386/boot0/Makefile#), так как он определяет некоторые "
	+"аспекты поведения [.filename]#boot0# во время выполнения. Например, если для "
	+"ввода-вывода используется терминал, подключённый к последовательному порту "
	+"(COM1), необходимо определить макрос `SIO` (`-DSIO`). `-DPXE` включает "
	+"загрузку через PXE при нажатии kbd:[F6]. Кроме того, программа определяет "
	+"набор _флагов_, которые позволяют дополнительно настроить её поведение. Всё "
	+"это проиллюстрировано в [.filename]#Makefile#. Например, обратите внимание "
	+"на директивы компоновщика, которые предписывают ему начинать секцию текста с "
	"адреса `0x600` и создавать выходной файл \"как есть\" (удаляя любое "
	"форматирование файла):"

	@@ -638,7 +632,7 @@
	"BIOS transfers control. First, it makes sure that the string operations "
	"autoincrement its pointer operands (the `cld` instruction) footnote:[When in "
	"doubt, we refer the reader to the official Intel manuals, which describe the "
	-"exact semantics for each instruction: .]. Then, as it makes no assumption "
	+"exact semantics for each instruction.]. Then, as it makes no assumption "
	"about the state of the segment registers, it initializes them. Finally, it "
	"sets the stack pointer register (`%sp`) to ($LOAD = address `0x7c00`), so we "
	"have a working stack."
	@@ -647,10 +641,10 @@
	"передаёт управление. Сначала он гарантирует, что строковые операции "
	"автоматически увеличивают указатели операндов (инструкция `cld`) footnote:[В "
	"случае сомнений мы отсылаем читателя к официальным руководствам Intel, где "
	-"описана точная семантика каждой инструкции: .]. Затем, не делая "
	-"предположений о состоянии сегментных регистров, он их инициализирует. "
	-"Наконец, он устанавливает регистр указателя стека (`%sp`) в ($LOAD = адрес "
	-"`0x7c00`), чтобы обеспечить работоспособный стек."
	+"описана точная семантика каждой инструкции.]. Затем, не делая предположений "
	+"о состоянии сегментных регистров, он их инициализирует. Наконец, он "
	+"устанавливает регистр указателя стека (`%sp`) в ($LOAD = адрес `0x7c00`), "
	+"чтобы обеспечить работоспособный стек."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:266
	@@ -701,12 +695,12 @@
	"As [.filename]#boot0# is loaded by the BIOS to address `0x7C00`, it copies "
	"itself to address `0x600` and then transfers control there (recall that it "
	"was linked to execute at address `0x600`). The source address, `0x7c00`, is "
	-"copied to register `%si`. The destination address, `0x600`, to register "
	-"`%di`. The number of words to copy, `256` (the program's size = 512 bytes), "
	+"copied to register `%si`. The destination address, `0x600`, to register `"
	+"%di`. The number of words to copy, `256` (the program's size = 512 bytes), "
	"is copied to register `%cx`. Next, the `rep` instruction repeats the "
	"instruction that follows, that is, `movsw`, the number of times dictated by "
	-"the `%cx` register. The `movsw` instruction copies the word pointed to by "
	-"`%si` to the address pointed to by `%di`. This is repeated another 255 "
	+"the `%cx` register. The `movsw` instruction copies the word pointed to by `"
	+"%si` to the address pointed to by `%di`. This is repeated another 255 "
	"times. On each repetition, both the source and destination registers, `%si` "
	"and `%di`, are incremented by one. Thus, upon completion of the 256-word "
	"(512-byte) copy, `%di` has the value `0x600`+`512`= `0x800`, and `%si` has "
	@@ -726,11 +720,11 @@
	"который указывает `%di`. Это повторяется ещё 255 раз. При каждом повторении "
	"оба регистра, исходный и конечный, `%si` и `%di`, увеличиваются на единицу. "
	"Таким образом, по завершении копирования 256 слов (512 байт), `%di` имеет "
	-"значение `0x600`+`512`= `0x800`, а `%si` — значение `0x7c00`+`512`= `0x7e00`;"
	-" таким образом, мы завершили _перемещение_ кода. С момента последнего "
	-"обновления этого документа инструкции копирования в коде изменились, поэтому "
	-"вместо movsb и stosb были введены movsw и stosw, которые копируют 2 байта (1 "
	-"слово) за одну итерацию."
	+"значение `0x600`+`512`= `0x800`, а `%si` — значение `0x7c00`+`512`= "
	+"`0x7e00`; таким образом, мы завершили _перемещение_ кода. С момента "
	+"последнего обновления этого документа инструкции копирования в коде "
	+"изменились, поэтому вместо movsb и stosb были введены movsw и stosw, которые "
	+"копируют 2 байта (1 слово) за одну итерацию."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:304
	@@ -806,8 +800,8 @@
	"This code tests the `SETDRV` bit (`0x20`) in the _flags_ variable. Recall "
	"that register `%bp` points to address location `0x800`, so the test is done "
	"to the _flags_ variable at address `0x800`-`69`= `0x7bb`. This is an "
	-"example of the type of modifications that can be done to "
	-"[.filename]#boot0#. The `SETDRV` flag is not set by default, but it can be "
	+"example of the type of modifications that can be done to [."
	+"filename]#boot0#. The `SETDRV` flag is not set by default, but it can be "
	"set in the [.filename]#Makefile#. When set, the drive number stored in the "
	"MBR is used instead of the one provided by the BIOS. We assume the "
	"defaults, and that the BIOS provided a valid drive number, so we jump to "
	@@ -828,8 +822,8 @@
	"The next block saves the drive number provided by the BIOS, and calls `putn` "
	"to print a new line on the screen."
	msgstr ""
	-"Следующий блок сохраняет номер диска, предоставленный BIOS, и вызывает `putn`"
	-" для вывода новой строки на экран."
	+"Следующий блок сохраняет номер диска, предоставленный BIOS, и вызывает "
	+"`putn` для вывода новой строки на экран."

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:341
	@@ -885,8 +879,8 @@
	"выводит на экран тип раздела для каждой из четырёх записей в таблице "
	"разделов. Каждый тип сравнивается со списком известных файловых систем "
	"операционных систем. Примерами распознаваемых типов разделов являются NTFS "
	-"(Windows(R), ID 0x7), `ext2fs` (Linux(R), ID 0x83) и, конечно же, "
	-"`ffs`/`ufs2` (FreeBSD, ID 0xa5). Реализация довольно проста."
	+"(Windows(R), ID 0x7), `ext2fs` (Linux(R), ID 0x83) и, конечно же, `ffs`/"
	+"`ufs2` (FreeBSD, ID 0xa5). Реализация довольно проста."

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:356
	@@ -958,8 +952,8 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:383
	msgid ""
	"It is important to note that the active flag for each entry is cleared, so "
	-"after the scanning, _no_ partition entry is active in our memory copy of "
	-"[.filename]#boot0#. Later, the active flag will be set for the selected "
	+"after the scanning, _no_ partition entry is active in our memory copy of [."
	+"filename]#boot0#. Later, the active flag will be set for the selected "
	"partition. This ensures that only one active partition exists if the user "
	"chooses to write the changes back to disk."
	msgstr ""
	@@ -1105,27 +1099,27 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:449
	msgid ""
	-"An interrupt is requested with number `0x1a` and argument `0` in register "
	-"`%ah`. The BIOS has a predefined set of services, requested by applications "
	+"An interrupt is requested with number `0x1a` and argument `0` in register `"
	+"%ah`. The BIOS has a predefined set of services, requested by applications "
	"as software-generated interrupts through the `int` instruction and receiving "
	"arguments in registers (in this case, `%ah`). Here, particularly, we are "
	"requesting the number of clock ticks since last midnight; this value is "
	"computed by the BIOS through the RTC (Real Time Clock). This clock can be "
	"programmed to work at frequencies ranging from 2 Hz to 8192 Hz. The BIOS "
	"sets it to 18.2 Hz at startup. When the request is satisfied, a 32-bit "
	-"result is returned by the BIOS in registers `%cx` and `%dx` (lower bytes in "
	-"`%dx`). This result (the `%dx` part) is copied to register `%di`, and the "
	-"value of the `TICKS` variable is added to `%di`. This variable resides in "
	-"[.filename]#boot0# at offset `_TICKS` (a negative value) from register `%bp` "
	+"result is returned by the BIOS in registers `%cx` and `%dx` (lower bytes in `"
	+"%dx`). This result (the `%dx` part) is copied to register `%di`, and the "
	+"value of the `TICKS` variable is added to `%di`. This variable resides in [."
	+"filename]#boot0# at offset `_TICKS` (a negative value) from register `%bp` "
	"(which, recall, points to `0x800`). The default value of this variable is "
	"`0xb6` (182 in decimal). Now, the idea is that [.filename]#boot0# "
	"constantly requests the time from the BIOS, and when the value returned in "
	"register `%dx` is greater than the value stored in `%di`, the time is up and "
	"the default selection will be made. Since the RTC ticks 18.2 times per "
	"second, this condition will be met after 10 seconds (this default behavior "
	-"can be changed in the [.filename]#Makefile#). Until this time has passed, "
	-"[.filename]#boot0# continually asks the BIOS for any user input; this is "
	-"done through `int 0x16`, argument `1` in `%ah`."
	+"can be changed in the [.filename]#Makefile#). Until this time has passed, [."
	+"filename]#boot0# continually asks the BIOS for any user input; this is done "
	+"through `int 0x16`, argument `1` in `%ah`."
	msgstr ""
	"Прерывание запрашивается с номером `0x1a` и аргументом `0` в регистре `%ah`. "
	"BIOS имеет предопределённый набор сервисов, запрашиваемых приложениями как "
	@@ -1135,18 +1129,18 @@
	"значение вычисляется BIOS через RTC (Real Time Clock). Эти часы могут быть "
	"настроены на работу с частотой от 2 Гц до 8192 Гц. BIOS устанавливает их на "
	"18,2 Гц при запуске. Когда запрос выполнен, 32-битный результат возвращается "
	-"BIOS в регистрах `%cx` и `%dx` (младшие байты в `%dx`). Этот результат ("
	-"часть `%dx`) копируется в регистр `%di`, и к `%di` добавляется значение "
	+"BIOS в регистрах `%cx` и `%dx` (младшие байты в `%dx`). Этот результат "
	+"(часть `%dx`) копируется в регистр `%di`, и к `%di` добавляется значение "
	"переменной `TICKS`. Эта переменная находится в [.filename]#boot0# по "
	"смещению `_TICKS` (отрицательное значение) от регистра `%bp` (который, "
	"напомним, указывает на `0x800`). Значение этой переменной по умолчанию — "
	"`0xb6` (182 в десятичной системе). Идея заключается в том, что [."
	"filename]#boot0# постоянно запрашивает время у BIOS, и когда значение, "
	-"возвращённое в регистре `%dx`, становится больше значения, хранящегося в "
	-"`%di`, время истекает и будет сделан выбор по умолчанию. Поскольку RTC "
	-"тикает 18,2 раза в секунду, это условие выполнится через 10 секунд (это "
	-"поведение по умолчанию можно изменить в [.filename]#Makefile#). До истечения "
	-"этого времени [.filename]#boot0# непрерывно опрашивает BIOS на предмет ввода "
	+"возвращённое в регистре `%dx`, становится больше значения, хранящегося в `"
	+"%di`, время истекает и будет сделан выбор по умолчанию. Поскольку RTC тикает "
	+"18,2 раза в секунду, это условие выполнится через 10 секунд (это поведение "
	+"по умолчанию можно изменить в [.filename]#Makefile#). До истечения этого "
	+"времени [.filename]#boot0# непрерывно опрашивает BIOS на предмет ввода "
	"пользователя; это делается через `int 0x16`, аргумент `1` в `%ah`."

	#. type: Plain text
	@@ -1246,8 +1240,8 @@
	"первого сектора слайса FreeBSD выполняется вызовом `intx13`. Мы "
	"предполагаем, что всё прошло успешно, поэтому переход к `beep` не "
	"выполняется. В частности, новый прочитанный сектор должен заканчиваться "
	-"магической последовательностью `0xaa55`. Наконец, значение в `%si` ("
	-"указатель на выбранную таблицу разделов) сохраняется для использования на "
	+"магической последовательностью `0xaa55`. Наконец, значение в `%si` "
	+"(указатель на выбранную таблицу разделов) сохраняется для использования на "
	"следующем этапе, и выполняется переход по адресу `0x7c00`, где начинается "
	"выполнение нашего следующего этапа (только что прочитанного блока)."

	@@ -1269,8 +1263,8 @@
	"MBR ([.filename]#boot0#) was loaded from absolute disk sector one to address "
	"`0x7c00`. Execution control was passed to that location."
	msgstr ""
	-"BIOS выполнил первоначальную инициализацию оборудования, включая POST. MBR (["
	-".filename]#boot0#) был загружен по адресу `0x7c00` из абсолютного сектора "
	+"BIOS выполнил первоначальную инициализацию оборудования, включая POST. MBR "
	+"([.filename]#boot0#) был загружен по адресу `0x7c00` из абсолютного сектора "
	"один с диска. Управление выполнением было передано по этому адресу."

	#. type: Plain text
	@@ -1293,13 +1287,13 @@
	msgid ""
	"[.filename]#boot1# is the next step in the boot-loading sequence. It is the "
	"first of three boot stages. Note that we have been dealing exclusively with "
	-"disk sectors. Indeed, the BIOS loads the absolute first sector, while "
	-"[.filename]#boot0# loads the first sector of the FreeBSD slice. Both loads "
	+"disk sectors. Indeed, the BIOS loads the absolute first sector, while [."
	+"filename]#boot0# loads the first sector of the FreeBSD slice. Both loads "
	"are to address `0x7c00`. We can conceptually think of these disk sectors as "
	"containing the files [.filename]#boot0# and [.filename]#boot1#, "
	-"respectively, but in reality this is not entirely true for "
	-"[.filename]#boot1#. Strictly speaking, unlike [.filename]#boot0#, "
	-"[.filename]#boot1# is not part of the boot blocks footnote:[There is a file /"
	+"respectively, but in reality this is not entirely true for [."
	+"filename]#boot1#. Strictly speaking, unlike [.filename]#boot0#, [."
	+"filename]#boot1# is not part of the boot blocks footnote:[There is a file /"
	"boot/boot1, but it is not the written to the beginning of the FreeBSD "
	"slice. Instead, it is concatenated with boot2 to form boot, which is "
	"written to the beginning of the FreeBSD slice and read at boot time.]. "
	@@ -1330,7 +1324,7 @@
	"единый файл превышает размер одного сектора (больше 512 байт). К счастью, [."
	"filename]#boot1# занимает _ровно_ первые 512 байт этого файла, поэтому, "
	"когда [.filename]#boot0# загружает первый сектор раздела FreeBSD (512 байт), "
	-"он фактически загружает [.filename]#boot1# и передает ему управление."
	+"он фактически загружает [.filename]#boot1# и передаёт ему управление."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:518
	@@ -1435,8 +1429,8 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:556
	msgid ""
	-"Next comes a loop that looks for the FreeBSD slice. Although "
	-"[.filename]#boot0# loaded [.filename]#boot1# from the FreeBSD slice, no "
	+"Next comes a loop that looks for the FreeBSD slice. Although [."
	+"filename]#boot0# loaded [.filename]#boot1# from the FreeBSD slice, no "
	"information was passed to it about this footnote:[Actually we did pass a "
	"pointer to the slice entry in register %si. However, boot1 does not assume "
	"that it was loaded by boot0 (perhaps some other MBR loaded it, and did not "
	@@ -1482,8 +1476,8 @@
	"device. This is passed on by the BIOS and preserved by the MBR. Numbers "
	"`0x80` and greater tells us that we are dealing with a hard drive, so a call "
	"is made to `nread`, where the MBR is read. Arguments to `nread` are passed "
	-"through `%si` and `%dh`. The memory address at label `part4` is copied to "
	-"`%si`. This memory address holds a \"fake partition\" to be used by "
	+"through `%si` and `%dh`. The memory address at label `part4` is copied to `"
	+"%si`. This memory address holds a \"fake partition\" to be used by "
	"`nread`. The following is the data in the fake partition:"
	msgstr ""
	"В приведённом выше коде регистр `%dl` содержит информацию о загрузочном "
	@@ -1514,8 +1508,7 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:584
	#, no-wrap
	msgid "[.filename]#stand/i386/boot2/boot1.S# [[boot-boot2-make-fake-partition]]"
	-msgstr ""
	-"[.filename]#stand/i386/boot2/boot1.S# [[boot-boot2-make-fake-partition]]"
	+msgstr "[.filename]#stand/i386/boot2/boot1.S# [[boot-boot2-make-fake-partition]]"

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:589
	@@ -1577,8 +1570,8 @@
	"also uses `xread.1`. This mechanism will be discussed in the next section."
	msgstr ""
	"Напомним, что `%si` указывает на поддельный раздел. Слово footnote:[В "
	-"контексте 16-битного реального режима слово — это 2 байта.] по смещению `0x8`"
	-" копируется в регистр `%ax`, а слово по смещению `0xa` — в `%cx`. BIOS "
	+"контексте 16-битного реального режима слово — это 2 байта.] по смещению "
	+"`0x8` копируется в регистр `%ax`, а слово по смещению `0xa` — в `%cx`. BIOS "
	"интерпретирует их как младшее 4-байтовое значение, обозначающее LBA для "
	"чтения (старшие четыре байта предполагаются нулевыми). Регистр `%bx` "
	"содержит адрес памяти, куда будет загружен MBR. Инструкция, помещающая `%cs` "
	@@ -1757,10 +1750,10 @@
	"in the MBR partition table, so a call to `nread` will effectively read "
	"sectors at the beginning of this partition. The argument passed on register "
	"`%dh` tells `nread` to read 16 disk sectors. Recall that the first 512 "
	-"bytes, or the first sector of the FreeBSD slice, coincides with the "
	-"[.filename]#boot1# program. Also recall that the file written to the "
	-"beginning of the FreeBSD slice is not [.filename]#/boot/boot1#, but "
	-"[.filename]#/boot/boot#. Let us look at the size of these files in the "
	+"bytes, or the first sector of the FreeBSD slice, coincides with the [."
	+"filename]#boot1# program. Also recall that the file written to the "
	+"beginning of the FreeBSD slice is not [.filename]#/boot/boot1#, but [."
	+"filename]#/boot/boot#. Let us look at the size of these files in the "
	"filesystem:"
	msgstr ""
	"Напомним, что в данный момент регистр `%si` указывает на запись среза "
	@@ -1792,14 +1785,14 @@
	"Both [.filename]#boot0# and [.filename]#boot1# are 512 bytes each, so they "
	"fit _exactly_ in one disk sector. [.filename]#boot2# is much bigger, "
	"holding both the BTX server and the [.filename]#boot2# client. Finally, a "
	-"file called simply [.filename]#boot# is 512 bytes larger than "
	-"[.filename]#boot2#. This file is a concatenation of [.filename]#boot1# and "
	-"[.filename]#boot2#. As already noted, [.filename]#boot0# is the file "
	-"written to the absolute first disk sector (the MBR), and [.filename]#boot# "
	-"is the file written to the first sector of the FreeBSD slice; "
	-"[.filename]#boot1# and [.filename]#boot2# are _not_ written to disk. The "
	-"command used to concatenate [.filename]#boot1# and [.filename]#boot2# into a "
	-"single [.filename]#boot# is merely `cat boot1 boot2 > boot`."
	+"file called simply [.filename]#boot# is 512 bytes larger than [."
	+"filename]#boot2#. This file is a concatenation of [.filename]#boot1# and [."
	+"filename]#boot2#. As already noted, [.filename]#boot0# is the file written "
	+"to the absolute first disk sector (the MBR), and [.filename]#boot# is the "
	+"file written to the first sector of the FreeBSD slice; [.filename]#boot1# "
	+"and [.filename]#boot2# are _not_ written to disk. The command used to "
	+"concatenate [.filename]#boot1# and [.filename]#boot2# into a single [."
	+"filename]#boot# is merely `cat boot1 boot2 > boot`."
	msgstr ""
	"Оба файла [.filename]#boot0# и [.filename]#boot1# имеют размер 512 байт "
	"каждый, поэтому они занимают _ровно_ один сектор диска. [.filename]#boot2# "
	@@ -1816,18 +1809,18 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:707
	msgid ""
	-"So [.filename]#boot1# occupies exactly the first 512 bytes of "
	-"[.filename]#boot# and, because [.filename]#boot# is written to the first "
	+"So [.filename]#boot1# occupies exactly the first 512 bytes of [."
	+"filename]#boot# and, because [.filename]#boot# is written to the first "
	"sector of the FreeBSD slice, [.filename]#boot1# fits exactly in this first "
	"sector. When `nread` reads the first 16 sectors of the FreeBSD slice, it "
	"effectively reads the entire [.filename]#boot# file footnote:[512*16=8192 "
	-"bytes, exactly the size of boot]. We will see more details about how "
	-"[.filename]#boot# is formed from [.filename]#boot1# and [.filename]#boot2# "
	-"in the next section."
	+"bytes, exactly the size of boot]. We will see more details about how [."
	+"filename]#boot# is formed from [.filename]#boot1# and [.filename]#boot2# in "
	+"the next section."
	msgstr ""
	"Итак, [.filename]#boot1# занимает ровно первые 512 байт [.filename]#boot#, "
	-"и, поскольку [.filename]#boot# записывается в первый сектор слайса FreeBSD, ["
	-".filename]#boot1# полностью помещается в этот первый сектор. Когда `nread` "
	+"и, поскольку [.filename]#boot# записывается в первый сектор слайса FreeBSD, "
	+"[.filename]#boot1# полностью помещается в этот первый сектор. Когда `nread` "
	"читает первые 16 секторов слайса FreeBSD, он фактически читает весь файл [."
	"filename]#boot# footnote:[512*16=8192 байта, ровно размер boot]. Более "
	"подробно о том, как [.filename]#boot# формируется из [.filename]#boot1# и [."
	@@ -1847,11 +1840,11 @@
	"Напомним, что `nread` использует адрес памяти `0x8c00` в качестве буфера "
	"передачи для хранения прочитанных секторов. Этот адрес выбран не случайно. "
	"Действительно, поскольку [.filename]#boot1# принадлежит первым 512 байтам, "
	-"он оказывается в диапазоне адресов `0x8c00`-`0x8dff`. Следующие 512 байт ("
	-"диапазон `0x8e00`-`0x8fff`) используются для хранения _bsdlabel_ footnote:["
	-"Исторически известной как disklabel. Если вам когда-либо было интересно, где "
	-"FreeBSD хранит эту информацию, она находится в этой области — см. "
	-"man:bsdlabel[8]]."
	+"он оказывается в диапазоне адресов `0x8c00`-`0x8dff`. Следующие 512 байт "
	+"(диапазон `0x8e00`-`0x8fff`) используются для хранения _bsdlabel_ footnote:"
	+"[Исторически известной как disklabel. Если вам когда-либо было интересно, "
	+"где FreeBSD хранит эту информацию, она находится в этой области — см. man:"
	+"bsdlabel[8]]."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:721
	@@ -1880,12 +1873,12 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:724
	msgid ""
	"The last code block of [.filename]#boot1# enables access to memory above 1MB "
	-"footnote:[This is necessary for legacy reasons. Interested readers should "
	-"see .] and concludes with a jump to the starting point of the BTX server:"
	+"footnote:[This is necessary for legacy reasons.] and concludes with a jump "
	+"to the starting point of the BTX server:"
	msgstr ""
	"Последний блок кода в [.filename]#boot1# разрешает доступ к памяти выше 1MB "
	-"footnote:[Это необходимо по историческим причинам. Заинтересованные читатели "
	-"могут обратиться к .] и завершается переходом к начальной точке сервера BTX:"
	+"footnote:[Это необходимо по историческим причинам.] и завершается переходом "
	+"к начальной точке сервера BTX:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:732
	@@ -1990,11 +1983,11 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:766
	msgid ""
	"[.filename]#boot1# loads the first 16 sectors of the FreeBSD slice into "
	-"address `0x8c00`. This 16 sectors, or 8192 bytes, is the whole file "
	-"[.filename]#boot#. The file is a concatenation of [.filename]#boot1# and "
	-"[.filename]#boot2#. [.filename]#boot2#, in turn, contains the BTX server "
	-"and the [.filename]#boot2# client. Finally, a jump is made to address "
	-"`0x9010`, the entry point of the BTX server."
	+"address `0x8c00`. This 16 sectors, or 8192 bytes, is the whole file [."
	+"filename]#boot#. The file is a concatenation of [.filename]#boot1# and [."
	+"filename]#boot2#. [.filename]#boot2#, in turn, contains the BTX server and "
	+"the [.filename]#boot2# client. Finally, a jump is made to address `0x9010`, "
	+"the entry point of the BTX server."
	msgstr ""
	"[.filename]#boot1# загружает первые 16 секторов среза FreeBSD по адресу "
	"`0x8c00`. Эти 16 секторов, или 8192 байта, представляют собой весь файл [."
	@@ -2007,15 +2000,16 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:770
	msgid ""
	"Before studying the BTX Server in detail, let us further review how the "
	-"single, all-in-one [.filename]#boot# file is created. The way "
	-"[.filename]#boot# is built is defined in its [.filename]#Makefile# "
	-"([.filename]#stand/i386/boot2/Makefile#). Let us look at the rule that "
	-"creates the [.filename]#boot# file:"
	+"single, all-in-one [.filename]#boot# file is created. The way [."
	+"filename]#boot# is built is defined in its [.filename]#Makefile# ([."
	+"filename]#stand/i386/boot2/Makefile#). Let us look at the rule that creates "
	+"the [.filename]#boot# file:"
	msgstr ""
	"Прежде чем изучать сервер BTX подробно, давайте рассмотрим, как создается "
	-"единый, всеобъемлющий файл [.filename]#boot#. Способ сборки [.filename]#boot#"
	-" определен в его [.filename]#Makefile# ([.filename]#stand/i386/boot2/"
	-"Makefile#). Рассмотрим правило, которое создает файл [.filename]#boot#:"
	+"единый, всеобъемлющий файл [.filename]#boot#. Способ сборки [."
	+"filename]#boot# определен в его [.filename]#Makefile# ([.filename]#stand/"
	+"i386/boot2/Makefile#). Рассмотрим правило, которое создает файл [."
	+"filename]#boot#:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:775
	@@ -2037,8 +2031,8 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:780
	msgid ""
	"This tells us that [.filename]#boot1# and [.filename]#boot2# are needed, and "
	-"the rule simply concatenates them to produce a single file called "
	-"[.filename]#boot#. The rules for creating [.filename]#boot1# are also quite "
	+"the rule simply concatenates them to produce a single file called [."
	+"filename]#boot#. The rules for creating [.filename]#boot1# are also quite "
	"simple:"
	msgstr ""
	"Это говорит нам, что [.filename]#boot1# и [.filename]#boot2# необходимы, и "
	@@ -2064,8 +2058,7 @@
	"\t${LD} ${LD_FLAGS} -e start --defsym ORG=${ORG1} -T ${LDSCRIPT} -o ${.TARGET} boot1.o\n"
	msgstr ""
	" boot1.out: boot1.o\n"
	-"\t${LD} ${LD_FLAGS} -e start --defsym ORG=${ORG1} -T ${LDSCRIPT} -o ${."
	-"TARGET} boot1.o\n"
	+"\t${LD} ${LD_FLAGS} -e start --defsym ORG=${ORG1} -T ${LDSCRIPT} -o ${.TARGET} boot1.o\n"

	#. type: Block title
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:790
	@@ -2077,28 +2070,28 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:799
	msgid ""
	"To apply the rule for creating [.filename]#boot1#, [.filename]#boot1.out# "
	-"must be resolved. This, in turn, depends on the existence of "
	-"[.filename]#boot1.o#. This last file is simply the result of assembling our "
	+"must be resolved. This, in turn, depends on the existence of [."
	+"filename]#boot1.o#. This last file is simply the result of assembling our "
	"familiar [.filename]#boot1.S#, without linking. Now, the rule for creating "
	"[.filename]#boot1.out# is applied. This tells us that [.filename]#boot1.o# "
	"should be linked with `start` as its entry point, and starting at address "
	-"`0x7c00`. Finally, [.filename]#boot1# is created from "
	-"[.filename]#boot1.out# applying the appropriate rule. This rule is the "
	-"[.filename]#objcopy# command applied to [.filename]#boot1.out#. Note the "
	-"flags passed to [.filename]#objcopy#: `-S` tells it to strip all relocation "
	-"and symbolic information; `-O binary` indicates the output format, that is, "
	-"a simple, unformatted binary file."
	+"`0x7c00`. Finally, [.filename]#boot1# is created from [.filename]#boot1."
	+"out# applying the appropriate rule. This rule is the [.filename]#objcopy# "
	+"command applied to [.filename]#boot1.out#. Note the flags passed to [."
	+"filename]#objcopy#: `-S` tells it to strip all relocation and symbolic "
	+"information; `-O binary` indicates the output format, that is, a simple, "
	+"unformatted binary file."
	msgstr ""
	"Для применения правила создания [.filename]#boot1# необходимо собрать [."
	"filename]#boot1.out#. Это, в свою очередь, зависит от наличия [."
	"filename]#boot1.o#. Последний файл является результатом ассемблирования "
	"нашего знакомого [.filename]#boot1.S# без компоновки. Теперь применяется "
	-"правило создания [.filename]#boot1.out#. Оно указывает, что [.filename]#boot1"
	-".o# должен быть скомпонован с точкой входа `start` и начальным адресом "
	-"`0x7c00`. Наконец, [.filename]#boot1# создается из [.filename]#boot1.out# "
	-"применением соответствующего правила. Это команда [.filename]#objcopy#, "
	-"применяемая к [.filename]#boot1.out#. Обратите внимание на флаги, "
	-"передаваемые [.filename]#objcopy#: `-S` указывает на удаление всей "
	+"правило создания [.filename]#boot1.out#. Оно указывает, что [."
	+"filename]#boot1.o# должен быть скомпонован с точкой входа `start` и "
	+"начальным адресом `0x7c00`. Наконец, [.filename]#boot1# создается из [."
	+"filename]#boot1.out# применением соответствующего правила. Это команда [."
	+"filename]#objcopy#, применяемая к [.filename]#boot1.out#. Обратите внимание "
	+"на флаги, передаваемые [.filename]#objcopy#: `-S` указывает на удаление всей "
	"информации о перемещении и символов; `-O binary` указывает формат вывода, то "
	"есть простой, неформатированный двоичный файл."

	@@ -2164,8 +2157,7 @@
	"\t${LD} ${LD_FLAGS} --defsym ORG=${ORG2} -T ${LDSCRIPT} -o ${.TARGET} ${.ALLSRC}\n"
	msgstr ""
	" boot2.out: ${BTXCRT} boot2.o sio.o ashldi3.o\n"
	-"\t${LD} ${LD_FLAGS} --defsym ORG=${ORG2} -T ${LDSCRIPT} -o ${.TARGET} ${."
	-"ALLSRC}\n"
	+"\t${LD} ${LD_FLAGS} --defsym ORG=${ORG2} -T ${LDSCRIPT} -o ${.TARGET} ${.ALLSRC}\n"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:828
	@@ -2181,8 +2173,7 @@
	" boot2.h: boot1.out\n"
	"\t${NM} -t d ${.ALLSRC} \| awk '/([0-9])+ T xread/ \\\n"
	"\t { x = $$1 - ORG1; \\\n"
	-"\t printf(\"#define XREADORG %#x\\n"
	-"\", REL1 + x) }' \\\n"
	+"\t printf(\"#define XREADORG %#x\\n\", REL1 + x) }' \\\n"
	"\t ORG1=`printf \"%d\" ${ORG1}` \\\n"
	"\t REL1=`printf \"%d\" ${REL1}` > ${.TARGET}\n"

	@@ -2253,8 +2244,8 @@
	msgid ""
	"Recall that [.filename]#boot1# was relocated (i.e., copied from `0x7c00` to "
	"`0x700`). This relocation will now make sense, because as we will see, the "
	-"BTX server reclaims some memory, including the space where "
	-"[.filename]#boot1# was originally loaded. However, the BTX server needs "
	+"BTX server reclaims some memory, including the space where [."
	+"filename]#boot1# was originally loaded. However, the BTX server needs "
	"access to [.filename]#boot1#'s `xread` function; this function, according to "
	"the output of [.filename]#boot2.h#, is at location `0x725`. Indeed, the BTX "
	"server uses the `xread` function from [.filename]#boot1#'s relocated code. "
	@@ -2272,19 +2263,19 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:868
	msgid ""
	-"The next rule directs the linker to link various files "
	-"([.filename]#ashldi3.o#, [.filename]#boot2.o# and [.filename]#sio.o#). Note "
	-"that the output file, [.filename]#boot2.out#, is linked to execute at "
	-"address `0x2000` (${ORG2}). Recall that [.filename]#boot2# will be executed "
	-"in user mode, within a special user segment set up by the BTX server. This "
	-"segment starts at `0xa000`. Also, remember that the [.filename]#boot2# "
	-"portion of [.filename]#boot# was copied to address `0xc000`, that is, offset "
	-"`0x2000` from the start of the user segment, so [.filename]#boot2# will work "
	-"properly when we transfer control to it. Next, [.filename]#boot2.bin# is "
	-"created from [.filename]#boot2.out# by stripping its symbols and format "
	-"information; boot2.bin is a _raw_ binary. Now, note that a file "
	-"[.filename]#boot2.ldr# is created as a 512-byte file full of zeros. This "
	-"space is reserved for the bsdlabel."
	+"The next rule directs the linker to link various files ([.filename]#ashldi3."
	+"o#, [.filename]#boot2.o# and [.filename]#sio.o#). Note that the output "
	+"file, [.filename]#boot2.out#, is linked to execute at address `0x2000` "
	+"(${ORG2}). Recall that [.filename]#boot2# will be executed in user mode, "
	+"within a special user segment set up by the BTX server. This segment starts "
	+"at `0xa000`. Also, remember that the [.filename]#boot2# portion of [."
	+"filename]#boot# was copied to address `0xc000`, that is, offset `0x2000` "
	+"from the start of the user segment, so [.filename]#boot2# will work properly "
	+"when we transfer control to it. Next, [.filename]#boot2.bin# is created "
	+"from [.filename]#boot2.out# by stripping its symbols and format information; "
	+"boot2.bin is a _raw_ binary. Now, note that a file [.filename]#boot2.ldr# "
	+"is created as a 512-byte file full of zeros. This space is reserved for the "
	+"bsdlabel."
	msgstr ""
	"Следующее правило указывает компоновщику на необходимость связать различные "
	"файлы ([.filename]#ashldi3.o#, [.filename]#boot2.o# и [.filename]#sio.o#). "
	@@ -2305,31 +2296,31 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:873
	msgid ""
	-"Now that we have files [.filename]#boot1#, [.filename]#boot2.bin# and "
	-"[.filename]#boot2.ldr#, only the BTX server is missing before creating the "
	-"all-in-one [.filename]#boot# file. The BTX server is located in "
	-"[.filename]#stand/i386/btx/btx#; it has its own [.filename]#Makefile# with "
	-"its own set of rules for building. The important thing to notice is that it "
	-"is also compiled as a _raw_ binary, and that it is linked to execute at "
	-"address `0x9000`. The details can be found in [.filename]#stand/i386/btx/"
	-"btx/Makefile#."
	+"Now that we have files [.filename]#boot1#, [.filename]#boot2.bin# and [."
	+"filename]#boot2.ldr#, only the BTX server is missing before creating the all-"
	+"in-one [.filename]#boot# file. The BTX server is located in [."
	+"filename]#stand/i386/btx/btx#; it has its own [.filename]#Makefile# with its "
	+"own set of rules for building. The important thing to notice is that it is "
	+"also compiled as a _raw_ binary, and that it is linked to execute at address "
	+"`0x9000`. The details can be found in [.filename]#stand/i386/btx/btx/"
	+"Makefile#."
	msgstr ""
	-"Теперь, когда у нас есть файлы [.filename]#boot1#, [.filename]#boot2.bin# и ["
	-".filename]#boot2.ldr#, осталось только добавить сервер BTX перед созданием "
	-"универсального файла [.filename]#boot#. Сервер BTX находится в [.filename]#"
	-"stand/i386/btx/btx#; у него есть собственный [.filename]#Makefile# со своим "
	-"набором правил для сборки. Важно отметить, что он также компилируется как "
	-"_сырой_ бинарный файл и линкуется для выполнения по адресу `0x9000`. "
	-"Подробности можно найти в [.filename]#stand/i386/btx/btx/Makefile#."
	+"Теперь, когда у нас есть файлы [.filename]#boot1#, [.filename]#boot2.bin# и "
	+"[.filename]#boot2.ldr#, осталось только добавить сервер BTX перед созданием "
	+"универсального файла [.filename]#boot#. Сервер BTX находится в [."
	+"filename]#stand/i386/btx/btx#; у него есть собственный [.filename]#Makefile# "
	+"со своим набором правил для сборки. Важно отметить, что он также "
	+"компилируется как _сырой_ бинарный файл и линкуется для выполнения по адресу "
	+"`0x9000`. Подробности можно найти в [.filename]#stand/i386/btx/btx/Makefile#."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:880
	msgid ""
	"Having the files that comprise the [.filename]#boot# program, the final step "
	-"is to _merge_ them. This is done by a special program called "
	-"[.filename]#btxld# (source located in [.filename]#/usr/src/usr.sbin/"
	-"btxld#). Some arguments to this program include the name of the output file "
	-"([.filename]#boot#), its entry point (`0x2000`) and its file format (raw "
	+"is to _merge_ them. This is done by a special program called [."
	+"filename]#btxld# (source located in [.filename]#/usr/src/usr.sbin/btxld#). "
	+"Some arguments to this program include the name of the output file ([."
	+"filename]#boot#), its entry point (`0x2000`) and its file format (raw "
	"binary). The various files are finally merged by this utility into the file "
	"[.filename]#boot#, which consists of [.filename]#boot1#, [.filename]#boot2#, "
	"the `bsdlabel` and the BTX server. This file, which takes exactly 16 "
	@@ -2386,9 +2377,9 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:891
	msgid ""
	"A `Task-State Segment (TSS)` is created. This is necessary because the "
	-"processor works in the _least_ privileged level when executing the client "
	-"([.filename]#boot2#), but in the _most_ privileged level when executing the "
	-"BTX server."
	+"processor works in the _least_ privileged level when executing the client ([."
	+"filename]#boot2#), but in the _most_ privileged level when executing the BTX "
	+"server."
	msgstr ""
	"Создается `Сегмент состояния задачи (TSS)`. Это необходимо, потому что "
	"процессор работает на _наименее_ привилегированном уровне при выполнении "
	@@ -2413,17 +2404,18 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:899
	msgid ""
	-"Let us now start studying the actual implementation. Recall that "
	-"[.filename]#boot1# made a jump to address `0x9010`, the BTX server's entry "
	+"Let us now start studying the actual implementation. Recall that [."
	+"filename]#boot1# made a jump to address `0x9010`, the BTX server's entry "
	"point. Before studying program execution there, note that the BTX server "
	"has a special header at address range `0x9000-0x900f`, right before its "
	"entry point. This header is defined as follows:"
	msgstr ""
	-"Приступим к изучению фактической реализации. Напомним, что [.filename]#boot1#"
	-" выполнил переход на адрес `0x9010` — точку входа сервера BTX. Прежде чем "
	-"изучать выполнение программы там, обратите внимание, что сервер BTX имеет "
	-"специальный заголовок в диапазоне адресов `0x9000-0x900f`, непосредственно "
	-"перед точкой входа. Этот заголовок определён следующим образом:"
	+"Приступим к изучению фактической реализации. Напомним, что [."
	+"filename]#boot1# выполнил переход на адрес `0x9010` — точку входа сервера "
	+"BTX. Прежде чем изучать выполнение программы там, обратите внимание, что "
	+"сервер BTX имеет специальный заголовок в диапазоне адресов `0x9000-0x900f`, "
	+"непосредственно перед точкой входа. Этот заголовок определён следующим "
	+"образом:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:915
	@@ -2475,8 +2467,8 @@
	msgstr ""
	"Обратите внимание, что первые два байта — это `0xeb` и `0xe`. В архитектуре "
	"IA-32 эти два байта интерпретируются как относительный переход за заголовок "
	-"к точке входа, поэтому теоретически [.filename]#boot1# мог бы перейти сюда ("
	-"адрес `0x9000`) вместо адреса `0x9010`. Обратите внимание, что последнее "
	+"к точке входа, поэтому теоретически [.filename]#boot1# мог бы перейти сюда "
	+"(адрес `0x9000`) вместо адреса `0x9010`. Обратите внимание, что последнее "
	"поле в заголовке BTX — это указатель на точку входа клиента ([."
	"filename]#boot2#)b2. Это поле исправляется во время компоновки."

	@@ -3042,9 +3034,9 @@
	"into the various segment registers. Five values still remain on the stack. "
	"They are popped when the `iret` instruction is executed. This instruction "
	"first pops the value that was pushed from the BTX header. This value is a "
	-"pointer to [.filename]#boot2#'s entry point. It is placed in the register "
	-"`%eip`, the instruction pointer register. Next, the segment selector for "
	-"the User Code Segment is popped and copied to register `%cs`. Remember that "
	+"pointer to [.filename]#boot2#'s entry point. It is placed in the register `"
	+"%eip`, the instruction pointer register. Next, the segment selector for the "
	+"User Code Segment is popped and copied to register `%cs`. Remember that "
	"this segment's privilege level is 3, the least privileged level. This means "
	"that we must provide values for the stack of this privilege level. This is "
	"why the processor, besides further popping the value for the EFLAGS "
	@@ -3115,7 +3107,7 @@
	"physical memory available, `envp` pointer etc. The definition for it is:"
	msgstr ""
	"`boot2` определяет важную структуру, `struct bootinfo`. Эта структура "
	-"инициализируется `boot2` и передается загрузчику, а затем ядру. Некоторые "
	+"инициализируется `boot2` и передаётся загрузчику, а затем ядру. Некоторые "
	"узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта "
	"структура, среди прочей информации, содержит имя файла ядра, геометрию "
	"жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, "
	@@ -3187,13 +3179,14 @@
	msgstr ""
	"`boot2` входит в бесконечный цикл, ожидая ввода пользователя, затем вызывает "
	"`load()`. Если пользователь ничего не нажимает, цикл прерывается по "
	-"таймауту, и `load()` загружает файл по умолчанию ([.filename]#/boot/loader#)"
	-". Функции `ino_t lookup(char filename)` и `int xfsread(ino_t inode, void "
	-"buf, size_t nbyte)` используются для чтения содержимого файла в память. [."
	-"filename]#/boot/loader# — это ELF-бинарный файл, но с заголовком ELF, перед "
	-"которым добавлена структура `struct exec` из [.filename]#a.out#. `load()` "
	-"анализирует ELF-заголовок загрузчика, загружает содержимое [.filename]#/boot/"
	-"loader# в память и передаёт управление на точку входа загрузчика:"
	+"таймауту, и `load()` загружает файл по умолчанию ([.filename]#/boot/"
	+"loader#). Функции `ino_t lookup(char *filename)` и `int xfsread(ino_t inode, "
	+"void *buf, size_t nbyte)` используются для чтения содержимого файла в "
	+"память. [.filename]#/boot/loader# — это ELF-бинарный файл, но с заголовком "
	+"ELF, перед которым добавлена структура `struct exec` из [.filename]#a.out#. "
	+"`load()` анализирует ELF-заголовок загрузчика, загружает содержимое [."
	+"filename]#/boot/loader# в память и передаёт управление на точку входа "
	+"загрузчика:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1201
	@@ -3223,8 +3216,8 @@
	"underlying mechanisms and BTX were discussed above."
	msgstr ""
	"Загрузчик также является клиентом BTX. Я не буду подробно описывать его "
	-"здесь, существует исчерпывающая man-страница, написанная Майком Смитом: "
	-"man:loader[8]. Основные механизмы и BTX были рассмотрены выше."
	+"здесь, существует исчерпывающая man-страница, написанная Майком Смитом: man:"
	+"loader[8]. Основные механизмы и BTX были рассмотрены выше."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1212
	@@ -3264,7 +3257,7 @@
	"GENERIC/#."
	msgstr ""
	"Давайте рассмотрим команду, которая компонует ядро. Это поможет определить "
	-"точное местоположение, где загрузчик передает выполнение ядру. Это "
	+"точное местоположение, где загрузчик передаёт выполнение ядру. Это "
	"местоположение является фактической точкой входа ядра. Данная команда теперь "
	"исключена из [.filename]#sys/conf/Makefile.i386#. Интересующее нас "
	"содержимое можно найти в [.filename]#/usr/obj/usr/src/i386.i386/sys/GENERIC/"
	@@ -3280,10 +3273,8 @@
	"<lots of kernel .o files>\n"
	msgstr ""
	"/usr/obj/usr/src/i386.i386/sys/GENERIC/kernel.meta:\n"
	-"ld -m elf_i386_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.i386 --build-"
	-"id=sha1 --no-warn-mismatch \\\n"
	-"--warn-common --export-dynamic --dynamic-linker /red/herring -X -o kernel "
	-"locore.o\n"
	+"ld -m elf_i386_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.i386 --build-id=sha1 --no-warn-mismatch \\\n"
	+"--warn-common --export-dynamic --dynamic-linker /red/herring -X -o kernel locore.o\n"
	"<lots of kernel .o files>\n"

	#. type: Plain text
	@@ -3319,8 +3310,8 @@
	"says that a kernel's entry point is the symbol `btext`. This symbol is "
	"defined in [.filename]#locore.s#:"
	msgstr ""
	-"говорит, что точка входа ядра — это символ `btext`. Этот символ определён в ["
	-".filename]#locore.s#:"
	+"говорит, что точка входа ядра — это символ `btext`. Этот символ определён в "
	+"[.filename]#locore.s#:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1261
	@@ -3412,11 +3403,8 @@
	"This function determines the booting method, and stores the `struct bootinfo` structure into the kernel memory."
	msgstr ""
	"Эта процедура разбирает параметры, переданные ядру при загрузке.\n"
	-"Ядро могло быть загружено тремя способами: загрузчиком (как описано выше), "
	-"старыми загрузочными блоками диска или по старой процедуре загрузки без "
	-"диска.\n"
	-"Эта функция определяет метод загрузки и сохраняет структуру `struct bootinfo`"
	-" в памяти ядра."
	+"Ядро могло быть загружено тремя способами: загрузчиком (как описано выше), старыми загрузочными блоками диска или по старой процедуре загрузки без диска.\n"
	+"Эта функция определяет метод загрузки и сохраняет структуру `struct bootinfo` в памяти ядра."

	#. type: Table
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1295
	@@ -3428,9 +3416,7 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1296
	#, no-wrap
	msgid "This function tries to find out what CPU it is running on, storing the value found in a variable `_cpu`."
	-msgstr ""
	-"Эта функция пытается определить, на каком процессоре она выполняется, "
	-"сохраняя найденное значение в переменной `_cpu`."
	+msgstr "Эта функция пытается определить, на каком процессоре она выполняется, сохраняя найденное значение в переменной `_cpu`."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1299
	@@ -3686,13 +3672,13 @@
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1396
	msgid ""
	"Sysctl `kern.hz` is the system clock tick. Additionally, these sysctls are "
	-"set by `init_param1()`: `kern.maxswzone, kern.maxbcache, kern.maxtsiz, "
	-"kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz`."
	+"set by `init_param1()`: `kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern."
	+"dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz`."
	msgstr ""
	"Sysctl `kern.hz` представляет собой такт системных часов. Кроме того, эти "
	"параметры sysctl устанавливаются функцией `init_param1()`: `kern.maxswzone, "
	-"kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, "
	-"kern.maxssiz, kern.sgrowsiz`."
	+"kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern."
	+"maxssiz, kern.sgrowsiz`."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1404
	@@ -4034,10 +4020,10 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1534
	msgid ""
	-"Although the sysinit framework is described in the link:/books/developers-"
	-"handbook[Developers' Handbook], I will discuss the internals of it."
	+"Although the sysinit framework is described in the extref:{developers-"
	+"handbook}[Developers' Handbook], I will discuss the internals of it."
	msgstr ""
	-"Хотя фреймворк sysinit описан в link:/books/developers-handbook[Руководстве "
	+"Хотя фреймворк sysinit описан в extref:{developers-handbook}[Руководстве "
	"разработчика], я рассмотрю его внутреннее устройство."

	#. type: Plain text
	@@ -4071,8 +4057,7 @@
	"\tprintf(\"%s\", (char *)data);\n"
	"}\n"
	"/* ... skipped ... */\n"
	-"SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, "
	-"copyright);\n"
	+"SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright);\n"

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1553
	@@ -4109,8 +4094,7 @@
	"/usr/include/sys/kernel.h:\n"
	" #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \\\n"
	" static struct sysinit uniquifier ## _sys_init = { \\ subsystem, \\\n"
	-" order, \\ func, \\ (ident) \\ }; \\ DATA_WSET(sysinit_set,uniquifier ##"
	-"\n"
	+" order, \\ func, \\ (ident) \\ }; \\ DATA_WSET(sysinit_set,uniquifier ##\n"
	" _sys_init);\n"

	#. type: delimited block . 4
	@@ -4197,8 +4181,8 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/boot/_index.adoc:1600
	msgid ""
	-"By defining a variable of type `struct sysinit` the content of "
	-"`set.sysinit_set` section will be \"collected\" into that variable:"
	+"By defining a variable of type `struct sysinit` the content of `set."
	+"sysinit_set` section will be \"collected\" into that variable:"
	msgstr ""
	"Определяя переменную типа `struct sysinit`, содержимое раздела `set."
	"sysinit_set` будет \"собрано\" в эту переменную:"
	@@ -4282,8 +4266,8 @@
	"0, the swapper process. The thread0 structure, mentioned before, is used to "
	"describe it."
	msgstr ""
	-"Системный планировщик sysinit определен в файле [.filename]#sys/vm/vm_glue.c#"
	-", а точка входа для этого объекта — `scheduler()`. Эта функция фактически "
	+"Системный планировщик sysinit определен в файле [.filename]#sys/vm/vm_glue."
	+"c#, а точка входа для этого объекта — `scheduler()`. Эта функция фактически "
	"представляет собой бесконечный цикл и описывает процесс с PID 0, известный "
	"как процесс swapper. Структура thread0, упомянутая ранее, используется для "
	"его описания."
	@@ -4361,8 +4345,7 @@
	"\tfr.fr_procp = &initproc;\n"
	"\terror = fork1(&thread0, &fr);\n"
	"\tif (error)\n"
	-"\t\tpanic(\"cannot fork init: %d\\n"
	-"\", error);\n"
	+"\t\tpanic(\"cannot fork init: %d\\n\", error);\n"
	"\tKASSERT(initproc->p_pid == 1, (\"create_init: initproc->p_pid != 1\"));\n"
	"\t/* divorce init's credentials from the kernel's */\n"
	"\tnewcred = crget();\n"
	@@ -4386,8 +4369,7 @@
	"\tPROC_UNLOCK(initproc);\n"
	"\tsx_xunlock(&proctree_lock);\n"
	"\tcrfree(oldcred);\n"
	-"\tcpu_fork_kthread_handler(FIRST_THREAD_IN_PROC(initproc), start_init, NULL);"
	-"\n"
	+"\tcpu_fork_kthread_handler(FIRST_THREAD_IN_PROC(initproc), start_init, NULL);\n"
	"}\n"
	"SYSINIT(init, SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL);\n"

	@@ -4398,9 +4380,9 @@
	"but does not mark it runnable. When this new process is scheduled for "
	"execution by the scheduler, the `start_init()` will be called. That "
	"function is defined in [.filename]#init_main.c#. It tries to load and exec "
	-"the [.filename]#init# binary, probing [.filename]#/sbin/init# first, then "
	-"[.filename]#/sbin/oinit#, [.filename]#/sbin/init.bak#, and finally "
	-"[.filename]#/rescue/init#:"
	+"the [.filename]#init# binary, probing [.filename]#/sbin/init# first, then [."
	+"filename]#/sbin/oinit#, [.filename]#/sbin/init.bak#, and finally [."
	+"filename]#/rescue/init#:"
	msgstr ""
	"Функция `create_init()` выделяет новый процесс, вызывая `fork1()`, но не "
	"помечает его как готовый к выполнению. Когда этот новый процесс будет "
	diff --git a/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc b/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc
	@@ -140,7 +140,7 @@
	[[driverbasics-char]]
	== Символьные устройства

	-Драйвер символьного устройства — это драйвер, который передает данные напрямую между устройством и пользовательским процессом. Это наиболее распространенный тип драйвера устройств, и в дереве исходного кода есть множество простых примеров.
	+Драйвер символьного устройства — это драйвер, который передаёт данные напрямую между устройством и пользовательским процессом. Это наиболее распространенный тип драйвера устройств, и в дереве исходного кода есть множество простых примеров.

	Этот простой пример псевдоустройства запоминает все значения, записанные в него, и может затем воспроизводить их при чтении.

	@@ -335,7 +335,7 @@

	Другие системы UNIX(R) могут поддерживать второй тип дисковых устройств, известный как блочные устройства. Блочные устройства — это дисковые устройства, для которых ядро предоставляет кэширование. Это кэширование делает блочные устройства практически непригодными или, по крайней мере, опасно ненадёжными. Кэширование изменяет порядок операций записи, лишая приложение возможности точно знать содержимое диска в любой момент времени.

	-Это делает невозможным предсказуемое и надежное восстановление после сбоев для структур данных на диске (файловых систем, баз данных и т. д.). Поскольку операции записи могут быть отложены, ядро не может сообщить приложению, какая именно операция записи столкнулась с ошибкой, что усугубляет проблему согласованности.
	+Это делает невозможным предсказуемое и надёжное восстановление после сбоев для структур данных на диске (файловых систем, баз данных и т. д.). Поскольку операции записи могут быть отложены, ядро не может сообщить приложению, какая именно операция записи столкнулась с ошибкой, что усугубляет проблему согласованности.

	По этой причине ни одно серьезное приложение не полагается на блочные устройства, и фактически почти все приложения, которые обращаются к дискам напрямую, прилагают значительные усилия, чтобы указать, что следует всегда использовать символьные (или "сырые") устройства. Поскольку реализация псевдонимов для каждого диска (раздела) в виде двух устройств с разной семантикой значительно усложняла соответствующий код ядра, FreeBSD отказалась от поддержки кэшируемых дисковых устройств в рамках модернизации инфраструктуры ввода-вывода для дисков.

	diff --git a/documentation/content/ru/books/arch-handbook/driverbasics/_index.po b/documentation/content/ru/books/arch-handbook/driverbasics/_index.po
	--- a/documentation/content/ru/books/arch-handbook/driverbasics/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/driverbasics/_index.po
	@@ -6,7 +6,7 @@
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-09-23 04:45+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookdriverbasics_index/ru/>\n"
	@@ -304,7 +304,7 @@
	"user process. This is the most common type of device driver and there are "
	"plenty of simple examples in the source tree."
	msgstr ""
	-"Драйвер символьного устройства — это драйвер, который передает данные "
	+"Драйвер символьного устройства — это драйвер, который передаёт данные "
	"напрямую между устройством и пользовательским процессом. Это наиболее "
	"распространенный тип драйвера устройств, и в дереве исходного кода есть "
	"множество простых примеров."
	@@ -824,7 +824,7 @@
	"particular write operation encountered a write error, this further compounds "
	"the consistency problem."
	msgstr ""
	-"Это делает невозможным предсказуемое и надежное восстановление после сбоев "
	+"Это делает невозможным предсказуемое и надёжное восстановление после сбоев "
	"для структур данных на диске (файловых систем, баз данных и т. д.). "
	"Поскольку операции записи могут быть отложены, ядро не может сообщить "
	"приложению, какая именно операция записи столкнулась с ошибкой, что "
	diff --git a/documentation/content/ru/books/arch-handbook/isa/_index.adoc b/documentation/content/ru/books/arch-handbook/isa/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/isa/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/isa/_index.adoc
	@@ -413,7 +413,7 @@

	* `int bus_dmamap_load(bus_dma_tag_t dmat, bus_dmamap_t map, void buf, bus_size_t buflen, bus_dmamap_callback_t callback, void *callback_arg, int flags)`
	+
	-Загрузить буфер в карту (карта должна быть предварительно создана с помощью `bus_dmamap_create()` или `bus_dmamem_alloc()`). Все страницы буфера проверяются на соответствие требованиям тега, и для несоответствующих выделяются промежуточные страницы. Создается массив дескрипторов физических сегментов и передается в подпрограмму обратного вызова. Ожидается, что эта подпрограмма обработает его каким-либо образом. Количество промежуточных буферов в системе ограничено, поэтому, если эти буферы требуются, но недоступны немедленно, запрос будет поставлен в очередь, и обратный вызов будет выполнен, когда промежуточные буферы станут доступны. Возвращает 0, если обратный вызов был выполнен немедленно, или `EINPROGRESS`, если запрос был поставлен в очередь для выполнения в будущем. В последнем случае синхронизация с подпрограммой обратного вызова, поставленной в очередь, является обязанностью драйвера.
	+Загрузить буфер в карту (карта должна быть предварительно создана с помощью `bus_dmamap_create()` или `bus_dmamem_alloc()`). Все страницы буфера проверяются на соответствие требованиям тега, и для несоответствующих выделяются промежуточные страницы. Создается массив дескрипторов физических сегментов и передаётся в подпрограмму обратного вызова. Ожидается, что эта подпрограмма обработает его каким-либо образом. Количество промежуточных буферов в системе ограничено, поэтому, если эти буферы требуются, но недоступны немедленно, запрос будет поставлен в очередь, и обратный вызов будет выполнен, когда промежуточные буферы станут доступны. Возвращает 0, если обратный вызов был выполнен немедленно, или `EINPROGRESS`, если запрос был поставлен в очередь для выполнения в будущем. В последнем случае синхронизация с подпрограммой обратного вызова, поставленной в очередь, является обязанностью драйвера.
	+
	** _dmat_ - тег
	** _map_ - карта
	@@ -467,7 +467,7 @@

	bus_dmamem_alloc -> bus_dmamap_load -> ...use buffer... -> -> bus_dmamap_unload -> bus_dmamem_free

	-Для буфера, который часто изменяется и передается извне драйвера:
	+Для буфера, который часто изменяется и передаётся извне драйвера:
	[.programlisting]
	....
	bus_dmamap_create ->
	@@ -740,7 +740,7 @@

	Теперь, имея доступ к регистрам с отображением на порты, мы можем каким-либо образом взаимодействовать с устройством и проверить, реагирует ли оно так, как ожидается. Если этого не происходит, вероятно, по этому адресу находится другое устройство или его там нет вовсе.

	-Обычно драйверы не настраивают обработчики прерываний до вызова процедуры присоединения. Вместо этого они выполняют проверки в режиме опроса, используя функцию `DELAY()` для таймаута. Процедура проверки никогда не должна зависать навсегда, все ожидания ответа от устройства должны выполняться с таймаутами. Если устройство не отвечает в течение заданного времени, вероятно, оно неисправно или неправильно настроено, и драйвер должен вернуть ошибку. При определении интервала таймаута следует давать устройству дополнительное время для надежности: хотя предполагается, что `DELAY()` задерживает выполнение на одинаковое время на любой машине, существует некоторая погрешность, зависящая от конкретного процессора.
	+Обычно драйверы не настраивают обработчики прерываний до вызова процедуры присоединения. Вместо этого они выполняют проверки в режиме опроса, используя функцию `DELAY()` для таймаута. Процедура проверки никогда не должна зависать навсегда, все ожидания ответа от устройства должны выполняться с таймаутами. Если устройство не отвечает в течение заданного времени, вероятно, оно неисправно или неправильно настроено, и драйвер должен вернуть ошибку. При определении интервала таймаута следует давать устройству дополнительное время для надёжности: хотя предполагается, что `DELAY()` задерживает выполнение на одинаковое время на любой машине, существует некоторая погрешность, зависящая от конкретного процессора.

	Если процедура проверки действительно хочет убедиться, что прерывания работают, она может также настроить и провести обнаружение прерываний. Однако это не рекомендуется.

	diff --git a/documentation/content/ru/books/arch-handbook/isa/_index.po b/documentation/content/ru/books/arch-handbook/isa/_index.po
	--- a/documentation/content/ru/books/arch-handbook/isa/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/isa/_index.po
	@@ -6,7 +6,7 @@
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-09-01 04:45+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookisa_index/ru/>\n"
	@@ -1866,7 +1866,7 @@
	"`bus_dmamap_create()` или `bus_dmamem_alloc()`). Все страницы буфера "
	"проверяются на соответствие требованиям тега, и для несоответствующих "
	"выделяются промежуточные страницы. Создается массив дескрипторов физических "
	-"сегментов и передается в подпрограмму обратного вызова. Ожидается, что эта "
	+"сегментов и передаётся в подпрограмму обратного вызова. Ожидается, что эта "
	"подпрограмма обработает его каким-либо образом. Количество промежуточных "
	"буферов в системе ограничено, поэтому, если эти буферы требуются, но "
	"недоступны немедленно, запрос будет поставлен в очередь, и обратный вызов "
	@@ -2129,7 +2129,7 @@
	#: documentation/content/en/books/arch-handbook/isa/_index.adoc:471
	msgid ""
	"For a buffer that changes frequently and is passed from outside the driver:"
	-msgstr "Для буфера, который часто изменяется и передается извне драйвера:"
	+msgstr "Для буфера, который часто изменяется и передаётся извне драйвера:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/isa/_index.adoc:480
	@@ -3161,7 +3161,7 @@
	"выполняться с таймаутами. Если устройство не отвечает в течение заданного "
	"времени, вероятно, оно неисправно или неправильно настроено, и драйвер "
	"должен вернуть ошибку. При определении интервала таймаута следует давать "
	-"устройству дополнительное время для надежности: хотя предполагается, что "
	+"устройству дополнительное время для надёжности: хотя предполагается, что "
	"`DELAY()` задерживает выполнение на одинаковое время на любой машине, "
	"существует некоторая погрешность, зависящая от конкретного процессора."

	diff --git a/documentation/content/ru/books/arch-handbook/jail/_index.po b/documentation/content/ru/books/arch-handbook/jail/_index.po
	--- a/documentation/content/ru/books/arch-handbook/jail/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/jail/_index.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-10-16 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-11 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookjail_index/ru/>\n"
	@@ -65,7 +65,7 @@
	"if an attacker gains `root` within the jail, it is only an annoyance, and "
	"not a devastation. This article mainly focuses on the internals (source "
	"code) of jail. For information on how to set up a jail see the extref:"
	-"{handbook}[handbook entry on jails, jails]."
	+"{handbook}jails[handbook entry on jails, jails]."
	msgstr ""
	"Клетка становится новой моделью безопасности. Пользователи запускают "
	"потенциально уязвимые серверы, такие как Apache, BIND и sendmail, внутри "
	@@ -258,8 +258,8 @@
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:118
	msgid ""
	"Finally, the userland program jails the process. Jail now becomes an "
	-"imprisoned process itself and then executes the command given using "
	-"man:execv[3]."
	+"imprisoned process itself and then executes the command given using man:"
	+"execv[3]."
	msgstr ""
	"Наконец, пользовательская программа помещает процесс в `клетку`. Теперь "
	"`клетка` становится самим заключенным процессом и выполняет команду, "
	@@ -303,9 +303,9 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:133
	msgid ""
	-"We will now be looking at the file [.filename]#/usr/src/sys/kern/"
	-"kern_jail.c#. This is the file where the man:jail[2] system call, "
	-"appropriate sysctls, and networking functions are defined."
	+"We will now be looking at the file [.filename]#/usr/src/sys/kern/kern_jail."
	+"c#. This is the file where the man:jail[2] system call, appropriate sysctls, "
	+"and networking functions are defined."
	msgstr ""
	"Мы сейчас рассмотрим файл [.filename]#/usr/src/sys/kern/kern_jail.c#. В этом "
	"файле определены системный вызов man:jail[2], соответствующие sysctls и "
	@@ -320,7 +320,8 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:137
	msgid "In [.filename]#kern_jail.c#, the following sysctls are defined:"
	-msgstr "В файле [.filename]#kern_jail.c# определены следующие параметры sysctl:"
	+msgstr ""
	+"В файле [.filename]#kern_jail.c# определены следующие параметры sysctl:"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:145
	@@ -350,8 +351,7 @@
	"int jail_socket_unixiproute_only = 1;\n"
	"SYSCTL_INT(_security_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,\n"
	" &jail_socket_unixiproute_only, 0,\n"
	-" \"Processes in jail are limited to creating UNIX/IPv4/route sockets "
	-"only\");\n"
	+" \"Processes in jail are limited to creating UNIX/IPv4/route sockets only\");\n"

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:155
	@@ -428,8 +428,8 @@
	msgid ""
	"Each of these sysctls can be accessed by the user through the man:sysctl[8] "
	"program. Throughout the kernel, these specific sysctls are recognized by "
	-"their name. For example, the name of the first sysctl is "
	-"`security.jail.set_hostname_allowed`."
	+"their name. For example, the name of the first sysctl is `security.jail."
	+"set_hostname_allowed`."
	msgstr ""
	"Каждый из этих параметров sysctl может быть доступен пользователю через "
	"программу man:sysctl[8]. В ядре эти конкретные параметры sysctl распознаются "
	@@ -457,8 +457,8 @@
	"аргумента: `struct thread td` и `struct jail_args uap`. `td` — это "
	"указатель на структуру `thread`, которая описывает вызывающий поток. В "
	"данном контексте `uap` — это указатель на структуру, в которой содержится "
	-"указатель на структуру `jail`, переданную из пользовательского пространства ["
	-".filename]#jail.c#. Ранее, когда я описывал пользовательскую программу, вы "
	+"указатель на структуру `jail`, переданную из пользовательского пространства "
	+"[.filename]#jail.c#. Ранее, когда я описывал пользовательскую программу, вы "
	"видели, что системному вызову man:jail[2] была передана структура `jail` в "
	"качестве собственного аргумента."

	@@ -495,14 +495,14 @@
	"`jail` structure pointed by `uap->jail` is copied into kernel space and is "
	"stored in another `jail` structure, `j`."
	msgstr ""
	-"Следовательно, `uap->jail` можно использовать для доступа к структуре `jail`"
	-", которая была передана системному вызову. Далее системный вызов копирует "
	-"структуру `клетка` в пространство ядра с помощью функции man:copyin[9]. "
	-"man:copyin[9] принимает три аргумента: адрес данных, которые нужно "
	-"скопировать в пространство ядра (`uap->jail`), место для записи данных (`j`) "
	-"и размер хранилища. Структура `jail`, на которую указывает `uap->jail`, "
	-"копируется в пространство ядра и сохраняется в другой структуре `клетка` — "
	-"`j`."
	+"Следовательно, `uap->jail` можно использовать для доступа к структуре "
	+"`jail`, которая была передана системному вызову. Далее системный вызов "
	+"копирует структуру `клетка` в пространство ядра с помощью функции man:"
	+"copyin[9]. man:copyin[9] принимает три аргумента: адрес данных, которые "
	+"нужно скопировать в пространство ядра (`uap->jail`), место для записи данных "
	+"(`j`) и размер хранилища. Структура `jail`, на которую указывает `uap-"
	+">jail`, копируется в пространство ядра и сохраняется в другой структуре "
	+"`клетка` — `j`."

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:201
	@@ -547,26 +547,18 @@
	msgstr ""
	"/usr/include/sys/jail.h:\n"
	"struct prison {\n"
	-" LIST_ENTRY(prison) pr_list; /* (a) all prisons */"
	-"\n"
	+" LIST_ENTRY(prison) pr_list; /* (a) all prisons */\n"
	" int pr_id; /* (c) prison id */\n"
	" int pr_ref; /* (p) refcount */\n"
	-" char pr_path[MAXPATHLEN]; /* (c) chroot path */"
	-"\n"
	-" struct vnode pr_root; / (c) vnode to rdir "
	-"*/\n"
	-" char pr_host[MAXHOSTNAMELEN]; /* (p) jail hostname "
	-"*/\n"
	-" u_int32_t pr_ip; /* (c) ip addr host "
	-"*/\n"
	+" char pr_path[MAXPATHLEN]; /* (c) chroot path */\n"
	+" struct vnode pr_root; / (c) vnode to rdir */\n"
	+" char pr_host[MAXHOSTNAMELEN]; /* (p) jail hostname */\n"
	+" u_int32_t pr_ip; /* (c) ip addr host */\n"
	" void pr_linux; / (p) linux abi */\n"
	-" int pr_securelevel; /* (p) securelevel */"
	-"\n"
	-" struct task pr_task; /* (d) destroy task "
	-"*/\n"
	+" int pr_securelevel; /* (p) securelevel */\n"
	+" struct task pr_task; /* (d) destroy task */\n"
	" struct mtx pr_mtx;\n"
	-" void *pr_slots; / (p) additional data "
	-"*/\n"
	+" void *pr_slots; / (p) additional data */\n"
	"};\n"

	#. type: Plain text
	@@ -653,8 +645,8 @@
	msgid ""
	"On FreeBSD, each kernel visible thread is identified by its `thread` "
	"structure, while the processes are described by their `proc` structures. You "
	-"can find the definitions of the `thread` and `proc` structure in "
	-"[.filename]#/usr/include/sys/proc.h#. For example, the `td` argument in any "
	+"can find the definitions of the `thread` and `proc` structure in [."
	+"filename]#/usr/include/sys/proc.h#. For example, the `td` argument in any "
	"system call is actually a pointer to the calling thread's `thread` "
	"structure, as stated before. The `td_proc` member in the `thread` structure "
	"pointed by `td` is a pointer to the `proc` structure which represents the "
	@@ -744,11 +736,11 @@
	"в клетке. Когда в ядре вызывается функция `jailed()` с вновь созданной "
	"структурой `ucred` в качестве аргумента, она возвращает 1, указывая, что "
	"учётные данные связаны с клеткой. Общим родительским процессом для всех "
	-"процессов, созданных внутри клетки, является процесс, запускающий man:jail[8]"
	-", так как он вызывает системный вызов man:jail[2]. При выполнении программы "
	-"через man:execve[2] она наследует свойство клетки из структуры `ucred` "
	-"родительского процесса, следовательно, у нее структура `ucred` тоже со "
	-"свойством клетки."
	+"процессов, созданных внутри клетки, является процесс, запускающий man:"
	+"jail[8], так как он вызывает системный вызов man:jail[2]. При выполнении "
	+"программы через man:execve[2] она наследует свойство клетки из структуры "
	+"`ucred` родительского процесса, следовательно, у нее структура `ucred` тоже "
	+"со свойством клетки."

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:296
	@@ -828,8 +820,8 @@
	"process. It inherently keep the newly forked child's credential consistent "
	"with its parent, so the child process is also jailed."
	msgstr ""
	-"Когда процесс создается из родительского процесса, системный вызов "
	-"man:fork[2] использует `crhold()` для поддержания учетных данных нового "
	+"Когда процесс создается из родительского процесса, системный вызов man:"
	+"fork[2] использует `crhold()` для поддержания учетных данных нового "
	"процесса. Это автоматически сохраняет учетные данные нового дочернего "
	"процесса согласованными с родительским, поэтому дочерний процесс также "
	"остается в клетке."
	@@ -888,12 +880,12 @@
	"messages which tell them how to act. The functions which deal with messages "
	"are: man:msgctl[3], man:msgget[3], man:msgsnd[3] and man:msgrcv[3]. Earlier, "
	"I mentioned that there were certain sysctls you could turn on or off in "
	-"order to affect the behavior of jail. One of these sysctls was "
	-"`security.jail.sysvipc_allowed`. By default, this sysctl is set to 0. If it "
	-"were set to 1, it would defeat the whole purpose of having a jail; "
	-"privileged users from the jail would be able to affect processes outside the "
	-"jailed environment. The difference between a message and a signal is that "
	-"the message only consists of the signal number."
	+"order to affect the behavior of jail. One of these sysctls was `security."
	+"jail.sysvipc_allowed`. By default, this sysctl is set to 0. If it were set "
	+"to 1, it would defeat the whole purpose of having a jail; privileged users "
	+"from the jail would be able to affect processes outside the jailed "
	+"environment. The difference between a message and a signal is that the "
	+"message only consists of the signal number."
	msgstr ""
	"System V IPC основан на сообщениях. Процессы могут отправлять друг другу эти "
	"сообщения, которые указывают им, как действовать. Функции, работающие с "
	@@ -982,8 +974,8 @@
	"предоставляют ещё один способ для процессов блокировать ресурсы. Однако "
	"процесс, ожидающий семафор, который уже используется, будет находиться в "
	"состоянии сна до тех пор, пока ресурсы не будут освобождены. Следующие "
	-"системные вызовы семафоров блокируются внутри клетки: man:semget[2], "
	-"man:semctl[2] и man:semop[2]."
	+"системные вызовы семафоров блокируются внутри клетки: man:semget[2], man:"
	+"semctl[2] и man:semop[2]."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:360
	@@ -996,8 +988,8 @@
	"`semctl(semid, semnum, cmd, ...)`: `semctl` does the specified `cmd` on the "
	"semaphore queue indicated by `semid`."
	msgstr ""
	-"`semctl(semid, semnum, cmd, ...)`: `semctl` выполняет указанную команду `cmd`"
	-" для очереди семафоров, указанной в `semid`."
	+"`semctl(semid, semnum, cmd, ...)`: `semctl` выполняет указанную команду "
	+"`cmd` для очереди семафоров, указанной в `semid`."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/jail/_index.adoc:363
	@@ -1232,8 +1224,7 @@
	msgstr ""
	"/usr/src/sys/netinet/in_pcb.c:\n"
	"int\n"
	-"in_pcbbind_setup(struct inpcb inp, struct sockaddr nam, in_addr_t *laddrp,"
	-"\n"
	+"in_pcbbind_setup(struct inpcb inp, struct sockaddr nam, in_addr_t *laddrp,\n"
	" u_short lportp, struct ucred cred)\n"
	"{\n"
	" ...\n"
	@@ -1277,8 +1268,8 @@
	"that address."
	msgstr ""
	"Вы можете задаться вопросом, какую функцию выполняет `prison_ip()`. "
	-"`prison_ip()` принимает три аргумента: указатель на учетные данные ("
	-"представленные как `cred`), любые флаги и IP-адрес. Она возвращает 1, если "
	+"`prison_ip()` принимает три аргумента: указатель на учетные данные "
	+"(представленные как `cred`), любые флаги и IP-адрес. Она возвращает 1, если "
	"IP-адрес НЕ принадлежит клетке, и 0 в противном случае. Как видно из кода, "
	"если это действительно IP-адрес, не принадлежащий клетке, протоколу не "
	"разрешается привязываться к этому адресу."
	diff --git a/documentation/content/ru/books/arch-handbook/mac/_index.adoc b/documentation/content/ru/books/arch-handbook/mac/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/mac/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/mac/_index.adoc
	@@ -135,7 +135,7 @@
	[[mac-framework-kernel-arch-label-synchronization]]
	=== Синхронизация меток

	-Поскольку к объектам ядра обычно может обращаться более одного потока одновременно, и допускается одновременный вход нескольких потоков в MAC Framework, хранение атрибутов безопасности, поддерживаемое MAC Framework, тщательно синхронизировано. Как правило, существующая синхронизация ядра для данных объектов ядра используется для защиты меток безопасности MAC Framework на объекте: например, метки MAC на сокетах защищаются с помощью существующего мьютекса сокета. Аналогично, семантика параллельного доступа обычно идентична семантике контейнерных объектов: для учетных данных поддерживается семантика копирования при записи для содержимого меток, как и для остальной структуры учетных данных. MAC Framework устанавливает необходимые блокировки на объекты при вызове с ссылкой на объект. Авторам политик необходимо учитывать эти семантики синхронизации, так как они иногда ограничивают типы доступа к меткам: например, когда ссылка только для чтения на учетные данные передается политике через точку входа, разрешены только операции чтения для состояния метки, прикрепленного к учетным данным.
	+Поскольку к объектам ядра обычно может обращаться более одного потока одновременно, и допускается одновременный вход нескольких потоков в MAC Framework, хранение атрибутов безопасности, поддерживаемое MAC Framework, тщательно синхронизировано. Как правило, существующая синхронизация ядра для данных объектов ядра используется для защиты меток безопасности MAC Framework на объекте: например, метки MAC на сокетах защищаются с помощью существующего мьютекса сокета. Аналогично, семантика параллельного доступа обычно идентична семантике контейнерных объектов: для учетных данных поддерживается семантика копирования при записи для содержимого меток, как и для остальной структуры учетных данных. MAC Framework устанавливает необходимые блокировки на объекты при вызове с ссылкой на объект. Авторам политик необходимо учитывать эти семантики синхронизации, так как они иногда ограничивают типы доступа к меткам: например, когда ссылка только для чтения на учетные данные передаётся политике через точку входа, разрешены только операции чтения для состояния метки, прикрепленного к учетным данным.

	[[mac-framework-kernel-arch-policy-synchronization]]
	=== Синхронизация политики и параллелизм
	@@ -3777,7 +3777,7 @@
	\|
	\|===

	-Определить, могут ли учетные данные субъекта создать vnode с указанной родительской директорией, информацией о имени и атрибутами. Возвращает 0 при успехе или значение `errno` при ошибке. Рекомендуемые ошибки: EACCES при несоответствии метки или EPERM при отсутствии привилегий. Этот вызов может выполняться в различных ситуациях, включая вызовы man:open[2] с O_CREAT, man:mkfifo[2] и другие.
	+Определить, могут ли учетные данные субъекта создать vnode с указанным родительским каталогом, информацией о имени и атрибутами. Возвращает 0 при успехе или значение `errno` при ошибке. Рекомендуемые ошибки: EACCES при несоответствии метки или EPERM при отсутствии привилегий. Этот вызов может выполняться в различных ситуациях, включая вызовы man:open[2] с O_CREAT, man:mkfifo[2] и другие.

	[[mac-mpo-cred-check-vnode-delete]]
	==== `mpo_check_vnode_delete`
	@@ -4237,7 +4237,7 @@
	\|
	\|===

	-Определить, следует ли разрешить субъекту переименование vnode `vp` в директорию `dvp` или в имя, представленное `cnp`. Если не существует файла для перезаписи, `vp` и `label` будут NULL.
	+Определить, следует ли разрешить субъекту переименование vnode `vp` в каталог `dvp` или в имя, представленное `cnp`. Если не существует файла для перезаписи, `vp` и `label` будут NULL.

	[[mac-mpo-cred-check-socket-listen]]
	==== `mpo_check_socket_listen`
	diff --git a/documentation/content/ru/books/arch-handbook/mac/_index.po b/documentation/content/ru/books/arch-handbook/mac/_index.po
	--- a/documentation/content/ru/books/arch-handbook/mac/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/mac/_index.po
	@@ -6,7 +6,7 @@
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-10-30 04:45+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookmac_index/ru/>\n"
	@@ -515,7 +515,7 @@
	"необходимые блокировки на объекты при вызове с ссылкой на объект. Авторам "
	"политик необходимо учитывать эти семантики синхронизации, так как они иногда "
	"ограничивают типы доступа к меткам: например, когда ссылка только для чтения "
	-"на учетные данные передается политике через точку входа, разрешены только "
	+"на учетные данные передаётся политике через точку входа, разрешены только "
	"операции чтения для состояния метки, прикрепленного к учетным данным."

	#. type: Title ===
	@@ -7076,8 +7076,8 @@
	"privilege. This call may be made in a number of situations, including as a "
	"result of calls to man:open[2] with O_CREAT, man:mkfifo[2], and others."
	msgstr ""
	-"Определить, могут ли учетные данные субъекта создать vnode с указанной "
	-"родительской директорией, информацией о имени и атрибутами. Возвращает 0 при "
	+"Определить, могут ли учетные данные субъекта создать vnode с указанным "
	+"родительским каталогом, информацией о имени и атрибутами. Возвращает 0 при "
	"успехе или значение `errno` при ошибке. Рекомендуемые ошибки: EACCES при "
	"несоответствии метки или EPERM при отсутствии привилегий. Этот вызов может "
	"выполняться в различных ситуациях, включая вызовы man:open[2] с O_CREAT, "
	@@ -7592,8 +7592,8 @@
	"no existing file to overwrite, `vp` and `label` will be NULL."
	msgstr ""
	"Определить, следует ли разрешить субъекту переименование vnode `vp` в "
	-"директорию `dvp` или в имя, представленное `cnp`. Если не существует файла "
	-"для перезаписи, `vp` и `label` будут NULL."
	+"каталог `dvp` или в имя, представленное `cnp`. Если не существует файла для "
	+"перезаписи, `vp` и `label` будут NULL."

	#. type: Title ====
	#: documentation/content/en/books/arch-handbook/mac/_index.adoc:4496
	diff --git a/documentation/content/ru/books/arch-handbook/scsi/_index.adoc b/documentation/content/ru/books/arch-handbook/scsi/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/scsi/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/scsi/_index.adoc
	@@ -69,7 +69,7 @@
	* _Модули периферийных устройств_ - драйвер для периферийных устройств (диски, ленты, CD-ROM и т.д.)
	* _Модули интерфейса SCSI_ (SIM) - драйверы адаптеров шины для подключения к шине ввода-вывода, такой как SCSI или IDE.

	-Периферийный драйвер получает запросы от ОС, преобразует их в последовательность команд SCSI и передает эти команды SCSI модулю интерфейса SCSI. Модуль интерфейса SCSI отвечает за передачу этих команд реальному оборудованию (или, если оборудование не поддерживает SCSI, а использует, например, IDE, также преобразует команды SCSI в собственные команды оборудования).
	+Периферийный драйвер получает запросы от ОС, преобразует их в последовательность команд SCSI и передаёт эти команды SCSI модулю интерфейса SCSI. Модуль интерфейса SCSI отвечает за передачу этих команд реальному оборудованию (или, если оборудование не поддерживает SCSI, а использует, например, IDE, также преобразует команды SCSI в собственные команды оборудования).

	Так как мы заинтересованы в написании драйвера адаптера SCSI, с этого момента мы будем рассматривать всё с точки зрения модуля SCSI-интерфейса (SIM).

	@@ -146,7 +146,7 @@
	* `driver_name` — имя фактического драйвера, например `ncr` или `wds`.
	* `softc` — указатель на внутренний дескриптор драйвера для данной SCSI-карты. Этот указатель будет использоваться драйвером в дальнейшем для получения приватных данных.
	* unit - номер управляющего устройства, например, для контроллера "mps0" это число будет 0
	-* mtx - Блокировка, связанная с данной SIM. Для SIM, которые не поддерживают блокировку, передается Giant. Для SIM, которые поддерживают, передается блокировка, используемая для защиты структур данных этой SIM. Эта блокировка будет удерживаться при вызовах xxx_action и xxx_poll.
	+* mtx - Блокировка, связанная с данной SIM. Для SIM, которые не поддерживают блокировку, передаётся Giant. Для SIM, которые поддерживают, передаётся блокировка, используемая для защиты структур данных этой SIM. Эта блокировка будет удерживаться при вызовах xxx_action и xxx_poll.
	* max_dev_transactions - максимальное количество одновременных транзакций на целевом SCSI-устройстве в режиме без тегов. Это значение почти всегда равно 1, за исключением возможных исключений только для не-SCSI карт. Также драйверы, которые надеются получить преимущество, подготавливая одну транзакцию во время выполнения другой, могут установить его в 2, но это не кажется оправданным из-за сложности.
	* max_tagged_dev_transactions - то же самое, но в режиме с тегами. Теги — это способ в SCSI инициировать несколько транзакций на устройстве: каждая транзакция получает уникальный тег и отправляется на устройство. Когда устройство завершает транзакцию, оно возвращает результат вместе с тегом, чтобы SCSI-адаптер (и драйвер) могли определить, какая транзакция была завершена. Этот аргумент также известен как максимальная глубина тега. Он зависит от возможностей SCSI-адаптера.

	@@ -255,7 +255,7 @@

	`xpt_done()` не обязательно вызывать из `xxx_action()`: Например, запрос ввода-вывода может быть поставлен в очередь внутри драйвера SIM и/или его SCSI-контроллера. Затем, когда устройство пошлет прерывание, сигнализирующее о завершении обработки этого запроса, `xpt_done()` может быть вызван из процедуры обработки прерывания.

	-На самом деле, статус CCB не только присваивается в качестве кода возврата, но и CCB всегда имеет какой-то статус. Перед тем как CCB передается в процедуру `xxx_action()`, он получает статус CCB_REQ_INPROG, означающий, что запрос находится в процессе выполнения. В [.filename]#/sys/cam/cam.h# определено удивительно большое количество значений статуса, которые должны детально отражать состояние запроса. Что еще интереснее, статус фактически представляет собой "побитовое ИЛИ" перечисленного значения статуса (младшие 6 бит) и возможных дополнительных флагов (старшие биты). Перечисленные значения будут подробно рассмотрены далее. Их краткое описание можно найти в разделе "Сводка ошибок". Возможные флаги статуса:
	+На самом деле, статус CCB не только присваивается в качестве кода возврата, но и CCB всегда имеет какой-то статус. Перед тем как CCB передаётся в процедуру `xxx_action()`, он получает статус CCB_REQ_INPROG, означающий, что запрос находится в процессе выполнения. В [.filename]#/sys/cam/cam.h# определено удивительно большое количество значений статуса, которые должны детально отражать состояние запроса. Что еще интереснее, статус фактически представляет собой "побитовое ИЛИ" перечисленного значения статуса (младшие 6 бит) и возможных дополнительных флагов (старшие биты). Перечисленные значения будут подробно рассмотрены далее. Их краткое описание можно найти в разделе "Сводка ошибок". Возможные флаги статуса:

	* _CAM_DEV_QFRZN_ - если драйвер SIM получает серьёзную ошибку (например, устройство не отвечает на выборку или нарушает протокол SCSI) при обработке CCB, он должен заморозить очередь запросов, вызвав `xpt_freeze_simq()`, вернуть другие поставленные в очередь, но ещё не обработанные CCB для этого устройства обратно в очередь CAM, затем установить этот флаг для проблемного CCB и вызвать `xpt_done()`. Этот флаг заставляет подсистему CAM разморозить очередь после обработки ошибки.
	* _CAM_AUTOSNS_VALID_ - если устройство вернуло состояние ошибки и флаг CAM_DIS_AUTOSENSE не установлен в CCB, драйвер SIM должен автоматически выполнить команду REQUEST SENSE, чтобы извлечь данные sense (расширенную информацию об ошибке) из устройства. Если попытка была успешной, данные sense должны быть сохранены в CCB, а этот флаг установлен.
	@@ -1322,7 +1322,7 @@
	При выполнении запроса ввода-вывода может произойти множество ошибок. Причина ошибки может быть указана в статусе CCB с большим количеством деталей. Примеры использования разбросаны по всему документу. Для полноты изложения приведём сводку рекомендуемых действий при типичных ошибках:

	* _CAM_RESRC_UNAVAIL_ — некоторый ресурс временно недоступен, и драйвер SIM не может сгенерировать событие, когда он станет доступен. Примером такого ресурса может быть некоторый внутренний аппаратный ресурс контроллера, для которого контроллер не генерирует прерывание при его доступности.
	-* _CAM_UNCOR_PARITY_ - произошла неисправимая ошибка четности
	+* _CAM_UNCOR_PARITY_ - произошла неисправимая ошибка чётности
	* _CAM_DATA_RUN_ERR_ - переполнение данных или неожиданная фаза данных (направление передачи не соответствует указанному в CAM_DIR_MASK) или нечётная длина передачи для широкой передачи
	* _CAM_SEL_TIMEOUT_ - произошел таймаут выбора (цель не отвечает)
	* _CAM_CMD_TIMEOUT_ - произошло превышение времени ожидания команды (сработала функция таймаута)
	diff --git a/documentation/content/ru/books/arch-handbook/scsi/_index.po b/documentation/content/ru/books/arch-handbook/scsi/_index.po
	--- a/documentation/content/ru/books/arch-handbook/scsi/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/scsi/_index.po
	@@ -6,7 +6,7 @@
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-10-26 04:45+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookscsi_index/ru/>\n"
	@@ -156,7 +156,7 @@
	"of the hardware)."
	msgstr ""
	"Периферийный драйвер получает запросы от ОС, преобразует их в "
	-"последовательность команд SCSI и передает эти команды SCSI модулю интерфейса "
	+"последовательность команд SCSI и передаёт эти команды SCSI модулю интерфейса "
	"SCSI. Модуль интерфейса SCSI отвечает за передачу этих команд реальному "
	"оборудованию (или, если оборудование не поддерживает SCSI, а использует, "
	"например, IDE, также преобразует команды SCSI в собственные команды "
	@@ -393,7 +393,7 @@
	"xxx_poll are called."
	msgstr ""
	"mtx - Блокировка, связанная с данной SIM. Для SIM, которые не поддерживают "
	-"блокировку, передается Giant. Для SIM, которые поддерживают, передается "
	+"блокировку, передаётся Giant. Для SIM, которые поддерживают, передаётся "
	"блокировка, используемая для защиты структур данных этой SIM. Эта блокировка "
	"будет удерживаться при вызовах xxx_action и xxx_poll."

	@@ -829,7 +829,7 @@
	"Summary section. The possible status flags are:"
	msgstr ""
	"На самом деле, статус CCB не только присваивается в качестве кода возврата, "
	-"но и CCB всегда имеет какой-то статус. Перед тем как CCB передается в "
	+"но и CCB всегда имеет какой-то статус. Перед тем как CCB передаётся в "
	"процедуру `xxx_action()`, он получает статус CCB_REQ_INPROG, означающий, что "
	"запрос находится в процессе выполнения. В [.filename]#/sys/cam/cam.h# "
	"определено удивительно большое количество значений статуса, которые должны "
	@@ -4082,7 +4082,7 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/scsi/_index.adoc:1468
	msgid "_CAM_UNCOR_PARITY_ - unrecovered parity error occurred"
	-msgstr "_CAM_UNCOR_PARITY_ - произошла неисправимая ошибка четности"
	+msgstr "_CAM_UNCOR_PARITY_ - произошла неисправимая ошибка чётности"

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/scsi/_index.adoc:1469
	diff --git a/documentation/content/ru/books/arch-handbook/smp/_index.adoc b/documentation/content/ru/books/arch-handbook/smp/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/smp/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/smp/_index.adoc
	@@ -100,7 +100,7 @@
	Недостатки этой оптимизации заключаются в том, что они очень специфичны для конкретной машины и сложны, поэтому стоят усилий только в случае значительного улучшения производительности. На данный момент, вероятно, ещё рано делать выводы, и, фактически, это может даже ухудшить производительность, так как почти все обработчики прерываний будут немедленно блокироваться на Giant и потребуют исправления потока при блокировке. Кроме того, Майк Смит предложил альтернативный метод обработки прерываний, который работает следующим образом:

	. Каждый обработчик прерывания состоит из двух частей: предиката, который выполняется в основном контексте прерывания, и обработчика, который выполняется в контексте собственного потока.
	-. Если у обработчика прерывания есть предикат, то при срабатывании прерывания этот предикат выполняется. Если предикат возвращает значение `true`, прерывание считается полностью обработанным, и ядро возвращается из прерывания. Если предикат возвращает `false` или предиката нет, то запланированный обработчик запускается.
	+. Если у обработчика прерывания есть предикат, то при срабатывании прерывания этот предикат выполняется. Если предикат возвращает значение `true`, прерывание считается полностью обработанным, и ядро возвращается из прерывания. Если предикат возвращает `false` или предиката нет, то система планирует запуск обработчика в контексте собственного потока.

	Встраивание легковесных переключений контекста в эту схему может оказаться довольно сложным. Поскольку мы, возможно, захотим перейти на эту схему в будущем, вероятно, лучше отложить работу над легковесными переключениями контекста до тех пор, пока мы не определимся с окончательной архитектурой обработки прерываний и не выясним, как легковесные переключения контекста могут (или не могут) в неё вписаться.

	diff --git a/documentation/content/ru/books/arch-handbook/smp/_index.po b/documentation/content/ru/books/arch-handbook/smp/_index.po
	--- a/documentation/content/ru/books/arch-handbook/smp/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/smp/_index.po
	@@ -6,7 +6,7 @@
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-10-29 04:45+0000\n"
	+"PO-Revision-Date: 2025-11-08 16:33+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbooksmp_index/ru/>\n"
	@@ -442,8 +442,8 @@
	"Если у обработчика прерывания есть предикат, то при срабатывании прерывания "
	"этот предикат выполняется. Если предикат возвращает значение `true`, "
	"прерывание считается полностью обработанным, и ядро возвращается из "
	-"прерывания. Если предикат возвращает `false` или предиката нет, то "
	-"запланированный обработчик запускается."
	+"прерывания. Если предикат возвращает `false` или предиката нет, то система "
	+"планирует запуск обработчика в контексте собственного потока."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/smp/_index.adoc:110
	diff --git a/documentation/content/ru/books/arch-handbook/sound/_index.adoc b/documentation/content/ru/books/arch-handbook/sound/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/sound/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/sound/_index.adoc
	@@ -76,7 +76,7 @@
	В каталоге [.filename]#/usr/src/sys/dev/sound/#, папка [.filename]#pcm/# содержит основной код, тогда как каталоги [.filename]#pci/#, [.filename]#isa/# и [.filename]#usb/# содержат драйверы для плат PCI и ISA, а также для USB-аудиоустройств.

	[[pcm-probe-and-attach]]
	-== Обнаружение, присоединение и т.д.
	+== Обнаружение, подключение и т.д.

	Драйверы звуковых устройств выполняют обнаружение и подключение почти так же, как и любой модуль драйвера оборудования. Возможно, вам будет полезно ознакомиться с разделами руководства, посвящёнными crossref:isa-driver[isa-driver,ISA] или crossref:pci[pci,PCI], для получения дополнительной информации.

	@@ -96,15 +96,15 @@
	MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);
	....
	+
	-Большинству звуковых драйверов необходимо хранить дополнительную приватную информацию о своём устройстве. Приватная структура данных обычно выделяется в процедуре attach. Её адрес передаётся в [.filename]#pcm# через вызовы `pcm_register()` и `mixer_init()`. [.filename]#pcm# позже передаёт обратно этот адрес в качестве параметра при вызовах интерфейсов звукового драйвера.
	-* Подпрограмма подключения звукового драйвера должна объявить свой интерфейс MIXER или AC97 для [.filename]#pcm#, вызвав `mixer_init()`. Для интерфейса MIXER это, в свою очередь, приводит к вызову crossref:sound[xxxmixer-init,`xxxmixer_init()`].
	-* Функция подключения драйвера звука объявляет свою общую конфигурацию CHANNEL для [.filename]#pcm#, вызывая `pcm_register(dev, sc, nplay, nrec)`, где `sc` — это адрес структуры данных устройства, используемый при последующих вызовах из [.filename]#pcm#, а `nplay` и `nrec` — количество каналов воспроизведения и записи.
	+Большинству звуковых драйверов необходимо хранить дополнительную приватную информацию о своём устройстве. Приватная структура данных обычно выделяется в процедуре подключения (attach). Её адрес передаётся в [.filename]#pcm# через вызовы `pcm_register()` и `mixer_init()`. [.filename]#pcm# позже передаёт обратно этот адрес в качестве параметра при вызовах интерфейсов звукового драйвера.
	+* Процедура подключения (attach) звукового драйвера должна объявить свой интерфейс MIXER или AC97 для [.filename]#pcm#, вызвав `mixer_init()`. Для интерфейса MIXER это, в свою очередь, приводит к вызову crossref:sound[xxxmixer-init,`xxxmixer_init()`].
	+* Процедура подключения драйвера звука объявляет свою общую конфигурацию CHANNEL для [.filename]#pcm#, вызывая `pcm_register(dev, sc, nplay, nrec)`, где `sc` — это адрес структуры данных устройства, используемый при последующих вызовах из [.filename]#pcm#, а `nplay` и `nrec` — количество каналов воспроизведения и записи.
	* Подпрограмма подключения звукового драйвера объявляет каждый из своих каналов вызовами `pcm_addchan()`. Это настраивает связующий слой канала в [.filename]#pcm# и, в свою очередь, вызывает вызов crossref:sound[xxxchannel-init,`xxxchannel_init()`].
	-* Драйвер звука должен вызвать `pcm_unregister()` в процедуре отключения перед освобождением своих ресурсов.
	+* Драйвер звука должен вызвать `pcm_unregister()` в процедуре отключения (detach) перед освобождением своих ресурсов.

	Существует два возможных способа работы с устройствами, не поддерживающими PnP:

	-* Используйте метод `device_identify()` (пример: [.filename]#sound/isa/es1888.c#). Метод `device_identify()` проверяет наличие оборудования по известным адресам и, если находит поддерживаемое устройство, создает новое pcm-устройство, которое затем передается для probe/attach.
	+* Используйте метод `device_identify()` (пример: [.filename]#sound/isa/es1888.c#). Метод `device_identify()` проверяет наличие оборудования по известным адресам и, если находит поддерживаемое устройство, создает новое pcm-устройство, которое затем передаётся для probe/attach.
	* Используйте пользовательскую конфигурацию ядра с соответствующими подсказками для устройств pcm (пример: [.filename]#sound/isa/mss.c#).

	[.filename]#pcm# драйверы должны реализовывать подпрограммы `device_suspend`, `device_resume` и `device_shutdown`, чтобы управление питанием и выгрузка модулей работали корректно.
	@@ -126,11 +126,11 @@

	Для всех функций интерфейса CHANNEL первый параметр — это непрозрачный указатель.

	-Второй параметр представляет собой указатель на приватную структуру данных канала, за исключением `channel_init()`, где передается указатель на приватную структуру устройства (и возвращается указатель на канал для дальнейшего использования [.filename]#pcm#).
	+Второй параметр представляет собой указатель на приватную структуру данных канала, за исключением `channel_init()`, где передаётся указатель на приватную структуру устройства (и возвращается указатель на канал для дальнейшего использования [.filename]#pcm#).

	==== Обзор операций передачи данных

	-Для надежной передачи звуковых данных ядро [.filename]#pcm# и драйверы звука взаимодействуют через общую область памяти, описываемую структурой `struct snd_dbuf`.
	+Для надёжной передачи звуковых данных ядро [.filename]#pcm# и драйверы звука взаимодействуют через общую область памяти, описываемую структурой `struct snd_dbuf`.

	`struct snd_dbuf` является приватной для [.filename]#pcm#, и драйверы звука получают нужные значения через вызовы функций доступа (`sndbuf_getxxx()`).

	@@ -145,7 +145,7 @@
	[[xxxchannel-init]]
	==== channel_init

	-`xxxchannel_init()` вызывается для инициализации каждого из каналов воспроизведения или записи. Вызовы инициируются из процедуры присоединения драйвера звука. (См. раздел crossref:sound[pcm-probe-and-attach,зондирование и присоединение]).
	+`xxxchannel_init()` вызывается для инициализации каждого из каналов воспроизведения или записи. Вызовы инициируются из процедуры подключения драйвера звука. (См. раздел crossref:sound[pcm-probe-and-attach,Обнаружение и подключение]).

	[.programlisting]
	....
	@@ -198,7 +198,7 @@

	==== channel_setblocksize

	-`xxxchannel_setblocksize()` устанавливает размер блока, который является размером единичных транзакций между [.filename]#pcm# и звуковым драйвером, а также между звуковым драйвером и устройством. Обычно это количество байт, передаваемых до возникновения прерывания. Во время передачи звуковой драйвер должен вызывать `chn_intr()` из [.filename]#pcm# каждый раз, когда передается данный размер.
	+`xxxchannel_setblocksize()` устанавливает размер блока, который является размером единичных транзакций между [.filename]#pcm# и звуковым драйвером, а также между звуковым драйвером и устройством. Обычно это количество байт, передаваемых до возникновения прерывания. Во время передачи звуковой драйвер должен вызывать `chn_intr()` из [.filename]#pcm# каждый раз, когда передаётся данный размер.

	Большинство драйверов звука здесь учитывают только размер блока, который будет использоваться при начале фактической передачи.

	diff --git a/documentation/content/ru/books/arch-handbook/sound/_index.po b/documentation/content/ru/books/arch-handbook/sound/_index.po
	--- a/documentation/content/ru/books/arch-handbook/sound/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/sound/_index.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-08-26 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbooksound_index/ru/>\n"
	@@ -169,20 +169,20 @@
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:77
	msgid ""
	"Under [.filename]#/usr/src/sys/dev/sound/#, the [.filename]#pcm/# directory "
	-"holds the central code, while the [.filename]#pci/#, [.filename]#isa/# and "
	-"[.filename]#usb/# directories have the drivers for PCI and ISA boards, and "
	-"for USB audio devices."
	+"holds the central code, while the [.filename]#pci/#, [.filename]#isa/# and [."
	+"filename]#usb/# directories have the drivers for PCI and ISA boards, and for "
	+"USB audio devices."
	msgstr ""
	"В каталоге [.filename]#/usr/src/sys/dev/sound/#, папка [.filename]#pcm/# "
	"содержит основной код, тогда как каталоги [.filename]#pci/#, [.filename]#isa/"
	-"# и [.filename]#usb/# содержат драйверы для плат PCI и ISA, а также для "
	-"USB-аудиоустройств."
	+"# и [.filename]#usb/# содержат драйверы для плат PCI и ISA, а также для USB-"
	+"аудиоустройств."

	#. type: Title ==
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:79
	#, no-wrap
	msgid "Probing, Attaching, etc."
	-msgstr "Обнаружение, присоединение и т.д."
	+msgstr "Обнаружение, подключение и т.д."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:82
	@@ -235,8 +235,7 @@
	" MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);\n"
	msgstr ""
	" DRIVER_MODULE(snd_xxxpci, pci, xxx_driver, pcm_devclass, 0, 0);\n"
	-" MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, "
	-"PCM_PREFVER,PCM_MAXVER);\n"
	+" MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);\n"

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:100
	@@ -249,9 +248,10 @@
	msgstr ""
	"Большинству звуковых драйверов необходимо хранить дополнительную приватную "
	"информацию о своём устройстве. Приватная структура данных обычно выделяется "
	-"в процедуре attach. Её адрес передаётся в [.filename]#pcm# через вызовы "
	-"`pcm_register()` и `mixer_init()`. [.filename]#pcm# позже передаёт обратно "
	-"этот адрес в качестве параметра при вызовах интерфейсов звукового драйвера."
	+"в процедуре подключения (attach). Её адрес передаётся в [.filename]#pcm# "
	+"через вызовы `pcm_register()` и `mixer_init()`. [.filename]#pcm# позже "
	+"передаёт обратно этот адрес в качестве параметра при вызовах интерфейсов "
	+"звукового драйвера."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:103
	@@ -260,10 +260,10 @@
	"to [.filename]#pcm# by calling `mixer_init()`. For a MIXER interface, this "
	"causes in turn a call to crossref:sound[xxxmixer-init,`xxxmixer_init()`]."
	msgstr ""
	-"Подпрограмма подключения звукового драйвера должна объявить свой интерфейс "
	-"MIXER или AC97 для [.filename]#pcm#, вызвав `mixer_init()`. Для интерфейса "
	-"MIXER это, в свою очередь, приводит к вызову crossref:sound[xxxmixer-"
	-"init,`xxxmixer_init()`]."
	+"Процедура подключения (attach) звукового драйвера должна объявить свой "
	+"интерфейс MIXER или AC97 для [.filename]#pcm#, вызвав `mixer_init()`. Для "
	+"интерфейса MIXER это, в свою очередь, приводит к вызову crossref:"
	+"sound[xxxmixer-init,`xxxmixer_init()`]."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:104
	@@ -274,19 +274,19 @@
	"from [.filename]#pcm#, and `nplay` and `nrec` are the number of play and "
	"record channels."
	msgstr ""
	-"Функция подключения драйвера звука объявляет свою общую конфигурацию CHANNEL "
	-"для [.filename]#pcm#, вызывая `pcm_register(dev, sc, nplay, nrec)`, где `sc` "
	-"— это адрес структуры данных устройства, используемый при последующих "
	-"вызовах из [.filename]#pcm#, а `nplay` и `nrec` — количество каналов "
	-"воспроизведения и записи."
	+"Процедура подключения драйвера звука объявляет свою общую конфигурацию "
	+"CHANNEL для [.filename]#pcm#, вызывая `pcm_register(dev, sc, nplay, nrec)`, "
	+"где `sc` — это адрес структуры данных устройства, используемый при "
	+"последующих вызовах из [.filename]#pcm#, а `nplay` и `nrec` — количество "
	+"каналов воспроизведения и записи."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:107
	msgid ""
	"The sound driver attach routine declares each of its channel objects by "
	"calls to `pcm_addchan()`. This sets up the channel glue in [.filename]#pcm# "
	-"and causes in turn a call to crossref:sound[xxxchannel-"
	-"init,`xxxchannel_init()`]."
	+"and causes in turn a call to crossref:sound[xxxchannel-init,"
	+"`xxxchannel_init()`]."
	msgstr ""
	"Подпрограмма подключения звукового драйвера объявляет каждый из своих "
	"каналов вызовами `pcm_addchan()`. Это настраивает связующий слой канала в [."
	@@ -299,8 +299,8 @@
	"The sound driver detach routine should call `pcm_unregister()` before "
	"releasing its resources."
	msgstr ""
	-"Драйвер звука должен вызвать `pcm_unregister()` в процедуре отключения перед "
	-"освобождением своих ресурсов."
	+"Драйвер звука должен вызвать `pcm_unregister()` в процедуре отключения "
	+"(detach) перед освобождением своих ресурсов."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:110
	@@ -320,7 +320,7 @@
	"Используйте метод `device_identify()` (пример: [.filename]#sound/isa/es1888."
	"c#). Метод `device_identify()` проверяет наличие оборудования по известным "
	"адресам и, если находит поддерживаемое устройство, создает новое pcm-"
	-"устройство, которое затем передается для probe/attach."
	+"устройство, которое затем передаётся для probe/attach."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:113
	@@ -338,9 +338,9 @@
	"and `device_shutdown` routines, so that power management and module "
	"unloading function correctly."
	msgstr ""
	-"[.filename]#pcm# драйверы должны реализовывать подпрограммы `device_suspend`"
	-", `device_resume` и `device_shutdown`, чтобы управление питанием и выгрузка "
	-"модулей работали корректно."
	+"[.filename]#pcm# драйверы должны реализовывать подпрограммы "
	+"`device_suspend`, `device_resume` и `device_shutdown`, чтобы управление "
	+"питанием и выгрузка модулей работали корректно."

	#. type: Title ==
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:117
	@@ -371,8 +371,8 @@
	msgid ""
	"The _AC97_ interface is a very small hardware access (register read/write) "
	"interface, implemented by drivers for hardware with an AC97 codec. In this "
	-"case, the actual MIXER interface is provided by the shared AC97 code in "
	-"[.filename]#pcm#."
	+"case, the actual MIXER interface is provided by the shared AC97 code in [."
	+"filename]#pcm#."
	msgstr ""
	"Интерфейс _AC97_ — это очень небольшой интерфейс доступа к оборудованию "
	"(чтение/запись регистров), реализованный драйверами для устройств с кодеком "
	@@ -416,11 +416,11 @@
	msgid ""
	"The second parameter is a pointer to the private channel data structure, "
	"except for `channel_init()` which has a pointer to the private device "
	-"structure (and returns the channel pointer for further use by "
	-"[.filename]#pcm#)."
	+"structure (and returns the channel pointer for further use by [."
	+"filename]#pcm#)."
	msgstr ""
	"Второй параметр представляет собой указатель на приватную структуру данных "
	-"канала, за исключением `channel_init()`, где передается указатель на "
	+"канала, за исключением `channel_init()`, где передаётся указатель на "
	"приватную структуру устройства (и возвращается указатель на канал для "
	"дальнейшего использования [.filename]#pcm#)."

	@@ -436,7 +436,7 @@
	"For sound data transfers, the [.filename]#pcm# core and the sound drivers "
	"communicate through a shared memory area, described by a `struct snd_dbuf`."
	msgstr ""
	-"Для надежной передачи звуковых данных ядро [.filename]#pcm# и драйверы звука "
	+"Для надёжной передачи звуковых данных ядро [.filename]#pcm# и драйверы звука "
	"взаимодействуют через общую область памяти, описываемую структурой `struct "
	"snd_dbuf`."

	@@ -474,9 +474,9 @@
	"driver's crossref:sound[channel-trigger,`xxxchannel_trigger()`] function "
	"with a parameter of PCMTRIG_START."
	msgstr ""
	-"[.filename]#pcm# сначала заполняет буфер, затем вызывает функцию "
	-"crossref:sound[channel-trigger,`xxxchannel_trigger()`] драйвера звука с "
	-"параметром PCMTRIG_START."
	+"[.filename]#pcm# сначала заполняет буфер, затем вызывает функцию crossref:"
	+"sound[channel-trigger,`xxxchannel_trigger()`] драйвера звука с параметром "
	+"PCMTRIG_START."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:149
	@@ -514,12 +514,12 @@
	msgid ""
	"`xxxchannel_init()` is called to initialize each of the play or record "
	"channels. The calls are initiated from the sound driver attach routine. "
	-"(See the crossref:sound[pcm-probe-and-attach,probe and attach section)."
	+"(See the crossref:sound[pcm-probe-and-attach,probe and attach section])."
	msgstr ""
	"`xxxchannel_init()` вызывается для инициализации каждого из каналов "
	-"воспроизведения или записи. Вызовы инициируются из процедуры присоединения "
	-"драйвера звука. (См. раздел crossref:sound[pcm-probe-and-attach,зондирование "
	-"и присоединение])."
	+"воспроизведения или записи. Вызовы инициируются из процедуры подключения "
	+"драйвера звука. (См. раздел crossref:sound[pcm-probe-and-attach,Обнаружение "
	+"и подключение])."

	#. type: delimited block . 4
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:168
	@@ -553,9 +553,8 @@
	"use is normally a small multiple of the 'typical' unit transfer size for "
	"your device.`c` is the [.filename]#pcm# channel control structure pointer. "
	"This is an opaque object. The function should store it in the local channel "
	-"structure, to be used in later calls to [.filename]#pcm# (ie: "
	-"`chn_intr(c)`).`dir` indicates the channel direction (`PCMDIR_PLAY` or "
	-"`PCMDIR_REC`)."
	+"structure, to be used in later calls to [.filename]#pcm# (ie: `chn_intr(c)`)."
	+"`dir` indicates the channel direction (`PCMDIR_PLAY` or `PCMDIR_REC`)."
	msgstr ""
	"`b` — это адрес для канала `struct snd_dbuf`. Он должен быть инициализирован "
	"в функции вызовом `sndbuf_alloc()`. Размер буфера, который следует "
	@@ -605,8 +604,7 @@
	" }\n"
	msgstr ""
	" static int\n"
	-" xxxchannel_setformat(kobj_t obj, void *data, u_int32_t format) <.>"
	-"\n"
	+" xxxchannel_setformat(kobj_t obj, void *data, u_int32_t format) <.>\n"
	" {\n"
	" struct xxx_chinfo *ch = data;\n"
	" ...\n"
	@@ -676,7 +674,7 @@
	"также между звуковым драйвером и устройством. Обычно это количество байт, "
	"передаваемых до возникновения прерывания. Во время передачи звуковой драйвер "
	"должен вызывать `chn_intr()` из [.filename]#pcm# каждый раз, когда "
	-"передается данный размер."
	+"передаётся данный размер."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:211
	@@ -700,8 +698,7 @@
	" }\n"
	msgstr ""
	" static int\n"
	-" xxxchannel_setblocksize(kobj_t obj, void *data, u_int32_t "
	-"blocksize)\n"
	+" xxxchannel_setblocksize(kobj_t obj, void *data, u_int32_t blocksize)\n"
	" {\n"
	" struct xxx_chinfo *ch = data;\n"
	" ...\n"
	@@ -767,8 +764,8 @@
	"things."
	msgstr ""
	"Если драйвер использует ISA DMA, перед выполнением действий с устройством "
	-"следует вызвать `sndbuf_isadma()`, которая позаботится о том, что делает "
	-"DMA-чип."
	+"следует вызвать `sndbuf_isadma()`, которая позаботится о том, что делает DMA-"
	+"чип."

	#. type: Title ====
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:248
	@@ -780,8 +777,8 @@
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:251
	msgid ""
	"`xxxchannel_getptr()` returns the current offset in the transfer buffer. "
	-"This will typically be called by `chn_intr()`, and this is how "
	-"[.filename]#pcm# knows where it can transfer new data."
	+"This will typically be called by `chn_intr()`, and this is how [."
	+"filename]#pcm# knows where it can transfer new data."
	msgstr ""
	"`xxxchannel_getptr()` возвращает текущее смещение в буфере передачи. Обычно "
	"этот вызов выполняется функцией `chn_intr()`, и именно так [.filename]#pcm# "
	@@ -1113,7 +1110,8 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:357
	msgid "`ac97_read()` and `ac97_write()` read or write a specified register."
	-msgstr "`ac97_read()` и `ac97_write()` читают или записывают указанный регистр."
	+msgstr ""
	+"`ac97_read()` и `ac97_write()` читают или записывают указанный регистр."

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/sound/_index.adoc:358
	diff --git a/documentation/content/ru/books/arch-handbook/usb/_index.adoc b/documentation/content/ru/books/arch-handbook/usb/_index.adoc
	--- a/documentation/content/ru/books/arch-handbook/usb/_index.adoc
	+++ b/documentation/content/ru/books/arch-handbook/usb/_index.adoc
	@@ -135,7 +135,7 @@

	Иногда для устройства не является проблемой вернуть меньше данных, чем запрошено. Например, при передаче данных в режиме bulk-in на модем может быть запрошено 200 байт данных, но у модема в данный момент доступно только 5 байт. Драйвер может установить флаг короткого пакета (SPD). Это позволяет хост-контроллеру принять пакет, даже если объем переданных данных меньше запрошенного. Этот флаг действителен только для in-передач, так как объем данных, отправляемых на устройство, всегда известен заранее. Если во время передачи в устройстве происходит неустранимая ошибка, канал останавливается (stalled). Прежде чем принимать или отправлять дополнительные данные, драйвер должен устранить причину остановки и сбросить условие остановки конечной точки, отправив запрос `clear endpoint halt` через канал по умолчанию. Конечная точка по умолчанию никогда не должна останавливаться.

	-Существует четыре различных типа конечных точек и соответствующих каналов: - Управляющий канал / канал по умолчанию: На каждое устройство приходится один управляющий канал, подключенный к конечной точке по умолчанию (конечная точка 0). Этот канал передает запросы устройства и связанные с ними данные. Разница между передачами через канал по умолчанию и другими каналами заключается в том, что протокол для этих передач описан в спецификации USB. Эти запросы используются для сброса и настройки устройства. Базовый набор команд, который должен поддерживаться каждым устройством, приведен в главе 9 спецификации USB. Команды, поддерживаемые на этом канале, могут быть расширены спецификацией класса устройства для обеспечения дополнительной функциональности.
	+Существует четыре различных типа конечных точек и соответствующих каналов: - Управляющий канал / канал по умолчанию: На каждое устройство приходится один управляющий канал, подключенный к конечной точке по умолчанию (конечная точка 0). Этот канал передаёт запросы устройства и связанные с ними данные. Разница между передачами через канал по умолчанию и другими каналами заключается в том, что протокол для этих передач описан в спецификации USB. Эти запросы используются для сброса и настройки устройства. Базовый набор команд, который должен поддерживаться каждым устройством, приведен в главе 9 спецификации USB. Команды, поддерживаемые на этом канале, могут быть расширены спецификацией класса устройства для обеспечения дополнительной функциональности.

	* Массовый канал: Это USB-эквивалент среды передачи данных в сыром виде.
	* Прерывающий канал: Хост отправляет запрос данных на устройство, и если устройству нечего отправлять, оно отвечает NAK на пакет данных. Прерывающие передачи планируются с частотой, указанной при создании канала.
	diff --git a/documentation/content/ru/books/arch-handbook/usb/_index.po b/documentation/content/ru/books/arch-handbook/usb/_index.po
	--- a/documentation/content/ru/books/arch-handbook/usb/_index.po
	+++ b/documentation/content/ru/books/arch-handbook/usb/_index.po
	@@ -5,8 +5,8 @@
	msgid ""
	msgstr ""
	"Project-Id-Version: FreeBSD Documentation VERSION\n"
	-"POT-Creation-Date: 2025-05-01 19:56-0300\n"
	-"PO-Revision-Date: 2025-07-12 04:45+0000\n"
	+"POT-Creation-Date: 2025-11-08 16:17+0000\n"
	+"PO-Revision-Date: 2025-11-12 04:45+0000\n"
	"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
	"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
	"documentation/booksarch-handbookusb_index/ru/>\n"
	@@ -170,15 +170,15 @@
	"USB 2.0 Specification (http://www.usb.org/developers/docs/usb20_docs/[http://"
	"www.usb.org/developers/docs/usb20_docs/])"
	msgstr ""
	-"Спецификация USB 2.0 (http://www.usb.org/developers/docs/usb20_docs/"
	-"[http://www.usb.org/developers/docs/usb20_docs/])"
	+"Спецификация USB 2.0 (http://www.usb.org/developers/docs/usb20_docs/[http://"
	+"www.usb.org/developers/docs/usb20_docs/])"

	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/usb/_index.adoc:69
	msgid ""
	-"Universal Host Controller Interface (UHCI) Specification (link:ftp://"
	-"ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf[ftp://ftp.netbsd.org/pub/"
	-"NetBSD/misc/blymn/uhci11d.pdf)]"
	+"Universal Host Controller Interface (UHCI) Specification (link:ftp://ftp."
	+"netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf[ftp://ftp.netbsd.org/pub/NetBSD/"
	+"misc/blymn/uhci11d.pdf])"
	msgstr ""
	"Универсальный интерфейс хост-контроллера (UHCI) Спецификация (link:ftp://ftp."
	"netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf[ftp://ftp.netbsd.org/pub/NetBSD/"
	@@ -187,9 +187,9 @@
	#. type: Plain text
	#: documentation/content/en/books/arch-handbook/usb/_index.adoc:70
	msgid ""
	-"Open Host Controller Interface (OHCI) Specification(link:ftp://"
	-"ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf[ftp://"
	-"ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf])"
	+"Open Host Controller Interface (OHCI) Specification(link:ftp://ftp.compaq."
	+"com/pub/supportinformation/papers/hcir1_0a.pdf[ftp://ftp.compaq.com/pub/"
	+"supportinformation/papers/hcir1_0a.pdf])"
	msgstr ""
	"Спецификация интерфейса Open Host Controller (OHCI)(link:ftp://ftp.compaq."
	"com/pub/supportinformation/papers/hcir1_0a.pdf[ftp://ftp.compaq.com/pub/"
	@@ -256,8 +256,8 @@
	"(классы) устройств. Эти драйверы реализуют протокол, используемый в каналах, "
	"отличных от стандартного. Они также реализуют дополнительную "
	"функциональность для обеспечения доступа к устройству другим частям ядра или "
	-"пользовательского пространства. Они используют интерфейс драйвера USB (USBDI)"
	-", предоставляемый уровнем сервисов."
	+"пользовательского пространства. Они используют интерфейс драйвера USB "
	+"(USBDI), предоставляемый уровнем сервисов."

	#. type: Title ==
	#: documentation/content/en/books/arch-handbook/usb/_index.adoc:81
	@@ -338,27 +338,28 @@
	"a more abstract interface doing a lot of work themselves."
	msgstr ""
	"Запросы устройств (управляющие передачи) к конечным точкам по умолчанию "
	-"являются особыми. Они состоят из двух или трёх фаз: SETUP, DATA (опционально)"
	-" и STATUS. Пакет настройки отправляется на устройство. Если присутствует "
	-"фаза данных, направление пакета(ов) данных указывается в пакете настройки. "
	-"Направление в фазе статуса противоположно направлению во время фазы данных "
	-"или IN, если фазы данных не было. Аппаратное обеспечение хост-контроллера "
	-"также предоставляет регистры с текущим состоянием корневых портов и "
	-"изменениями, произошедшими с момента последнего сброса регистра изменений "
	-"статуса. Доступ к этим регистрам предоставляется через виртуализированный "
	-"концентратор, как предложено в спецификации USB. Виртуальный концентратор "
	-"должен соответствовать классу устройств концентратора, указанному в главе 11 "
	-"этой спецификации. Он должен предоставлять канал по умолчанию, через который "
	-"можно отправлять запросы устройств. Он возвращает стандартные и специфичные "
	-"для класса концентратора наборы дескрипторов. Также он должен предоставлять "
	-"прерывающий канал, сообщающий об изменениях, происходящих на его портах. В "
	-"настоящее время доступны две спецификации для хост-контроллеров: - Universal "
	-"Host Controller Interface (UHCI) от Intel и Open Host Controller Interface "
	-"(OHCI) от Compaq, Microsoft и National Semiconductor. Спецификация UHCI "
	-"разработана для уменьшения аппаратной сложности, требуя от драйвера хост-"
	-"контроллера предоставления полного расписания передач для каждого кадра. "
	-"Контроллеры типа OHCI гораздо более независимы, предоставляя более "
	-"абстрактный интерфейс и выполняя большую часть работы самостоятельно."
	+"являются особыми. Они состоят из двух или трёх фаз: SETUP, DATA "
	+"(опционально) и STATUS. Пакет настройки отправляется на устройство. Если "
	+"присутствует фаза данных, направление пакета(ов) данных указывается в пакете "
	+"настройки. Направление в фазе статуса противоположно направлению во время "
	+"фазы данных или IN, если фазы данных не было. Аппаратное обеспечение хост-"
	+"контроллера также предоставляет регистры с текущим состоянием корневых "
	+"портов и изменениями, произошедшими с момента последнего сброса регистра "
	+"изменений статуса. Доступ к этим регистрам предоставляется через "
	+"виртуализированный концентратор, как предложено в спецификации USB. "
	+"Виртуальный концентратор должен соответствовать классу устройств "
	+"концентратора, указанному в главе 11 этой спецификации. Он должен "
	+"предоставлять канал по умолчанию, через который можно отправлять запросы "
	+"устройств. Он возвращает стандартные и специфичные для класса концентратора "
	+"наборы дескрипторов. Также он должен предоставлять прерывающий канал, "
	+"сообщающий об изменениях, происходящих на его портах. В настоящее время "
	+"доступны две спецификации для хост-контроллеров: - Universal Host Controller "
	+"Interface (UHCI) от Intel и Open Host Controller Interface (OHCI) от Compaq, "
	+"Microsoft и National Semiconductor. Спецификация UHCI разработана для "
	+"уменьшения аппаратной сложности, требуя от драйвера хост-контроллера "
	+"предоставления полного расписания передач для каждого кадра. Контроллеры "
	+"типа OHCI гораздо более независимы, предоставляя более абстрактный интерфейс "
	+"и выполняя большую часть работы самостоятельно."

	#. type: Title ===
	#: documentation/content/en/books/arch-handbook/usb/_index.adoc:91
	@@ -662,8 +663,8 @@
	msgstr ""
	"Дескрипторы конечных точек: Адрес конечной точки, направление и тип, "
	"максимальный поддерживаемый размер пакета и частота опроса, если тип "
	-"является конечной точкой прерывания. Для конечной точки по умолчанию ("
	-"конечная точка 0) дескриптора не существует, и она никогда не учитывается в "
	+"является конечной точкой прерывания. Для конечной точки по умолчанию "
	+"(конечная точка 0) дескриптора не существует, и она никогда не учитывается в "
	"дескрипторе интерфейса."

	#. type: Plain text
	@@ -706,8 +707,8 @@
	"Канальный обмен данными с конечными точками устройства осуществляется через "
	"так называемые каналы. Драйверы передают данные конечным точкам через "
	"канал и предоставляют функцию обратного вызова, которая вызывается при "
	-"завершении или сбое передачи (асинхронные передачи) или ожидают завершения ("
	-"синхронная передача). Передачи данных в конечную точку сериализуются в "
	+"завершении или сбое передачи (асинхронные передачи) или ожидают завершения "
	+"(синхронная передача). Передачи данных в конечную точку сериализуются в "
	"канале. Передача может завершиться успешно, завершиться с ошибкой или "
	"превысить время ожидания (если оно было задано). Существует два типа "
	"таймаутов для передач. Таймауты могут происходить из-за истечения времени на "
	@@ -778,7 +779,7 @@
	"Существует четыре различных типа конечных точек и соответствующих каналов: - "
	"Управляющий канал / канал по умолчанию: На каждое устройство приходится один "
	"управляющий канал, подключенный к конечной точке по умолчанию (конечная "
	-"точка 0). Этот канал передает запросы устройства и связанные с ними данные. "
	+"точка 0). Этот канал передаёт запросы устройства и связанные с ними данные. "
	"Разница между передачами через канал по умолчанию и другими каналами "
	"заключается в том, что протокол для этих передач описан в спецификации USB. "
	"Эти запросы используются для сброса и настройки устройства. Базовый набор "
	@@ -1025,8 +1026,8 @@
	msgid ""
	"For many devices the protocol information has not yet been published "
	"however. Information on the protocol being used might be available from the "
	-"company making the device. Some companies will require you to sign a Non "
	-"-Disclosure Agreement (NDA) before giving you the specifications. This in "
	+"company making the device. Some companies will require you to sign a Non -"
	+"Disclosure Agreement (NDA) before giving you the specifications. This in "
	"most cases precludes making the driver open source."
	msgstr ""
	"Для многих устройств информация о протоколе ещё не опубликована. Сведения об "

File Metadata

Mime Type: text/plain
Expires: Wed, Jul 22, 3:50 PM (6 h, 58 m)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 35370704
Default Alt Text: D53717.id.diff (207 KB)

D53717.id.diffNo OneTemporaryActions

D53717.id.diffView Options

File Metadata

Event Timeline

D53717.id.diff
No OneTemporary
Actions

D53717.id.diff
View Options