Date: Sun, 15 Mar 2026 12:01:07 +0000 From: Vladlen Popolitov <vladlen@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: c0ce4b4861 - main - update translation of books/arch-handbook to Russian Message-ID: <69b69f83.3082b.2fe9e4de@gitrepo.freebsd.org>
index | next in thread | raw e-mail
The branch main has been updated by vladlen: URL: https://cgit.FreeBSD.org/doc/commit/?id=c0ce4b4861e07028ed289a510bf966cf242b4deb commit c0ce4b4861e07028ed289a510bf966cf242b4deb Author: Vladlen Popolitov <vladlen@FreeBSD.org> AuthorDate: 2026-03-15 12:00:55 +0000 Commit: Vladlen Popolitov <vladlen@FreeBSD.org> CommitDate: 2026-03-15 12:00:55 +0000 update translation of books/arch-handbook to Russian Differential Revision: https://reviews.freebsd.org/D55723 --- .../ru/books/arch-handbook/boot/_index.adoc | 20 +- .../content/ru/books/arch-handbook/boot/_index.po | 34 +-- .../books/arch-handbook/driverbasics/_index.adoc | 2 +- .../ru/books/arch-handbook/driverbasics/_index.po | 4 +- .../content/ru/books/arch-handbook/isa/_index.adoc | 6 +- .../content/ru/books/arch-handbook/isa/_index.po | 10 +- .../ru/books/arch-handbook/jail/_index.adoc | 8 +- .../content/ru/books/arch-handbook/jail/_index.po | 26 +- .../ru/books/arch-handbook/kobj/_index.adoc | 2 +- .../content/ru/books/arch-handbook/kobj/_index.po | 10 +- .../content/ru/books/arch-handbook/mac/_index.adoc | 262 ++++++++++----------- .../content/ru/books/arch-handbook/mac/_index.po | 130 +++++----- .../ru/books/arch-handbook/pccard/_index.adoc | 4 +- .../ru/books/arch-handbook/pccard/_index.po | 10 +- .../ru/books/arch-handbook/scsi/_index.adoc | 14 +- .../content/ru/books/arch-handbook/scsi/_index.po | 18 +- .../content/ru/books/arch-handbook/smp/_index.adoc | 16 +- .../content/ru/books/arch-handbook/smp/_index.po | 38 +-- .../ru/books/arch-handbook/sysinit/_index.adoc | 2 +- .../ru/books/arch-handbook/sysinit/_index.po | 6 +- .../content/ru/books/arch-handbook/usb/_index.adoc | 6 +- .../content/ru/books/arch-handbook/usb/_index.po | 12 +- .../content/ru/books/arch-handbook/vm/_index.adoc | 6 +- .../content/ru/books/arch-handbook/vm/_index.po | 8 +- 24 files changed, 327 insertions(+), 327 deletions(-) diff --git a/documentation/content/ru/books/arch-handbook/boot/_index.adoc b/documentation/content/ru/books/arch-handbook/boot/_index.adoc index 43dacd74c7..abfcf1feaa 100644 --- a/documentation/content/ru/books/arch-handbook/boot/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/boot/_index.adoc @@ -53,7 +53,7 @@ endif::[] Эта глава представляет собой обзор процессов загрузки и инициализации системы, начиная с POST в BIOS (микропрограмме) и заканчивая созданием первого пользовательского процесса. Поскольку начальные этапы загрузки системы сильно зависят от архитектуры, в качестве примера используется архитектура IA-32. Однако архитектуры AMD64 и ARM64 гораздо важнее и интереснее, и их следует рассмотреть в ближайшем будущем в соответствии с темой этого документа. -Процесс загрузки FreeBSD может быть удивительно сложным. После передачи управления от BIOS необходимо выполнить значительный объем низкоуровневой настройки перед загрузкой и выполнением ядра. Эта настройка должна быть выполнена простым и гибким способом, предоставляя пользователю широкие возможности для настройки и адаптации. +Процесс загрузки FreeBSD может быть удивительно сложным. После передачи управления от BIOS необходимо выполнить значительный объём низкоуровневой настройки перед загрузкой и выполнением ядра. Эта настройка должна быть выполнена простым и гибким способом, предоставляя пользователю широкие возможности для настройки и адаптации. [[boot-overview]] == Обзор @@ -131,9 +131,9 @@ FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0. Значение `0xfffffff0` немного меньше 4 ГБ, поэтому, если в машине нет 4 ГБ физической памяти, оно не может указывать на действительный адрес памяти. Аппаратное обеспечение компьютера преобразует этот адрес так, чтобы он указывал на блок памяти BIOS. -BIOS (Basic Input Output System) — это микросхема на материнской плате, которая содержит относительно небольшой объем памяти только для чтения (ROM). Эта память включает различные низкоуровневые процедуры, специфичные для оборудования, поставляемого с материнской платой. Процессор сначала переходит по адресу 0xfffffff0, который фактически находится в памяти BIOS. Обычно по этому адресу содержится инструкция перехода к процедурам POST BIOS. +BIOS (Basic Input Output System) — это микросхема на материнской плате, которая содержит относительно небольшой объём памяти только для чтения (ROM). Эта память включает различные низкоуровневые процедуры, специфичные для оборудования, поставляемого с материнской платой. Процессор сначала переходит по адресу 0xfffffff0, который фактически находится в памяти BIOS. Обычно по этому адресу содержится инструкция перехода к процедурам POST BIOS. -POST (Power On Self Test) — это набор процедур, включающих проверку памяти, проверку системной шины и другую низкоуровневую инициализацию, чтобы процессор мог правильно настроить компьютер. Важным этапом на этой стадии является определение загрузочного устройства. Современные реализации BIOS позволяют выбирать загрузочное устройство, обеспечивая загрузку с дискеты, CD-ROM, жесткого диска или других устройств. +POST (Power On Self Test) — это набор процедур, включающих проверку памяти, проверку системной шины и другую низкоуровневую инициализацию, чтобы процессор мог правильно настроить компьютер. Важным этапом на этой стадии является определение загрузочного устройства. Современные реализации BIOS позволяют выбирать загрузочное устройство, обеспечивая загрузку с дискеты, CD-ROM, жёсткого диска или других устройств. Самым последним действием в POST является инструкция `INT 0x19`. Обработчик `INT 0x19` считывает 512 байт из первого сектора загрузочного устройства в память по адресу `0x7c00`. Термин _первый сектор_ происходит из архитектуры жёстких дисков, где магнитная пластина разделена на множество цилиндрических дорожек. Дорожки нумеруются, и каждая дорожка разделена на несколько (обычно 64) секторов. Нумерация дорожек начинается с 0, но нумерация секторов начинается с 1. Дорожка 0 находится на внешней стороне магнитной пластины, а сектор 1, первый сектор, имеет собое назначение. Он также называется MBR (Master Boot Record) или Главная Загрузочная Запись. Остальные секторы на первой дорожке не используются. @@ -368,7 +368,7 @@ read_key: * 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. @@ -402,7 +402,7 @@ main: .[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-main]] Как и [.filename]#boot0#, этот код перемещает [.filename]#boot1#, на этот раз по адресу `0x700`. Однако, в отличие от [.filename]#boot0#, он не переходит туда. [.filename]#boot1# скомпонован для выполнения по адресу `0x7c00`, фактически там, куда он был изначально загружен. Причина этого перемещения будет рассмотрена далее. -Далее идет цикл, который ищет слайс FreeBSD. Хотя [.filename]#boot0# загрузил [.filename]#boot1# из слайса FreeBSD, ему не была передана информация об этом footnote:[На самом деле мы передали указатель на адрес слайса в регистре %si. Однако boot1 не предполагает, что он был загружен boot0 (возможно, его загрузил другой MBR и не передал эту информацию), поэтому он ничего не предполагает.], поэтому [.filename]#boot1# должен повторно просканировать таблицу разделов, чтобы найти начало слайса FreeBSD. Для этого он перечитывает MBR: +Далее идёт цикл, который ищет слайс FreeBSD. Хотя [.filename]#boot0# загрузил [.filename]#boot1# из слайса FreeBSD, ему не была передана информация об этом footnote:[На самом деле мы передали указатель на адрес слайса в регистре %si. Однако boot1 не предполагает, что он был загружен boot0 (возможно, его загрузил другой MBR и не передал эту информацию), поэтому он ничего не предполагает.], поэтому [.filename]#boot1# должен повторно просканировать таблицу разделов, чтобы найти начало слайса FreeBSD. Для этого он перечитывает MBR: [.programlisting] .... @@ -426,7 +426,7 @@ main: .... .[.filename]#stand/i386/boot2/boot1.S# [[boot-boot2-make-fake-partition]] -В частности, LBA для этой фиктивной раздела жестко закодирован как ноль. Это используется как аргумент для BIOS при чтении абсолютного сектора один с жесткого диска. Альтернативно, может использоваться адресация CHS. В этом случае, фиктивный раздел содержит цилиндр 0, головку 0 и сектор 1, что эквивалентно абсолютному сектору один. +В частности, LBA для этой фиктивной раздела жёстко закодирован как ноль. Это используется как аргумент для BIOS при чтении абсолютного сектора один с жёсткого диска. Или же может использоваться адресация CHS. В этом случае фиктивный раздел содержит цилиндр 0, головку 0 и сектор 1, что эквивалентно абсолютному сектору один. Продолжим, рассмотрев `nread`: @@ -802,7 +802,7 @@ init.8: xorl %ecx,%ecx # Zero .... .[.filename]#stand/i386/btx/btx/btx.S# [[btx-prot]] -Сначала вызывается `setpic` для программирования 8259A PIC (программируемого контроллера прерываний). Этот чип подключен к нескольким источникам аппаратных прерываний. При получении прерывания от устройства он сигнализирует процессору соответствующим вектором прерывания. Это можно настроить так, чтобы определенные прерывания были связаны с конкретными векторами прерываний, как объяснялось ранее. Затем регистры IDTR (Interrupt Descriptor Table Register) и GDTR (Global Descriptor Table Register) загружаются инструкциями `lidt` и `lgdt` соответственно. Эти регистры загружаются б зовым адресом и предельным адресом для IDT и GDT. Следующие три инструкции устанавливают бит Protection Enable (PE) в регистре `%cr0`. Это фактически переключает процессор в 32-битный защищенный режим. Затем выполняется дальний переход на `init.8` с использованием селектора сегмента SEL_SCODE, который выбирает сегмент кода супервизора (Supervisor Code Segment). После этого перехода процессор фактически работает на уровне CPL 0 — наиболее привилегированном уровне. Наконец, для стека выбирается сегмент данных супервизора (Supervisor Data Segment) путем присвоения селектора сегмент а SEL_SDATA регистру `%ss`. Этот сегмент данных также имеет уровень привилегий `0`. +Сначала вызывается `setpic` для программирования 8259A PIC (программируемого контроллера прерываний). Этот чип подключен к нескольким источникам аппаратных прерываний. При получении прерывания от устройства он сигнализирует процессору соответствующим вектором прерывания. Это можно настроить так, чтобы определённые прерывания были связаны с конкретными векторами прерываний, как объяснялось ранее. Затем регистры IDTR (Interrupt Descriptor Table Register) и GDTR (Global Descriptor Table Register) загружаются инструкциями `lidt` и `lgdt` соответственно. Эти регистры загружаются б зовым адресом и предельным адресом для IDT и GDT. Следующие три инструкции устанавливают бит Protection Enable (PE) в регистре `%cr0`. Это фактически переключает процессор в 32-битный защищенный режим. Затем выполняется дальний переход на `init.8` с использованием селектора сегмента SEL_SCODE, который выбирает сегмент кода супервизора (Supervisor Code Segment). После этого перехода процессор фактически работает на уровне CPL 0 — наиболее привилегированном уровне. Наконец, для стека выбирается сегмент данных супервизора (Supervisor Data Segment) путем присвоения селектора сегмент а SEL_SDATA регистру `%ss`. Этот сегмент данных также имеет уровень привилегий `0`. Наш последний блок кода отвечает за загрузку TR (Регистра Задач) с селектором сегмента для TSS, который мы создали ранее, и настройку окружения пользовательского режима перед передачей управления исполнения клиенту [.filename]#boot2#. @@ -851,7 +851,7 @@ init.9: push $0x0 # general [[boot2]] == Этап загрузки boot2 -`boot2` определяет важную структуру, `struct bootinfo`. Эта структура инициализируется `boot2` и передаётся загрузчику, а затем ядру. Некоторые узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта структура, среди прочей информации, содержит имя файла ядра, геометрию жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, доступную физическую память, указатель `envp` и т.д. Ее определение выглядит так: +`boot2` определяет важную структуру, `struct bootinfo`. Эта структура инициализируется `boot2` и передаётся загрузчику, а затем ядру. Некоторые узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта структура, среди прочей информации, содержит имя файла ядра, геометрию жёсткого диска в BIOS, номер диска в BIOS для загрузочного устройства, доступную физическую память, указатель `envp` и т.д. Ее определение выглядит так: [.programlisting] .... @@ -1064,7 +1064,7 @@ sys/kern/subr_param.c: Sysctl `kern.hz` представляет собой такт системных часов. Кроме того, эти параметры sysctl устанавливаются функцией `init_param1()`: `kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz`. Затем `init386()` подготавливает Глобальную Таблицу Дескрипторов -(GDT). Каждая задача на x86 выполняется в своем собственном виртуальном +(GDT). Каждая задача на x86 выполняется в своём собственном виртуальном адресном пространстве, и это пространство адресуется парой сегмент:смещение. Например, если текущая инструкция, которую должен выполнить процессор, находится по адресу CS:EIP, то линейный виртуальный @@ -1145,7 +1145,7 @@ sys/i386/i386/machdep.c: #endif .... -Сегмент состояния задачи (TSS) — это еще одна структура защищенного режима x86, используемая оборудованием для хранения информации о задаче при переключении задач. +Сегмент состояния задачи (TSS) — это ещё одна структура защищенного режима x86, используемая оборудованием для хранения информации о задаче при переключении задач. Локальная таблица дескрипторов (LDT) используется для ссылки на код и данные пользовательского пространства. Определено несколько селекторов, указывающих на LDT, включая шлюзы системных вызовов, а также селекторы кода и данных пользователя: diff --git a/documentation/content/ru/books/arch-handbook/boot/_index.po b/documentation/content/ru/books/arch-handbook/boot/_index.po index 863c740fc1..8d2920051f 100644 --- a/documentation/content/ru/books/arch-handbook/boot/_index.po +++ b/documentation/content/ru/books/arch-handbook/boot/_index.po @@ -1,12 +1,12 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025. +# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2025-11-12 04:45+0000\n" +"PO-Revision-Date: 2026-03-05 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" @@ -65,7 +65,7 @@ msgid "" "customization possibilities." msgstr "" "Процесс загрузки FreeBSD может быть удивительно сложным. После передачи " -"управления от BIOS необходимо выполнить значительный объем низкоуровневой " +"управления от BIOS необходимо выполнить значительный объём низкоуровневой " "настройки перед загрузкой и выполнением ядра. Эта настройка должна быть " "выполнена простым и гибким способом, предоставляя пользователю широкие " "возможности для настройки и адаптации." @@ -333,9 +333,9 @@ msgid "" "jump instruction to the BIOS's POST routines." msgstr "" "BIOS (Basic Input Output System) — это микросхема на материнской плате, " -"которая содержит относительно небольшой объем памяти только для чтения " -"(ROM). Эта память включает различные низкоуровневые процедуры, специфичные " -"для оборудования, поставляемого с материнской платой. Процессор сначала " +"которая содержит относительно небольшой объём памяти только для чтения (ROM)" +". Эта память включает различные низкоуровневые процедуры, специфичные для " +"оборудования, поставляемого с материнской платой. Процессор сначала " "переходит по адресу 0xfffffff0, который фактически находится в памяти BIOS. " "Обычно по этому адресу содержится инструкция перехода к процедурам POST BIOS." @@ -354,7 +354,7 @@ msgstr "" "процессор мог правильно настроить компьютер. Важным этапом на этой стадии " "является определение загрузочного устройства. Современные реализации BIOS " "позволяют выбирать загрузочное устройство, обеспечивая загрузку с дискеты, " -"CD-ROM, жесткого диска или других устройств." +"CD-ROM, жёсткого диска или других устройств." #. type: Plain text #: documentation/content/en/books/arch-handbook/boot/_index.adoc:179 @@ -1307,7 +1307,7 @@ msgid "" "and transferring control to it." msgstr "" "[.filename]#boot1# — это следующий шаг в последовательности загрузки. Это " -"первая из трех стадий загрузки. Обратите внимание, что до сих пор мы " +"первая из трёх стадий загрузки. Обратите внимание, что до сих пор мы " "работали исключительно с секторами диска. Действительно, BIOS загружает " "самый первый сектор, а [.filename]#boot0# загружает первый сектор раздела " "FreeBSD. Обе загрузки происходят по адресу `0x7c00`. Мы можем концептуально " @@ -1438,7 +1438,7 @@ msgid "" "rescan the partition table to find where the FreeBSD slice starts. " "Therefore it rereads the MBR:" msgstr "" -"Далее идет цикл, который ищет слайс FreeBSD. Хотя [.filename]#boot0# " +"Далее идёт цикл, который ищет слайс FreeBSD. Хотя [.filename]#boot0# " "загрузил [.filename]#boot1# из слайса FreeBSD, ему не была передана " "информация об этом footnote:[На самом деле мы передали указатель на адрес " "слайса в регистре %si. Однако boot1 не предполагает, что он был загружен " @@ -1519,11 +1519,11 @@ msgid "" "fake partition holds cylinder 0, head 0 and sector 1, which is equivalent to " "absolute sector one." msgstr "" -"В частности, LBA для этой фиктивной раздела жестко закодирован как ноль. Это " +"В частности, LBA для этой фиктивной раздела жёстко закодирован как ноль. Это " "используется как аргумент для BIOS при чтении абсолютного сектора один с " -"жесткого диска. Альтернативно, может использоваться адресация CHS. В этом " -"случае, фиктивный раздел содержит цилиндр 0, головку 0 и сектор 1, что " -"эквивалентно абсолютному сектору один." +"жёсткого диска. Или же может использоваться адресация CHS. В этом случае " +"фиктивный раздел содержит цилиндр 0, головку 0 и сектор 1, что эквивалентно " +"абсолютному сектору один." #. type: Plain text #: documentation/content/en/books/arch-handbook/boot/_index.adoc:591 @@ -2904,7 +2904,7 @@ msgstr "" "контроллера прерываний). Этот чип подключен к нескольким источникам " "аппаратных прерываний. При получении прерывания от устройства он " "сигнализирует процессору соответствующим вектором прерывания. Это можно " -"настроить так, чтобы определенные прерывания были связаны с конкретными " +"настроить так, чтобы определённые прерывания были связаны с конкретными " "векторами прерываний, как объяснялось ранее. Затем регистры IDTR (Interrupt " "Descriptor Table Register) и GDTR (Global Descriptor Table Register) " "загружаются инструкциями `lidt` и `lgdt` соответственно. Эти регистры " @@ -3110,7 +3110,7 @@ msgstr "" "инициализируется `boot2` и передаётся загрузчику, а затем ядру. Некоторые " "узлы этой структуры устанавливаются `boot2`, остальные — загрузчиком. Эта " "структура, среди прочей информации, содержит имя файла ядра, геометрию " -"жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, " +"жёсткого диска в BIOS, номер диска в BIOS для загрузочного устройства, " "доступную физическую память, указатель `envp` и т.д. Ее определение выглядит " "так:" @@ -3696,7 +3696,7 @@ msgid "" "selector). FreeBSD's GDT holds descriptors for 15 selectors per CPU:" msgstr "" "Затем `init386()` подготавливает Глобальную Таблицу Дескрипторов (GDT). " -"Каждая задача на x86 выполняется в своем собственном виртуальном адресном " +"Каждая задача на x86 выполняется в своём собственном виртуальном адресном " "пространстве, и это пространство адресуется парой сегмент:смещение. " "Например, если текущая инструкция, которую должен выполнить процессор, " "находится по адресу CS:EIP, то линейный виртуальный адрес этой инструкции " @@ -3887,7 +3887,7 @@ msgid "" "The Task State Segment is another x86 protected mode structure, the TSS is " "used by the hardware to store task information when a task switch occurs." msgstr "" -"Сегмент состояния задачи (TSS) — это еще одна структура защищенного режима " +"Сегмент состояния задачи (TSS) — это ещё одна структура защищенного режима " "x86, используемая оборудованием для хранения информации о задаче при " "переключении задач." diff --git a/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc b/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc index aacb879d84..bdd854cf6b 100644 --- a/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/driverbasics/_index.adoc @@ -140,7 +140,7 @@ KMOD=skeleton [[driverbasics-char]] == Символьные устройства -Драйвер символьного устройства — это драйвер, который передаёт данные напрямую между устройством и пользовательским процессом. Это наиболее распространенный тип драйвера устройств, и в дереве исходного кода есть множество простых примеров. +Драйвер символьного устройства — это драйвер, который передаёт данные напрямую между устройством и пользовательским процессом. Это наиболее распространённый тип драйвера устройств, и в дереве исходного кода есть множество простых примеров. Этот простой пример псевдоустройства запоминает все значения, записанные в него, и может затем воспроизводить их при чтении. diff --git a/documentation/content/ru/books/arch-handbook/driverbasics/_index.po b/documentation/content/ru/books/arch-handbook/driverbasics/_index.po index 57748f9514..3116e73e78 100644 --- a/documentation/content/ru/books/arch-handbook/driverbasics/_index.po +++ b/documentation/content/ru/books/arch-handbook/driverbasics/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-05-01 19:56-0300\n" -"PO-Revision-Date: 2025-11-12 04:45+0000\n" +"PO-Revision-Date: 2025-11-20 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" @@ -306,7 +306,7 @@ msgid "" msgstr "" "Драйвер символьного устройства — это драйвер, который передаёт данные " "напрямую между устройством и пользовательским процессом. Это наиболее " -"распространенный тип драйвера устройств, и в дереве исходного кода есть " +"распространённый тип драйвера устройств, и в дереве исходного кода есть " "множество простых примеров." #. type: Plain text diff --git a/documentation/content/ru/books/arch-handbook/isa/_index.adoc b/documentation/content/ru/books/arch-handbook/isa/_index.adoc index 61caf17b2a..a36105d19f 100644 --- a/documentation/content/ru/books/arch-handbook/isa/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/isa/_index.adoc @@ -340,7 +340,7 @@ flags - уровень приоритета прерывания, один из: Сначала может быть выделен (а затем освобожден) блок непрерывной памяти, соответствующий требованиям тега. Обычно это используется для выделения относительно долгоживущих областей памяти для взаимодействия с устройством. Загрузка такой памяти в карту тривиальна: она всегда рассматривается как один блок в соответствующем диапазоне физической памяти. -Второй момент: произвольная область виртуальной памяти может быть загружена в карту. Каждая страница этой памяти будет проверяться на соответствие требованиям карты. Если она соответствует, то остается на своем исходном месте. Если нет, то выделяется новая соответствующая промежуточная страница (bounce page), которая используется как промежуточное хранилище. При записи данных с несоответствующих исходных страниц они сначала копируются на свои промежуточные страницы, а затем передаются с промежуточных страниц на устройство. При чтении данные поступают с устройства на промежуточные страницы, а затем копируются на свои несоответствующие исходные страницы. Процесс копирования между исходными и промежуточными страницами называется синхронизацией. Обычно это используется для каждой передачи: буфер для каждой передачи загружается, передача выполняется, и буфер выгружается. +Второй момент: произвольная область виртуальной памяти может быть загружена в карту. Каждая страница этой памяти будет проверяться на соответствие требованиям карты. Если она соответствует, то остаётся на своём исходном месте. Если нет, то выделяется новая соответствующая промежуточная страница (bounce page), которая используется как промежуточное хранилище. При записи данных с несоответствующих исходных страниц они сначала копируются на свои промежуточные страницы, а затем передаются с промежуточных страниц на устройство. При чтении данные поступают с устройства на промежуточные страницы, а затем копируются на свои несоответствующие исходные страницы. Процесс копирования между исходными и промежуточными страницами называется синхронизацией. Обычно это используется для каждой передачи: буфер для каждой передачи загружается, передача выполняется, и буфер выгружается. Функции, работающие с памятью DMA: @@ -463,7 +463,7 @@ dmat - тег, который должен быть уничтожен. Ниже представлены типичные последовательности вызовов при использовании карты в зависимости от её назначения. Символы -> используются для обозначения последовательности во времени. -Для буфера, который остается практически неизменным в течение всего времени между присоединением и отсоединением устройства: +Для буфера, который остаётся практически неизменным в течение всего времени между присоединением и отсоединением устройства: bus_dmamem_alloc -> bus_dmamap_load -> ...use buffer... -> -> bus_dmamap_unload -> bus_dmamem_free @@ -711,7 +711,7 @@ bus_dmamem_alloc -> bus_dmamap_load -> ...use buffer... -> -> bus_dmamap_unload return ENXIO; .... -Конечно, обычно для таких вещей следует использовать процедуру `identify()` драйвера. Однако может быть одна веская причина, почему лучше сделать это в `probe()`: если этот обнаружение может привести к сбою другого чувствительного устройства. Процедуры обнаружения упорядочены с учетом флага `sensitive`: чувствительные устройства проверяются первыми, а остальные устройства — позже. Но процедуры `identify()` вызываются до любого обнаружения, поэтому они не учитывают чувствительные устройства и могут вызвать их сбой. +Конечно, обычно для таких вещей следует использовать процедуру `identify()` драйвера. Однако может быть одна веская причина, почему лучше сделать это в `probe()`: если этот обнаружение может привести к сбою другого чувствительного устройства. Процедуры обнаружения упорядочены с учётом флага `sensitive`: чувствительные устройства проверяются первыми, а остальные устройства — позже. Но процедуры `identify()` вызываются до любого обнаружения, поэтому они не учитывают чувствительные устройства и могут вызвать их сбой. Вот, после того как мы получили начальный порт, необходимо установить количество портов (за исключением устройств PnP), так как в файле конфигурации ядра эта информация отсутствует. diff --git a/documentation/content/ru/books/arch-handbook/isa/_index.po b/documentation/content/ru/books/arch-handbook/isa/_index.po index 599e6b01a8..20b145402c 100644 --- a/documentation/content/ru/books/arch-handbook/isa/_index.po +++ b/documentation/content/ru/books/arch-handbook/isa/_index.po @@ -1,12 +1,12 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025. +# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-05-01 19:56-0300\n" -"PO-Revision-Date: 2025-11-12 04:45+0000\n" +"PO-Revision-Date: 2026-03-04 20:01+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" @@ -1467,7 +1467,7 @@ msgid "" msgstr "" "Второй момент: произвольная область виртуальной памяти может быть загружена " "в карту. Каждая страница этой памяти будет проверяться на соответствие " -"требованиям карты. Если она соответствует, то остается на своем исходном " +"требованиям карты. Если она соответствует, то остаётся на своём исходном " "месте. Если нет, то выделяется новая соответствующая промежуточная страница (" "bounce page), которая используется как промежуточное хранилище. При записи " "данных с несоответствующих исходных страниц они сначала копируются на свои " @@ -2113,7 +2113,7 @@ msgid "" "For a buffer which stays practically fixed during all the time between " "attachment and detachment of a device:" msgstr "" -"Для буфера, который остается практически неизменным в течение всего времени " +"Для буфера, который остаётся практически неизменным в течение всего времени " "между присоединением и отсоединением устройства:" #. type: Plain text @@ -3064,7 +3064,7 @@ msgstr "" "Конечно, обычно для таких вещей следует использовать процедуру `identify()` " "драйвера. Однако может быть одна веская причина, почему лучше сделать это в " "`probe()`: если этот обнаружение может привести к сбою другого " -"чувствительного устройства. Процедуры обнаружения упорядочены с учетом флага " +"чувствительного устройства. Процедуры обнаружения упорядочены с учётом флага " "`sensitive`: чувствительные устройства проверяются первыми, а остальные " "устройства — позже. Но процедуры `identify()` вызываются до любого " "обнаружения, поэтому они не учитывают чувствительные устройства и могут " diff --git a/documentation/content/ru/books/arch-handbook/jail/_index.adoc b/documentation/content/ru/books/arch-handbook/jail/_index.adoc index 14b36f4151..cc414c6ffa 100644 --- a/documentation/content/ru/books/arch-handbook/jail/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/jail/_index.adoc @@ -48,7 +48,7 @@ toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] -На большинстве систем UNIX(R) пользователь `root` обладает неограниченной властью. Это не способствует безопасности. Если злоумышленник получит права `root` в системе, у него окажутся все функции под рукой. В FreeBSD существуют sysctl-параметры, которые ограничивают власть `root`, чтобы минимизировать ущерб от действий злоумышленника. В частности, одна из таких функций называется `уровни безопасности`. Аналогично, другая функция, доступная начиная с FreeBSD 4.0, — это утилита man:jail[8] — клетка. Клетка создает chroot-окружение и накладывает определенные огранич ения на процессы, запущенные внутри `клетки`. Например, процесс в `клетке` не может влиять на процессы вне её, использовать определенные системные вызовы или наносить какой-либо ущерб основной системе. +На большинстве систем UNIX(R) пользователь `root` обладает неограниченной властью. Это не способствует безопасности. Если злоумышленник получит права `root` в системе, у него окажутся все функции под рукой. В FreeBSD существуют sysctl-параметры, которые ограничивают власть `root`, чтобы минимизировать ущерб от действий злоумышленника. В частности, одна из таких функций называется `уровни безопасности`. Аналогично, другая функция, доступная начиная с FreeBSD 4.0, — это утилита man:jail[8] — клетка. Клетка создает chroot-окружение и накладывает определённые огранич ения на процессы, запущенные внутри `клетки`. Например, процесс в `клетке` не может влиять на процессы вне её, использовать определённые системные вызовы или наносить какой-либо ущерб основной системе. Клетка становится новой моделью безопасности. Пользователи запускают потенциально уязвимые серверы, такие как Apache, BIND и sendmail, внутри клеток, так что если злоумышленник получит права `root` внутри клетки, это будет лишь неудобством, а не катастрофой. Данная статья в основном сосредоточена на внутреннем устройстве (исходном коде) клетки. Для получения информации о настройке клетки см. extref:{handbook}jails[раздел о клетках Руководства FreeBSD, jails-synopsis]. @@ -313,7 +313,7 @@ jail_attach(struct thread *td, struct jail_attach_args *uap) } .... -Когда процесс создается из родительского процесса, системный вызов man:fork[2] использует `crhold()` для поддержания учетных данных нового процесса. Это автоматически сохраняет учетные данные нового дочернего процесса согласованными с родительским, поэтому дочерний процесс также остается в клетке. +Когда процесс создается из родительского процесса, системный вызов man:fork[2] использует `crhold()` для поддержания учётных данных нового процесса. Это автоматически сохраняет учётные данные нового дочернего процесса согласованными с родительским, поэтому дочерний процесс также остаётся в клетке. [.programlisting] .... @@ -402,7 +402,7 @@ socreate(int dom, struct socket **aso, int type, int proto, === Протоколы -Существуют определенные протоколы, которые очень распространены, такие как TCP, UDP, IP и ICMP. IP и ICMP находятся на одном уровне: сетевом уровне 2. Принимаются определенные меры предосторожности, чтобы предотвратить привязку протокола к определенному адресу процессом в клетке, только если установлен параметр `nam`. `nam` является указателем на структуру `sockaddr`, которая описывает адрес, к которому привязывается служба. Более точное определение заключается в том, что `sockaddr` "может использоваться как шаблон для ссылки на идентификационный тег и дли у каждого адреса". В функции `in_pcbbind_setup()`, `sin` — это указатель на структуру `sockaddr_in`, которая содержит порт, адрес, длину и семейство доменов сокета, который должен быть привязан. В основном, это запрещает любым процессам из клетки указывать адрес, который не принадлежит клетке, в которой существует вызывающий процесс. +Существуют определённые протоколы, которые очень распространены, такие как TCP, UDP, IP и ICMP. IP и ICMP находятся на одном уровне: сетевом уровне 2. Принимаются определённые меры предосторожности, чтобы предотвратить привязку протокола к определённому адресу процессом в клетке, только если установлен параметр `nam`. `nam` является указателем на структуру `sockaddr`, которая описывает адрес, к которому привязывается служба. Более точное определение заключается в том, что `sockaddr` "может использоваться как шаблон для ссылки на идентификационный тег и дли у каждого адреса". В функции `in_pcbbind_setup()`, `sin` — это указатель на структуру `sockaddr_in`, которая содержит порт, адрес, длину и семейство доменов сокета, который должен быть привязан. В основном, это запрещает любым процессам из клетки указывать адрес, который не принадлежит клетке, в которой существует вызывающий процесс. [.programlisting] .... @@ -442,7 +442,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp, } .... -Вы можете задаться вопросом, какую функцию выполняет `prison_ip()`. `prison_ip()` принимает три аргумента: указатель на учетные данные (представленные как `cred`), любые флаги и IP-адрес. Она возвращает 1, если IP-адрес НЕ принадлежит клетке, и 0 в противном случае. Как видно из кода, если это действительно IP-адрес, не принадлежащий клетке, протоколу не разрешается привязываться к этому адресу. +Вы можете задаться вопросом, какую функцию выполняет `prison_ip()`. `prison_ip()` принимает три аргумента: указатель на учётные данные (представленные как `cred`), любые флаги и IP-адрес. Она возвращает 1, если IP-адрес НЕ принадлежит клетке, и 0 в противном случае. Как видно из кода, если это действительно IP-адрес, не принадлежащий клетке, протоколу не разрешается привязываться к этому адресу. [.programlisting] .... diff --git a/documentation/content/ru/books/arch-handbook/jail/_index.po b/documentation/content/ru/books/arch-handbook/jail/_index.po index 7486e99aac..43d8e6834c 100644 --- a/documentation/content/ru/books/arch-handbook/jail/_index.po +++ b/documentation/content/ru/books/arch-handbook/jail/_index.po @@ -1,12 +1,12 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025. +# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2025-11-11 04:45+0000\n" +"PO-Revision-Date: 2026-03-04 20:01+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" @@ -52,9 +52,9 @@ msgstr "" "минимизировать ущерб от действий злоумышленника. В частности, одна из таких " "функций называется `уровни безопасности`. Аналогично, другая функция, " "доступная начиная с FreeBSD 4.0, — это утилита man:jail[8] — клетка. Клетка " -"создает chroot-окружение и накладывает определенные ограничения на процессы, " +"создает chroot-окружение и накладывает определённые ограничения на процессы, " "запущенные внутри `клетки`. Например, процесс в `клетке` не может влиять на " -"процессы вне её, использовать определенные системные вызовы или наносить " +"процессы вне её, использовать определённые системные вызовы или наносить " "какой-либо ущерб основной системе." #. type: Plain text @@ -820,11 +820,11 @@ msgid "" "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()` для поддержания учётных данных нового " +"процесса. Это автоматически сохраняет учётные данные нового дочернего " "процесса согласованными с родительским, поэтому дочерний процесс также " -"остается в клетке." +"остаётся в клетке." #. type: delimited block . 4 #: documentation/content/en/books/arch-handbook/jail/_index.adoc:324 @@ -1169,10 +1169,10 @@ msgid "" "disallows any processes from jail to be able to specify the address that " "does not belong to the jail in which the calling process exists." msgstr "" -"Существуют определенные протоколы, которые очень распространены, такие как " +"Существуют определённые протоколы, которые очень распространены, такие как " "TCP, UDP, IP и ICMP. IP и ICMP находятся на одном уровне: сетевом уровне 2. " -"Принимаются определенные меры предосторожности, чтобы предотвратить привязку " -"протокола к определенному адресу процессом в клетке, только если установлен " +"Принимаются определённые меры предосторожности, чтобы предотвратить привязку " +"протокола к определённому адресу процессом в клетке, только если установлен " "параметр `nam`. `nam` является указателем на структуру `sockaddr`, которая " "описывает адрес, к которому привязывается служба. Более точное определение " "заключается в том, что `sockaddr` \"может использоваться как шаблон для " @@ -1268,8 +1268,8 @@ msgid "" "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/kobj/_index.adoc b/documentation/content/ru/books/arch-handbook/kobj/_index.adoc index fa43b32738..7d9e498d53 100644 --- a/documentation/content/ru/books/arch-handbook/kobj/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/kobj/_index.adoc @@ -70,7 +70,7 @@ endif::[] Kobj работает путем генерации описаний методов. Каждое описание содержит уникальный идентификатор, а также функцию по умолчанию. Адрес описания используется для однозначной идентификации метода в таблице методов класса. -Класс создается путем построения таблицы методов, связывающей одну или несколько функций с описаниями методов. Перед использованием класс компилируется. В процессе компиляции выделяется кэш и связывается с классом. Уникальный идентификатор назначается каждому описанию метода в таблице методов класса, если это еще не было сделано другой ссылающейся компиляцией класса. Для каждого используемого метода скриптом генерируется функция для проверки аргументов и автоматического обращения к описанию метода для поиска. Сгенерированная функция ищет метод, используя уникальный идентификатор, связанный с описанием метода, в качестве хэша для доступа к кэшу, связанному с классом объекта. Если метод не найден в кэше, сгенерированная функция использует таблицу класса для поиска метода. Если метод найден, используется связанная с ним функция внутри класса; в противном случае используется функция по умолчанию, связанная с описанием метода. +Класс создается путем построения таблицы методов, связывающей одну или несколько функций с описаниями методов. Перед использованием класс компилируется. В процессе компиляции выделяется кэш и связывается с классом. Уникальный идентификатор назначается каждому описанию метода в таблице методов класса, если это ещё не было сделано другой компиляцией, ссылающейся на этот класс. Для каждого используемого метода скриптом генерируется функция для проверки аргументов и автоматического обращения к описанию метода для поиска. Сгенерир ванная функция ищет метод, используя уникальный идентификатор, связанный с описанием метода, в качестве хэша для доступа к кэшу, связанному с классом объекта. Если метод не найден в кэше, сгенерированная функция использует таблицу класса для поиска метода. Если метод найден, используется связанная с ним функция внутри класса; в противном случае используется функция по умолчанию, связанная с описанием метода. Эти перенаправления можно визуализировать следующим образом: diff --git a/documentation/content/ru/books/arch-handbook/kobj/_index.po b/documentation/content/ru/books/arch-handbook/kobj/_index.po index 4209eb3967..26ad1feeb8 100644 --- a/documentation/content/ru/books/arch-handbook/kobj/_index.po +++ b/documentation/content/ru/books/arch-handbook/kobj/_index.po @@ -6,7 +6,7 @@ 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" +"PO-Revision-Date: 2025-11-26 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/booksarch-handbookkobj_index/ru/>\n" @@ -133,10 +133,10 @@ msgstr "" "несколько функций с описаниями методов. Перед использованием класс " "компилируется. В процессе компиляции выделяется кэш и связывается с классом. " "Уникальный идентификатор назначается каждому описанию метода в таблице " -"методов класса, если это еще не было сделано другой ссылающейся компиляцией " -"класса. Для каждого используемого метода скриптом генерируется функция для " -"проверки аргументов и автоматического обращения к описанию метода для " -"поиска. Сгенерированная функция ищет метод, используя уникальный " +"методов класса, если это ещё не было сделано другой компиляцией, ссылающейся " +"на этот класс. Для каждого используемого метода скриптом генерируется " +"функция для проверки аргументов и автоматического обращения к описанию " +"метода для поиска. Сгенерированная функция ищет метод, используя уникальный " "идентификатор, связанный с описанием метода, в качестве хэша для доступа к " "кэшу, связанному с классом объекта. Если метод не найден в кэше, " "сгенерированная функция использует таблицу класса для поиска метода. Если " diff --git a/documentation/content/ru/books/arch-handbook/mac/_index.adoc b/documentation/content/ru/books/arch-handbook/mac/_index.adoc index d27bbccef5..133fe61ed3 100644 --- a/documentation/content/ru/books/arch-handbook/mac/_index.adoc +++ b/documentation/content/ru/books/arch-handbook/mac/_index.adoc @@ -135,12 +135,12 @@ FreeBSD включает экспериментальную поддержку [[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]] === Синхронизация политики и параллелизм -Модули политик должны быть написаны с учетом того, что множество потоков ядра могут одновременно войти в одну или несколько точек входа политики из-за параллельной и вытесняющей природы ядра FreeBSD. Если модуль политики использует изменяемое состояние, это может потребовать применения примитивов синхронизации внутри политики, чтобы предотвратить несогласованные представления этого состояния, ведущие к некорректной работе политики. Политики, как правило, могут использовать существующие примитивы синхронизации FreeBSD для этой цели, в ключая мьютексы, блокировки с ожиданием, условные переменные и счётные семафоры. Однако политики должны быть написаны так, чтобы применять эти примитивы осторожно, соблюдая существующие порядки блокировок в ядре и учитывая, что некоторые точки входа не допускают ожидания, ограничивая использование примитивов в этих точках входа мьютексами и операциями пробуждения. +Модули политик должны быть написаны с учётом того, что множество потоков ядра могут одновременно войти в одну или несколько точек входа политики из-за параллельной и вытесняющей природы ядра FreeBSD. Если модуль политики использует изменяемое состояние, это может потребовать применения примитивов синхронизации внутри политики, чтобы предотвратить несогласованные представления этого состояния, ведущие к некорректной работе политики. Политики, как правило, могут использовать существующие примитивы синхронизации FreeBSD для этой цели, в ключая мьютексы, блокировки с ожиданием, условные переменные и счётные семафоры. Однако политики должны быть написаны так, чтобы применять эти примитивы осторожно, соблюдая существующие порядки блокировок в ядре и учитывая, что некоторые точки входа не допускают ожидания, ограничивая использование примитивов в этих точках входа мьютексами и операциями пробуждения. Когда модули политики обращаются к другим подсистемам ядра, они обычно должны освобождать любые блокировки внутри политики, чтобы избежать нарушения порядка блокировок ядра или риска рекурсивных блокировок. Это позволит сохранить блокировки политики как конечные блокировки в глобальном порядке блокировок, помогая избежать взаимоблокировки. @@ -152,7 +152,7 @@ FreeBSD включает экспериментальную поддержку [[mac-framework-kernel-arch-entrypoints]] === Точки входа -Ядро взаимодействует с MAC Framework двумя способами: вызывает набор API для уведомления фреймворка о соответствующих событиях и предоставляет указатель на структуру меток, не зависящую от политики, в объектах, связанных с безопасностью. Указатель метки управляется MAC Framework через точки входа управления метками, что позволяет фреймворку предоставлять службу маркировки модулям политик с относительно минимальными изменениями в подсистеме ядра, управляющей объектом. Например, указатели меток были добавлены к процессам, учетным данным проце ссов, сокетам, каналам, vnode, Mbuf, сетевым интерфейсам, очередям сборки IP-пакетов и множеству других структур, связанных с безопасностью. Ядро также вызывает MAC Framework при принятии важных решений по безопасности, позволяя модулям политик дополнять эти решения на основе собственных критериев (включая, возможно, данные, хранящиеся в метках безопасности). Большинство этих критически важных решений по безопасности будут явными проверками контроля доступа; однако некоторые влияют на более общие функции принятия решений, такие как сопоставлен ие пакетов для сокетов и переход меток при выполнении программы. +Ядро взаимодействует с MAC Framework двумя способами: вызывает набор API для уведомления фреймворка о соответствующих событиях и предоставляет указатель на структуру меток, не зависящую от политики, в объектах, связанных с безопасностью. Указатель метки управляется MAC Framework через точки входа управления метками, что позволяет фреймворку предоставлять службу маркировки модулям политик с относительно минимальными изменениями в подсистеме ядра, управляющей объектом. Например, указатели меток были добавлены к процессам, учётным данным проце ссов, сокетам, каналам, vnode, Mbuf, сетевым интерфейсам, очередям сборки IP-пакетов и множеству других структур, связанных с безопасностью. Ядро также вызывает MAC Framework при принятии важных решений по безопасности, позволяя модулям политик дополнять эти решения на основе собственных критериев (включая, возможно, данные, хранящиеся в метках безопасности). Большинство этих критически важных решений по безопасности будут явными проверками контроля доступа; однако некоторые влияют на более общие функции принятия решений, такие как сопоставлен ие пакетов для сокетов и переход меток при выполнении программы. [[mac-framework-kernel-arch-composition]] === Композиция политик @@ -266,7 +266,7 @@ MPC_LOADTIME_FLAG_LABELMBUFS:: Авторы модулей политик должны быть осведомлены о стратегии блокировок в ядре, а также о том, какие блокировки объектов доступны на различных точках входа. Им следует избегать сценариев взаимоблокировок, не захватывая нелистовые блокировки внутри точек входа, а также соблюдать протокол блокировок для доступа и изменения объектов. В частности, авторы должны учитывать, что хотя необходимые блокировки для доступа к объектам и их меткам обычно удерживаются, достаточные блокировки для изменения объекта или его метки могут отсутствоват для всех точек входа. Информация о блокировках аргументов документирована в описании точек входа фреймворка MAC. -Точки входа политики будут передавать ссылку на метку объекта вместе с самим объектом. Это позволяет помеченным политикам не знать внутренней структуры объекта, но при этом принимать решения на основе метки. Исключением из этого являются учетные данные процесса, для которые предполагается, что политики понимают их, как объект безопасности первого класса в ядре. +Точки входа политики будут передавать ссылку на метку объекта вместе с самим объектом. Это позволяет помеченным политикам не знать внутренней структуры объекта, но при этом принимать решения на основе метки. Исключением из этого являются учётные данные процесса, для которые предполагается, что политики понимают их, как объект безопасности первого класса в ядре. [[mac-entry-point-reference]] == Справочник по точкам входа политики MAC @@ -420,7 +420,7 @@ void mpo_init_cred_label(struct label *label); | |=== -Инициализировать метку для вновь созданных учетных данных пользователя. Разрешено приостанавливать выполнение. +Инициализировать метку для вновь созданных учётных данных пользователя. Разрешено приостанавливать выполнение. [[mac-mpo-init-devfsdirent]] ==== `mpo_init_devfsdirent_label` @@ -704,7 +704,7 @@ void mpo_destroy_bpfdesc_label(struct label *label); | |=== -Уничтожить метку на дескрипторе BPF. В этой точке входа политика должна освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на дескрипторе BPF. В этой точке входа политика должна освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-cred]] ==== `mpo_destroy_cred_label` @@ -726,7 +726,7 @@ void mpo_destroy_cred_label(struct label *label); | |=== -Уничтожить метку на учетных данных. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на учётных данных. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-devfsdirent]] ==== `mpo_destroy_devfsdirent_label` @@ -748,7 +748,7 @@ void mpo_destroy_devfsdirent_label(struct label *label); | |=== -Уничтожить метку на записи devfs. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на записи devfs. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-ifnet-label]] ==== `mpo_destroy_ifnet_label` @@ -770,7 +770,7 @@ void mpo_destroy_ifnet_label(struct label *label); | |=== -Уничтожить метку на удаленном интерфейсе. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на удаленном интерфейсе. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-ipq-label]] ==== `mpo_destroy_ipq_label` @@ -792,7 +792,7 @@ void mpo_destroy_ipq_label(struct label *label); | |=== -Уничтожить метку в очереди IP-фрагментов. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку в очереди IP-фрагментов. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-mbuf-label]] ==== `mpo_destroy_mbuf_label` @@ -814,7 +814,7 @@ void mpo_destroy_mbuf_label(struct label *label); | |=== -Уничтожить метку в заголовке mbuf. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку в заголовке mbuf. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-mount-label]] ==== `mpo_destroy_mount_label` @@ -836,7 +836,7 @@ void mpo_destroy_mount_label(struct label *label); | |=== -Уничтожить метки на точке монтирования. В этой точке входа модуль политики должен освободить внутреннее хранилище, связанное с `mntlabel`, чтобы ее можно было уничтожить. +Уничтожить метки на точке монтирования. В этой точке входа модуль политики должен освободить внутреннее хранилище, связанное с `mntlabel`, чтобы её можно было уничтожить. [[mac-mpo-destroy-mount]] ==== `mpo_destroy_mount_label` @@ -884,7 +884,7 @@ void mpo_destroy_socket_label(struct label *label); | |=== -Уничтожить метку на сокете. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на сокете. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-socket-peer-label]] ==== `mpo_destroy_socket_peer_label` @@ -906,7 +906,7 @@ void mpo_destroy_socket_peer_label(struct label *peerlabel); | |=== -Уничтожить метку однорангового узла на сокете. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку однорангового узла на сокете. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-pipe-label]] ==== `mpo_destroy_pipe_label` @@ -950,7 +950,7 @@ void mpo_destroy_proc_label(struct label *label); | |=== -Уничтожить метку на процессе. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на процессе. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-destroy-vnode-label]] ==== `mpo_destroy_vnode_label` @@ -972,7 +972,7 @@ void mpo_destroy_vnode_label(struct label *label); | |=== -Уничтожить метку на vnode. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы ее можно было уничтожить. +Уничтожить метку на vnode. В этой точке входа модуль политики должен освободить любое внутреннее хранилище, связанное с `label`, чтобы её можно было уничтожить. [[mac-mpo-copy-mbuf-label]] ==== `mpo_copy_mbuf_label` @@ -1664,7 +1664,7 @@ void mpo_create_devfs_symlink(struct ucred *cred, struct mount *mp, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`mp` @@ -1708,7 +1708,7 @@ int mpo_create_vnode_extattr(struct ucred *cred, struct mount *mp, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`mount` @@ -1759,7 +1759,7 @@ void mpo_create_mount(struct ucred *cred, struct mount *mp, struct label *mnt, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`mp` @@ -1775,7 +1775,7 @@ void mpo_create_mount(struct ucred *cred, struct mount *mp, struct label *mnt, | |=== -Заполнить метки на точке монтирования, создаваемой переданными учетными данными субъекта. Этот вызов будет выполнен при монтировании новой файловой системы. +Заполнить метки на точке монтирования, создаваемой переданными учётными данными субъекта. Этот вызов будет выполнен при монтировании новой файловой системы. [[mac-mpo-create-root-mount]] ===== `mpo_create_root_mount` @@ -1796,7 +1796,7 @@ void mpo_create_root_mount(struct ucred *cred, struct mount *mp, 3+|См. crossref:mac[mac-mpo-create-mount, `mpo_create_mount`]. |=== -Заполнить метки на точке монтирования, создаваемой переданными учетными данными субъекта. Этот вызов будет выполнен при монтировании корневой файловой системы после `mpo_create_mount;`. +Заполнить метки на точке монтирования, создаваемой переданными учётными данными субъекта. Этот вызов будет выполнен при монтировании корневой файловой системы после `mpo_create_mount;`. [[mac-mpo-relabel-vnode]] ===== `mpo_relabel_vnode` @@ -1815,7 +1815,7 @@ void mpo_relabel_vnode(struct ucred *cred, struct vnode *vp, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`vp` @@ -1831,7 +1831,7 @@ void mpo_relabel_vnode(struct ucred *cred, struct vnode *vp, | |=== -Обновить метку на переданном vnode с учетом переданной обновленной метки vnode и переданных учетных данных субъекта. +Обновить метку на переданном vnode с учётом переданной обновленной метки vnode и переданных учётных данных субъекта. [[mac-mpo-setlabel-vnode-extattr]] ===== `mpo_setlabel_vnode_extattr` @@ -1850,7 +1850,7 @@ int mpo_setlabel_vnode_extattr(struct ucred *cred, struct vnode *vp, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`vp` @@ -1958,7 +1958,7 @@ void mpo_create_pipe(struct ucred *cred, struct pipe *pipe, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`pipe` @@ -1970,7 +1970,7 @@ void mpo_create_pipe(struct ucred *cred, struct pipe *pipe, | |=== -Установить метку на только что созданном канале из переданных учетных данных субъекта. Этот вызов выполняется при создании нового канала. +Установить метку на только что созданном канале из переданных учётных данных субъекта. Этот вызов выполняется при создании нового канала. [[mac-mpo-create-socket]] ===== `mpo_create_socket` @@ -1989,7 +1989,7 @@ void mpo_create_socket(struct ucred *cred, struct socket *so, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта |Неизменяемый |`so` @@ -2001,7 +2001,7 @@ void mpo_create_socket(struct ucred *cred, struct socket *so, | |=== -Установить метку на новом сокете из переданных учетных данных субъекта. Этот вызов выполняется при создании сокета. +Установить метку на новом сокете из переданных учётных данных субъекта. Этот вызов выполняется при создании сокета. [[mac-mpo-create-socket-from-socket]] ===== `mpo_create_socket_from_socket` @@ -2056,7 +2056,7 @@ void mpo_relabel_pipe(struct ucred *cred, struct pipe *pipe, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`pipe` @@ -2091,7 +2091,7 @@ void mpo_relabel_socket(struct ucred *cred, struct socket *so, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта |Неизменяемый |`so` @@ -2200,7 +2200,7 @@ void mpo_create_bpfdesc(struct ucred *cred, struct bpf_d *bpf_d, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта |Неизменяемый |`bpf_d` @@ -2616,7 +2616,7 @@ void mpo_relabel_ifnet(struct ucred *cred, struct ifnet *ifnet, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`ifnet` @@ -2632,7 +2632,7 @@ void mpo_relabel_ifnet(struct ucred *cred, struct ifnet *ifnet, | |=== -Обновить метку сетевого интерфейса, `ifnet`, на основе переданной новой метки, `newlabel`, и переданных учетных данных субъекта, `cred`. +Обновить метку сетевого интерфейса, `ifnet`, на основе переданной новой метки, `newlabel`, и переданных учётных данных субъекта, `cred`. [[mac-mpo-update-ipq]] ===== `mpo_update_ipq` @@ -2688,7 +2688,7 @@ void mpo_create_cred(struct ucred *parent_cred, struct ucred *child_cred); | Блокировка |`parent_cred` -|Учетные данные субъекта‐родителя +|Учётные данные субъекта‐родителя | |`child_cred` @@ -2716,11 +2716,11 @@ void mpo_execve_transition(struct ucred *old, struct ucred *new, | Блокировка |`old` -|Учетные данные существующего субъекта +|Учётные данные существующего субъекта |Неизменяемый |`new` -|Учетные данные нового субъекта для добавления метки +|Учётные данные нового субъекта для добавления метки | |`vp` @@ -2732,7 +2732,7 @@ void mpo_execve_transition(struct ucred *old, struct ucred *new, | |=== -Обновить метку учетных данных вновь созданного субъекта (`new`) на основе переданных учетных данных существующего субъекта (`old`) в соответствии с переходом метки, вызванным выполнением переданного vnode (`vp`). Этот вызов происходит, когда процесс выполняет переданный vnode, и одна из политик возвращает успех из точки входа `mpo_execve_will_transition`. Политики могут выбрать реализацию этого вызова просто путем вызова `mpo_create_cred` и передачи двух субъектов учетных данных, чтобы не реализовывать событие перехода. Политики не должны оставлять эту точку входа нереализованной, если они реализуют `mpo_create_cred`, даже если они не реализуют `mpo_execve_will_transition`. +Обновить метку учётных данных вновь созданного субъекта (`new`) на основе переданных учётных данных существующего субъекта (`old`) в соответствии с переходом метки, вызванным выполнением переданного vnode (`vp`). Этот вызов происходит, когда процесс выполняет переданный vnode, и одна из политик возвращает успех из точки входа `mpo_execve_will_transition`. Политики могут выбрать реализацию этого вызова просто путем вызова `mpo_create_cred` и передачи двух субъектов учётных данных, чтобы не реализовывать событие перехода. Политики не должны оставлять эту точку входа нереализованной, если они реализуют `mpo_create_cred`, даже если они не реализуют `mpo_execve_will_transition`. [[mac-mpo-execve-will-transition]] ===== `mpo_execve_will_transition` @@ -2751,7 +2751,7 @@ int mpo_execve_will_transition(struct ucred *old, struct vnode *vp, | Блокировка |`old` -|Учетные данные субъекта перед man:execve[2] +|Учётные данные субъекта перед man:execve[2] |Неизменяемый |`vp` @@ -2763,7 +2763,7 @@ int mpo_execve_will_transition(struct ucred *old, struct vnode *vp, | |=== -Определить, будет ли политика выполнять событие перехода в результате выполнения переданного vnode с использованием переданных учетных данных субъекта. Вернуть 1, если переход требуется, и 0, если нет. Даже если политика возвращает 0, она должна корректно обрабатывать неожиданный вызов `mpo_execve_transition`, так как этот вызов может произойти из-за запроса перехода другой политикой. +Определить, будет ли политика выполнять событие перехода в результате выполнения переданного vnode с использованием переданных учётных данных субъекта. Вернуть 1, если переход требуется, и 0, если нет. Даже если политика возвращает 0, она должна корректно обрабатывать неожиданный вызов `mpo_execve_transition`, так как этот вызов может произойти из-за запроса перехода другой политикой. [[mac-mpo-create-proc0]] ===== `mpo_create_proc0` @@ -2781,11 +2781,11 @@ void mpo_create_proc0(struct ucred *cred); | Блокировка |`cred` -|Учетные данные субъекта для заполнения +|Учётные данные субъекта для заполнения | |=== -Создать учетные данные субъекта процесса 0, родителя всех процессов ядра. +Создать учётные данные субъекта процесса 0, родителя всех процессов ядра. [[mac-mpo-create-proc1]] ===== `mpo_create_proc1` @@ -2803,11 +2803,11 @@ void mpo_create_proc1(struct ucred *cred); | Блокировка |`cred` -|Учетные данные субъекта для заполнения +|Учётные данные субъекта для заполнения | |=== -Создать учетные данные субъекта процесса 1, родителя всех пользовательских процессов. +Создать учётные данные субъекта процесса 1, родителя всех пользовательских процессов. [[mac-mpo-relabel-cred]] ===== `mpo_relabel_cred` @@ -2825,7 +2825,7 @@ void mpo_relabel_cred(struct ucred *cred, struct label *newlabel); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`newlabel` @@ -2833,7 +2833,7 @@ void mpo_relabel_cred(struct ucred *cred, struct label *newlabel); | |=== -Обновить метку на учетных данных субъекта из переданной обновляемой метки. +Обновить метку на учётных данных субъекта из переданной обновляемой метки. [[mac-access-control-checks]] === Проверки контроля доступа @@ -2913,7 +2913,7 @@ int mpo_check_kenv_dump(struct ucred *cred); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |=== @@ -2935,7 +2935,7 @@ int mpo_check_kenv_get(struct ucred *cred, char *name); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`name` @@ -2961,7 +2961,7 @@ int mpo_check_kenv_set(struct ucred *cred, char *name); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`name` @@ -2987,7 +2987,7 @@ int mpo_check_kenv_unset(struct ucred *cred, char *name); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`name` @@ -3014,7 +3014,7 @@ int mpo_check_kld_load(struct ucred *cred, struct vnode *vp, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`vp` @@ -3044,7 +3044,7 @@ int mpo_check_kld_stat(struct ucred *cred); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |=== @@ -3066,7 +3066,7 @@ int mpo_check_kld_unload(struct ucred *cred); | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |=== @@ -3089,7 +3089,7 @@ int mpo_check_pipe_ioctl(struct ucred *cred, struct pipe *pipe, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | |`pipe` @@ -3128,7 +3128,7 @@ int mpo_check_pipe_poll(struct ucred *cred, struct pipe *pipe, | Блокировка |`cred` -|Учетные данные субъекта +|Учётные данные субъекта | *** 1783 LINES SKIPPED ***home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69b69f83.3082b.2fe9e4de>