-Пока бушевали коммерческие войны Unix, ядро Linux разрабатывалось как клон Unix для ПК. Линус Торвальдс признает, что существование компилятора GNU C и связанных с ним инструментов GNU стало основой для появления Linux. Он выпустил ядро Linux под лицензией GPL.
+Пока бушевали коммерческие войны Unix, ядро Linux разрабатывалось как клон Unix для ПК. Линус Торвальдс признаёт, что существование компилятора GNU C и связанных с ним инструментов GNU стало основой для появления Linux. Он выпустил ядро Linux под лицензией GPL.
Помните, что лицензия GPL требует, чтобы любой код, статически связанный с кодом под GPL, также распространялся под GPL. Исходный код такой программы должен быть предоставлен пользователю. Однако динамическая линковка не считается нарушением GPL. Давление с целью размещения проприетарных приложений в Linux стало слишком сильным. Такие приложения часто должны быть связаны с системными библиотеками. Это привело к созданию модифицированной версии GPL под названием http://www.opensource.org/licenses/lgpl-license.php[LGPL] ("Library", позже переименована в "Lesser" GPL). LGPL разрешает проприетарному коду быть связанным с библиотекой GNU C, glibc. Вам не нужно раскрывать исходный код, который был динамически связан с библиотекой под LGPL.
@@ -146,7 +146,7 @@
Для тех, кто должен работать со статически связанными реализациями множества программных стандартов, GPL часто является неудобной лицензией, поскольку она исключает использование проприетарных реализаций этих стандартов. Таким образом, GPL минимизирует количество программ, которые могут быть созданы с использованием стандарта под лицензией GPL. Лицензия GPL задумывалась так, чтобы не предоставлять механизм для разработки стандарта, на основе которого создаются проприетарные продукты. (Это не относится к приложениям для Linux, поскольку они не используют статическую линковку, а вместо этого применяют API на основе трапов/ловушек.)
-Лицензия GPL пытается заставить программистов вносить вклад в развивающийся набор программ, а затем конкурировать в распространении и поддержке этого набора. Такая ситуация нереалистична для многих необходимых стандартов ядра системы, которые могут применяться в самых разных средах, требующих коммерческой настройки или интеграции с унаследованными стандартами под существующими (не-GPL) лицензиями. Системы реального времени часто статически связываются, поэтому GPL и LGPL определенно рассматриваются многими компаниями, работающими с встраиваемыми системами, как потенциальные проблемы.
+Лицензия GPL пытается заставить программистов вносить вклад в развивающийся набор программ, а затем конкурировать в распространении и поддержке этого набора. Такая ситуация нереалистична для многих необходимых стандартов ядра системы, которые могут применяться в самых разных средах, требующих коммерческой настройки или интеграции с унаследованными стандартами под существующими (не-GPL) лицензиями. Системы реального времени часто статически связываются, поэтому GPL и LGPL определённо рассматриваются многими компаниями, работающими с встраиваемыми системами, как потенциальные проблемы.
GPL - это попытка удержать усилия, независимо от спроса, на этапах исследований и разработки. Это максимизирует выгоды для исследователей и разработчиков, при неизвестных затратах для тех, кто мог бы получить выгоду от более широкого распространения.
Настройте процессы, которые помогают отслеживать разработку FreeBSD. Например:
+
-*Отслеживание исходного кода FreeBSD.* Проект упрощает зеркалирование своего SVN-репозитория с помощью extref:{committers-guide}[svnsync, svn-advanced-use-setting-up-svnsync]. Наличие полной истории исходного кода полезно при отладке сложных проблем и дает ценное понимание намерений оригинальных разработчиков. Используйте систему контроля версий, которая позволяет легко объединять изменения между основной кодовой базой FreeBSD и вашим внутренним кодом.
+*Отслеживание исходного кода FreeBSD.* Проект упрощает зеркалирование своего SVN-репозитория с помощью extref:{committers-guide}[svnsync, svn-advanced-use-setting-up-svnsync]. Наличие полной истории исходного кода полезно при отладке сложных проблем и даёт ценное понимание намерений оригинальных разработчиков. Используйте систему контроля версий, которая позволяет легко объединять изменения между основной кодовой базой FreeBSD и вашим внутренним кодом.
+
crossref:building-products[fig-svn-blame, Аннотированный листинг исходного кода, сгенерированный с помощью `svn blame`] показывает часть аннотированного листинга файла, на который ссылается журнал изменений в crossref:building-products[fig-change-log, Пример записи в журнале изменений]. Происхождение каждой строки исходного кода чётко видно. Аннотированные листинги, показывающие историю каждого файла, входящего в состав FreeBSD, https://svnweb.freebsd.org/[доступны в интернете].
* Кеннет П. Стокс <mailto:ken@stox.sa.enteract.com[ken@stox.sa.enteract.com]> из http://www.imagescape.com/[Imaginary Landscape, LLC.].
* Dmitry S. Kohmanyuk <mailto:dk@dog.farm.org[dk@dog.farm.org]>.
-* http://www.cdrom.co.jp/[Laser5] из Японии (часть прибыли от продаж их различных FreeBSD CDROM идет на поддержку проекта).
+* http://www.cdrom.co.jp/[Laser5] из Японии (часть прибыли от продаж их различных FreeBSD CDROM идёт на поддержку проекта).
* http://www.mmjp.or.jp/fuki/[Fuki Shuppan Publishing Co.] пожертвовала часть прибыли от книги _Hajimete no FreeBSD_ (FreeBSD, начало работы) проектам FreeBSD и XFree86.
* http://www.ascii.co.jp/[ASCII Corp.] пожертвовала часть прибыли от нескольких книг, связанных с FreeBSD, проекту FreeBSD.
* http://www.yokogawa.co.jp/[Yokogawa Electric Corp] щедро предоставила значительное финансирование проекту FreeBSD.
Брюс был одним из основателей проекта FreeBSD и входил в состав core.0, но он никогда не был пристрастным, и на протяжении многих лет множество других проектов получали пользу от его патчей, советов и мудрости.
+
-Рецензии кода от Брюса были трех видов: "мягкие", "брюсифицированные" и "брюсификация", но они никогда не были личными: всегда речь шла только о коде, ошибках, небрежном мышлении, упущенном историческом контексте, неоднозначных стандартах — и о нарушениях style(9).
+Рецензии кода от Брюса были трёх видов: "мягкие", "брюсифицированные" и "брюсификация", но они никогда не были личными: всегда речь шла только о коде, ошибках, небрежном мышлении, упущенном историческом контексте, неоднозначных стандартах — и о нарушениях style(9).
+
Поскольку Брюс провёл больше рецензий кода, чем кто-либо в истории проекта FreeBSD, журналы коммитов скрывают истинный масштаб его влияния, пока вы не обратите внимание на «Submitted by», «Reviewed by» и «Pointed out by».
-title: 'Универсальная Система Печати Unix на FreeBSD'
+title: 'Универсальная система печати Unix на FreeBSD'
trademarks: ["freebsd", "general"]
---
-= Универсальная Система Печати Unix на FreeBSD
+= Универсальная система печати Unix на FreeBSD
:doctype: article
:toc: macro
:toclevels: 1
@@ -50,13 +50,13 @@
toc::[]
[[printing-cups]]
-== Знакомимся с Универсальной Системой Печати UNIX (CUPS)
+== Знакомимся с универсальной системой печати UNIX (CUPS)
-Универсальная Система Печати UNIX (Common Unix Printing System, или сокращенно CUPS), предоставляет переносимую среду печати для UNIX(R) и UNIX(R)-подобных операционных систем. Она была разработана компанией Easy Software Products, чтобы предоставить стандартное решение в печати для всех разработчиков и пользователей UNIX(R).
+Универсальная система печати UNIX (Common Unix Printing System, или сокращенно CUPS), предоставляет переносимую среду печати для UNIX(R) и UNIX(R)-подобных операционных систем. Она была разработана компанией Easy Software Products, чтобы предоставить стандартное решение в печати для всех разработчиков и пользователей UNIX(R).
-Универсальная Система Печати UNIX использует протокол межсетевой печати (Internet Printing Protocol, IPP) как основу для управления заданиями на печать и очередями. Также частично поддерживаются следующие протоколы: LPD, SMB и AppSocket (также известный как JetDirect). CUPS дает возможность обзора сетевых принтеров и использования опций, базирующихся на ПостСкрипт Описании Принтеров (PostScript Printer Definition, PPD), чтобы поддерживать в UNIX(R) общепринятые традиции печати. В результате CUPS идеально подходит для совместного использования принтеров в смешанной среде из FreeBSD, Linux(R), Mac OS(R) X или Windows(R).
+Универсальная система печати UNIX использует протокол межсетевой печати (Internet Printing Protocol, IPP) как основу для управления заданиями на печать и очередями. Также частично поддерживаются следующие протоколы: LPD, SMB и AppSocket (также известный как JetDirect). CUPS даёт возможность обзора сетевых принтеров и использования опций, базирующихся на ПостСкрипт Описании Принтеров (PostScript Printer Definition, PPD), чтобы поддерживать в UNIX(R) общепринятые традиции печати. В результате CUPS идеально подходит для совместного использования принтеров в смешанной среде из FreeBSD, Linux(R), Mac OS(R) X или Windows(R).
-Официальный сайт Универсальной Системы Печати UNIX - http://www.cups.org/[http://www.cups.org/].
+Официальный сайт универсальной системы печати UNIX - http://www.cups.org/[http://www.cups.org/].
__Некоторые из них базируются на коде GNU, а некоторые -- нет.__
* Система X Window, отвечающая за графический интерфейс.
+
-Система X Window, которая используется в большинстве версий BSD, поддерживается http://www.X.org/[проектом X.Org]. FreeBSD дает пользователю возможность выбирать из множества графических оболочек, таких как GNOME, KDE или Xfce; а также из множества легких оконных менеджеров наподобие Openbox, Fluxbox или Awesome.
+Система X Window, которая используется в большинстве версий BSD, поддерживается http://www.X.org/[проектом X.Org]. FreeBSD даёт пользователю возможность выбирать из множества графических оболочек, таких как GNOME, KDE или Xfce; а также из множества легких оконных менеджеров наподобие Openbox, Fluxbox или Awesome.
* Множество разных других прикладных и системных программ.
[[what-a-real-unix]]
@@ -114,8 +114,8 @@
* _Контрибьюторы_ пишут код или документацию. Они не могут добавлять или изменять код непосредственно в дереве исходников проекта. Это привилегия особым образом зарегистрированных разработчиков, или __коммиттеров (committers)__, которые просматривают и тестируют присылаемый им код и включают его в дерево.
* _Коммиттеры_ являются разработчиками, которые имеют доступ на запись в дерево исходных кодов проекта. Чтобы стать коммиттером, человек должен проявить себя в той области, в которой он хочет работать.
+
-Каждый коммиттер по своему собственному усмотрению решает, нужно ли ему подтверждение правильности планируемых изменений от других разработчиков или нет. В общем случае опытный коммиттер может вносить очевидно выгодные изменения ни с кем не советуясь. К примеру, коммиттер проекта документации может исправлять опечатки или грамматические ошибки в документах без предварительного согласования. Напротив, далеко идущие или просто сложные изменения настоятельно рекомендуется представлять к обсуждению перед окончательным внесением в дерево. Бывают крайние случаи, когда член Core Team, выполняющий функцию архитектора проекта, может санкционировать немедленную отмену или _откат_ каких-то изменений в дереве. Все коммиттеры обязательно получают уведомление о каждом изменении в дереве по электронной почте, так что их невозможно сохранить в тайне.
-* _Правление_ (Core Team). В проектах FreeBSD и NetBSD имеются управляющие советы, которые занимаются координационной деятельностью. Их роль, права и обязанности не всегда чётко определены. Необязательно (хотя в порядке вещей) быть коммиттером для того, чтобы входить в состав Core Team. Правила, которым следует Core Team, различаются между проектами, но в общем случае члены Core Team определяют общее направление развития системы в большей степени, чем все остальные разработчики.
+Каждый коммиттер по своему собственному усмотрению решает, нужно ли ему подтверждение правильности планируемых изменений от других разработчиков или нет. В общем случае опытный коммиттер может вносить очевидно выгодные изменения ни с кем не советуясь. К примеру, коммиттер проекта документации может исправлять опечатки или грамматические ошибки в документах без предварительного согласования. Напротив, далеко идущие или просто сложные изменения настоятельно рекомендуется представлять к обсуждению перед окончательным внесением в дерево. Бывают крайние случаи, когда член Основной команды (Core Team), выполняющий функцию архитектора проекта, может санкционировать немедленную отмену или _откат_ каких-то изменений в дереве. Все коммиттеры обязательно получают уведомление о каждом изменении в дереве по электронной почте, так что их невозможно сохранить в тайне.
+* _Основная команда_ (Core Team). В проектах FreeBSD и NetBSD имеются управляющие советы, которые занимаются координационной деятельностью. Их роль, права и обязанности не всегда чётко определены. Необязательно (хотя в порядке вещей) быть коммиттером для того, чтобы входить в состав Основной команды. Правила, которым следует Основная команда, различаются между проектами, но в общем случае члены Основной команды определяют общее направление развития системы в большей степени, чем все остальные разработчики.
Такое положение вещей отличается от принятого в Linux:
-То есть, отбрасывать пакеты, которые поступают извне, утверждая, что они из нашей сети. Это стандартная мера для предотвращения попыток обхода межсетевого экрана путем генерации вредоносных пакетов, которые выглядят так, будто они из внутренней сети. Проблема в том, что есть _как минимум_ один хост на внешнем интерфейсе, который нельзя игнорировать: маршрутизатор. Однако обычно интернет-провайдер применяет антиспуфинг на своем маршрутизаторе, так что нам не нужно слишком беспокоиться об этом.
+То есть, отбрасывать пакеты, которые поступают извне, утверждая, что они из нашей сети. Это стандартная мера для предотвращения попыток обхода межсетевого экрана путем генерации вредоносных пакетов, которые выглядят так, будто они из внутренней сети. Проблема в том, что есть _как минимум_ один хост на внешнем интерфейсе, который нельзя игнорировать: маршрутизатор. Однако обычно интернет-провайдер применяет антиспуфинг на своём маршрутизаторе, так что нам не нужно слишком беспокоиться об этом.
Последнее правило кажется точной копией правила по умолчанию, то есть не пропускать ничего, что явно не разрешено. Однако есть разница: весь подозрительный трафик будет записываться в журнал.
-Существует два правила для пропуска SMTP и DNS-трафика к почтовому серверу и серверу имен, если они у вас есть. Очевидно, весь набор правил должен быть адаптирован под личные предпочтения — это лишь конкретный пример (формат правил подробно описан на man:ipfw[8]). Обратите внимание, что для работы "relay" и "ns" разрешение имен должно работать _до_ включения моста. Это пример того, как убедиться, что IP-адрес установлен на правильной сетевой карте. Альтернативно можно указать IP-адрес вместо имени хоста (это требуется, если у машины нет IP-адреса).
+Существует два правила для пропуска SMTP и DNS-трафика к почтовому серверу и серверу имен, если они у вас есть. Очевидно, весь набор правил должен быть адаптирован под личные предпочтения — это лишь конкретный пример (формат правил подробно описан на man:ipfw[8]). Обратите внимание, что для работы "relay" и "ns" разрешение имён должно работать _до_ включения моста. Это пример того, как убедиться, что IP-адрес установлен на правильной сетевой карте. Или можно указать IP-адрес вместо имени хоста (это требуется, если у машины нет IP-адреса).
Люди, привыкшие настраивать межсетевые экраны, вероятно, также привыкли использовать правило `reset` или `forward` для идентификационных пакетов (TCP-порт 113). К сожалению, это не применимо при использовании моста, поэтому лучше всего просто передавать их целевому устройству. Пока на этом устройстве не запущен идентификационный демон, это относительно безопасно. Альтернативой является сброс соединений на порту 113, что создает проблемы с такими сервисами, как IRC (запрос идентификации будет ожидать таймаута).
-Имеется множество различных форматов файлов шрифтов и соответствующих окончаний имен файлов. Здесь обсуждаются лишь следующие из них:
+Имеется множество различных форматов файлов шрифтов и соответствующих окончаний имён файлов. Здесь обсуждаются лишь следующие из них:
[.filename]#.pfa#, [.filename]#.pfb#::
Файлы шрифтов PostScript(R) type 1. Файлы [.filename]#.pfa# являются текстовым (__A__scii) представлением, а [.filename]#.pfb# - двоичным (__B__inary).
@@ -126,7 +126,7 @@
% vidcontrol VGA_80x60
....
-Различные программы, ориентированные на работу с экраном, такие, как man:vi[1], должны уметь определять текущие размеры экрана. Так как это делается через вызовы `ioctl` к драйверу консоли (такому, как man:syscons[4]), то размеры будут определяться правильно.
+Различные программы, ориентированные на работу с экраном, такие, как man:vi[1], должны уметь определять текущие размеры экрана. Так как это делается через вызовы `ioctl` к драйверу консоли (такому как man:syscons[4]), то размеры будут определяться правильно.
Чтобы это проходило более гладко, можно включить эти команды в скрипты начальной загрузки, чтобы они выполнялись при запуске системы. Чтобы это сделать, добавьте такую строчку в [.filename]#/etc/rc.conf#.
@@ -438,7 +438,7 @@
Смесь верхнего/нижнего регистров присутствует из-за того, что эти файлы предназначены и для DOS. [.filename]#ttf2pf.ps# использует остальные с именами в верхнем регистре, так что при переименовании это нужно учитывать. (На самом деле [.filename]#GS_TTF.PS# и [.filename]#PFS2AFM.PS# предположительно являются частью дистрибутива Ghostscript, но их легко использовать как отдельные утилиты. В поставку FreeBSD они не включены.) Вы можете также установить их в каталог [.filename]#/usr/local/shared/groff_font/devps#(?).
`afmtodit`::
-Создает файлы шрифтов для использования с программой Groff из текстовых файлов с метриками шрифта. Она обычно располагается в каталоге [.filename]#/usr/src/contrib/groff/afmtodit# и для ее использования требуется проделать некоторую работу.
+Создает файлы шрифтов для использования с программой Groff из текстовых файлов с метриками шрифта. Она обычно располагается в каталоге [.filename]#/usr/src/contrib/groff/afmtodit# и для её использования требуется проделать некоторую работу.
+
[NOTE]
====
@@ -518,8 +518,8 @@
Такая весьма печальная ситуация может вскоре измениться. В рамках проекта http://www.freetype.org/[FreeType Project] в настоящее время разрабатывается полезный набор инструментов для работы с FreeType:
-* Сервер шрифтов `xfsft` для X11 может работать и со шрифтами TrueType, и с обычными шрифтами. Хотя в настоящее время он еще находится в стадии отладки, но его уже можно использовать. Посмотрите http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/[страницу Juliusz Chroboczek], чтобы получить более полную информацию. Указания по переносу на FreeBSD можно найти на странице http://math.missouri.edu/~stephen/software/[Стивена Монтгомери] (Stephen Montgomery), посвященной программному обеспечению.
-* xfstt является еще одним сервером шрифтов для X11, доступный по адресу link:ftp://sunsite.unc.edu/pub/Linux/X11/fonts[ftp://sunsite.unc.edu/pub/Linux/X11/fonts].
+* Сервер шрифтов `xfsft` для X11 может работать и со шрифтами TrueType, и с обычными шрифтами. Хотя в настоящее время он ещё находится в стадии отладки, но его уже можно использовать. Посмотрите http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/[страницу Juliusz Chroboczek], чтобы получить более полную информацию. Указания по переносу на FreeBSD можно найти на странице http://math.missouri.edu/~stephen/software/[Стивена Монтгомери] (Stephen Montgomery), посвященной программному обеспечению.
+* xfstt является ещё одним сервером шрифтов для X11, доступный по адресу link:ftp://sunsite.unc.edu/pub/Linux/X11/fonts[ftp://sunsite.unc.edu/pub/Linux/X11/fonts].
* Программа, которая называется `ttf2bdf`, может генерировать BDF-файлы, которые можно использовать в системе X Window, из файлов шрифтов TrueType. Выполнимые файлы Linux могут находиться по адресу link:ftp://crl.nmsu.edu/CLR/multiling/General[ftp://crl.nmsu.edu/CLR/multiling/General].
-Термин "хакер" не имеет ничего общего с проникновением на компьютеры других людей. Правильным термином для обозначения такой деятельности является "кракер", однако популярная пресса этого еще не поняла. Хакеры FreeBSD нарушением защиты не занимаются. Более полное описание хакеров находится в руководстве Эрика Рэймонда (Eric Raymond) http://www.catb.org/~esr/faqs/hacker-howto.html[Как стать хакером]
+Термин "хакер" не имеет ничего общего с проникновением на компьютеры других людей. Правильным термином для обозначения такой деятельности является "кракер", однако популярная пресса этого ещё не поняла. Хакеры FreeBSD нарушением защиты не занимаются. Более полное описание хакеров находится в руководстве Эрика Рэймонда (Eric Raymond) http://www.catb.org/~esr/faqs/hacker-howto.html[Как стать хакером]
====
Данный регулярно рассылаемый документ предназначен для помощи как тем, кто ищет ответов на вопросы во FreeBSD-questions ("новички"), так и тем, кто на эти вопросы отвечает ("хакеры").
@@ -83,9 +83,9 @@
Общим вопросам по FreeBSD посвящены два списка рассылки, `FreeBSD-questions` и `FreeBSD-hackers`. В некоторых случаях на самом деле не ясно, в каком списке нужно задавать вопрос. Следующий критерий, однако, должен помочь в 98% всех случаев:
. Если вопрос является общим, спрашивайте во `FreeBSD-questions`. Примерами могут служить вопросы по установке FreeBSD или использованию конкретных утилит UNIX(R).
-. Если вы думаете, что вопрос относится к ошибке, но вы не уверены или не знаете, как ее исправить, пошлите сообщение во `FreeBSD-questions`.
+. Если вы думаете, что вопрос относится к ошибке, но вы не уверены или не знаете, как её исправить, пошлите сообщение во `FreeBSD-questions`.
. Если вопрос относится к ошибке и вы __уверены__, что это ошибка (например, вы можете указать место в коде, где она происходит, и, может быть, у вас есть для нее исправление), то пошлите сообщение в список рассылки `FreeBSD-hackers`.
-. Если вопрос относится к усовершенствованию FreeBSD, и вы можете дать предложения по ее реализации, то посылайте сообщение во `FreeBSD-hackers`.
+. Если вопрос относится к усовершенствованию FreeBSD, и вы можете дать предложения по её реализации, то посылайте сообщение во `FreeBSD-hackers`.
Имеется также некоторое количество других extref:{handbook}eresources[специализированных списков рассылки, eresources-mail]. Здесь также подходит указанный выше критерий, и в ваших интересах следовать ему, потому что именно так можно получить результат.
@@ -128,7 +128,7 @@
** Если у вас возникли трудности при установке FreeBSD, пожалуйста, опишите ваше оборудование. В частности, важно знать адреса ввода/вывода и IRQ адаптеров, установленных в вашей машине.
** Если у вас возникли трудности в настройке PPP, опишите настройку. Какую версию PPP вы используете? Какой тип аутентификации? У вас используется статическое или динамическое выделение адресов IP? Какие сообщения вы получили в файле протокола?
-* Основной объем информации, который вы должны дать, представляет собой вывод программ, таких, как man:dmesg[8], или консольные сообщения, которые обычно появляются в файле [.filename]#/var/log/messages#. Не пытайтесь скопировать эту информацию, набрав ее снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как man:dmesg[8], перенаправьте вывод в файл и включите его в письмо. Например,
+* Основной объём информации, который вы должны дать, представляет собой вывод программ, таких как man:dmesg[8], или консольные сообщения, которые обычно появляются в файле [.filename]#/var/log/messages#. Не пытайтесь скопировать эту информацию, набрав её снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких как man:dmesg[8], перенаправьте вывод в файл и включите его в письмо. Например,
+
[source, shell]
....
@@ -174,7 +174,7 @@
Часто вам бывает нужно дать дополнительную информацию к вопросу, который вы уже отослали. Лучшим способом сделать это является ответ на первоначальное сообщение. Здесь есть три момента:
. Вы включаете текст исходного сообщения, чтобы люди знали, о чем вы говорите. Однако не забудьте удалить ненужный текст.
-. Текст в строке с темой письма остается тем же самым (вы не забыли его указать, не правда ли?). Многие почтовые программы сортируют сообщения по теме письма. Это поможет при группировке сообщений.
+. Текст в строке с темой письма остаётся тем же самым (вы не забыли его указать, не правда ли?). Многие почтовые программы сортируют сообщения по теме письма. Это поможет при группировке сообщений.
. Ссылочные номера сообщений в заголовке будут указывать на предыдущее сообщение. Некоторые почтовые программы, такие, как http://www.mutt.org/[mutt], могут _упорядочивать_ сообщения, показывая точную связь между ними.
== Как отвечать на вопрос
@@ -192,7 +192,7 @@
. Из исходного сообщения включите текст, который относится к делу. Избегайте излишнего цитирования, но не переусердствуйте. Тот, кто не читал первоначального сообщения, должен понять, о чём же идёт речь.
. Используйте приемы выделения текста, который взят из исходного сообщения и текста, который добавили вы. Лично я нахожу, что для первоначального текста лучше всего работает вставка символа "`>`". Вставка пробела после "`>`" и пустых строк между вашим и первоначальным текстами сделает результат более читабельным.
. Поместите ваш ответ в правильном месте (после текста, на который вы отвечаете). Очень трудно читать набор ответов, когда каждый из них следует перед текстом, к которому относится.
-. Большинство почтовых программ меняют строку темы письма в ответе, предваряя ее текстом типа "Re: ". Если ваша почтовая программа не делает это автоматически, вы должны делать это вручную.
+. Большинство почтовых программ меняют строку темы письма в ответе, предваряя её текстом типа "Re: ". Если ваша почтовая программа не делает это автоматически, вы должны делать это вручную.
. Если спрашивающий не следует соглашениям по форматированию текста (слишком длинные строки, неподходящая строка темы), __пожалуйста__, исправьте эти ошибки. В случае некорректной строки темы письма (типа "HELP!!??") измените её, например, так: "Re: Difficulties with sync PPP (was: HELP!!??)". В таком случае у других людей, пытающихся отследить обсуждение, будет меньше проблем.
+
В таких случаях хорошо сказать, что вы сделали и почему, но постарайтесь не грубить. Если вы чувствуете, что не можете ответить, не скатываясь на грубость, воздержитесь от ответа вообще.
-description: 'Описывает подход, используемый командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества. В нем описаны инструменты, доступные тем, кто заинтересован в создании настраиваемых релизов FreeBSD для корпоративного внедрения или коммерческой продуктивизации'
+description: 'Описывает подход, используемый командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества. В нём описаны инструменты, доступные тем, кто заинтересован в создании настраиваемых релизов FreeBSD для корпоративного внедрения или коммерческой продуктивизации'
organizations:
-
organization: 'The FreeBSD Foundation'
@@ -198,17 +198,17 @@
Если выпуск создаётся из существующей ветки {branchStable}, дату заморозки KBI можно исключить, так как KBI уже считается замороженным в устоявшихся ветках {branchStable}.
====
-При написании графика цикла выпуска необходимо учитывать ряд факторов, особенно этапы, на которые целевая дата зависит от предопределенных этапов, от которых существует зависимость. Например, тег выпуска коллекции портов берется из активной квартальной ветки на момент последнего `RC`. Это частично определяет, какая квартальная ветка используется, когда может быть создан тег выпуска и какая версия дерева портов используется для финальной сборки `RELEASE`.
+При написании графика цикла выпуска необходимо учитывать ряд факторов, особенно этапы, на которые целевая дата зависит от предопределённых этапов, от которых существует зависимость. Например, тег выпуска коллекции портов берется из активной квартальной ветки на момент последнего `RC`. Это частично определяет, какая квартальная ветка используется, когда может быть создан тег выпуска и какая версия дерева портов используется для финальной сборки `RELEASE`.
После общего согласования расписания команда {teamRe} отправляет расписание разработчикам FreeBSD по электронной почте.
-Вполне типично, что многие разработчики сообщают команде {teamRe} о различных работах в процессе выполнения. В некоторых случаях может быть запрошено продление для работы в процессе, а в других случаях может быть сделан запрос на "общее одобрение" для определенного подмножества дерева.
+Вполне типично, что многие разработчики сообщают команде {teamRe} о различных работах в процессе выполнения. В некоторых случаях может быть запрошено продление для работы в процессе, а в других случаях может быть сделан запрос на "общее одобрение" для определённого подмножества дерева.
При таких запросах важно убедиться, что обсуждаются сроки (даже если они приблизительные). Для общих одобрений следует четко указать продолжительность действия такого одобрения. Например, разработчик FreeBSD может запросить общее одобрение с начала периода мягкой заморозки кода до начала сборок `RC`.
[NOTE]
====
-Для отслеживания общих одобрений команда {teamRe} использует внутренний репозиторий, в котором ведется журнал таких запросов. В нем указывается область, на которую распространяется общее одобрение, автор(ы), срок действия одобрения и причина его выдачи. Например, может быть предоставлено общее одобрение для [.filename]#release/doc/# всем членам {teamRe} до финального `RC` для обновления примечаний к выпуску и другой связанной с выпуском документации.
+Для отслеживания общих одобрений команда {teamRe} использует внутренний репозиторий, в котором ведется журнал таких запросов. В нём указывается область, на которую распространяется общее одобрение, автор(ы), срок действия одобрения и причина его выдачи. Например, может быть предоставлено общее одобрение для [.filename]#release/doc/# всем членам {teamRe} до финального `RC` для обновления примечаний к выпуску и другой связанной с выпуском документации.
====
[NOTE]
@@ -502,7 +502,7 @@
[[releng-stable-branching]]
=== Создание ветки {branchRelengx}
-Когда первая сборка `RC` (Release Candidate) готова к началу, создается ветка {branchReleng}. Это многоэтапный процесс, который должен выполняться в определенном порядке, чтобы избежать аномалий, таких как пересечения значений `__FreeBSD_version`, например. Указанные ниже пути относятся к корню репозитория. Порядок коммитов и что нужно изменить:
+Когда первая сборка `RC` (Release Candidate) готова к началу, создается ветка {branchReleng}. Это многоэтапный процесс, который должен выполняться в определённом порядке, чтобы избежать аномалий, таких как пересечения значений `__FreeBSD_version`, например. Указанные ниже пути относятся к корню репозитория. Порядок коммитов и что нужно изменить:
[NOTE]
====
@@ -564,7 +564,7 @@
[[releng-build-scripts]]
=== Скрипты сборки релизов
-До выхода FreeBSD 9.0-RELEASE файл [.filename]#src/release/Makefile# был обновлен для поддержки , а скрипт [.filename]#src/release/generate-release.sh# был добавлен в качестве обертки для автоматизации вызова целей.
+До выхода FreeBSD 9.0-RELEASE файл [.filename]#src/release/Makefile# был обновлен для поддержки , а скрипт [.filename]#src/release/generate-release.sh# был добавлен в качестве обёртки для автоматизации вызова целей.
До выхода FreeBSD 9.2-RELEASE был представлен [.filename]#src/release/release.sh#, который, основываясь на [.filename]#src/release/generate-release.sh#, включал поддержку указания конфигурационных файлов для переопределения различных опций и переменных окружения. Поддержка конфигурационных файлов обеспечила возможность кросс-сборки каждого архитектурного варианта для релиза путем указания отдельного конфигурационного файла для каждого вызова.
@@ -662,7 +662,7 @@
[[releng-mirrors-publishing]]
=== Публикация установочных носителей FreeBSD
-Как только образы размещены в [.filename]#/archive/tmp/#, они готовы к публикации путем размещения в [.filename]#/archive/pub/FreeBSD#. Для уменьшения времени распространения используются жесткие ссылки из [.filename]#/archive/tmp# в [.filename]#/archive/pub/FreeBSD#.
+Как только образы размещены в [.filename]#/archive/tmp/#, они готовы к публикации путем размещения в [.filename]#/archive/pub/FreeBSD#. Для уменьшения времени распространения используются жёсткие ссылки из [.filename]#/archive/tmp# в [.filename]#/archive/pub/FreeBSD#.
_Отчёты о состоянии нужны не только для того, чтобы сообщать всем о выполненных задачах, но и для объяснения причин их выполнения._
-Продолжим предыдущий пример. Почему интересно, что мы теперь поддерживаем карты Yoyodyne Frobnicator? Они широко распространены? Они используются в каком-то конкретном популярном устройстве? Они применяются в определённой нише, где FreeBSD имеет (или хотела бы иметь) присутствие? Это самые быстрые сетевые карты на планете? В отчётах о состоянии часто встречаются такие фразы:
+Продолжим предыдущий пример. Почему интересно, что мы теперь поддерживаем карты Yoyodyne Frobnicator? Они широко распространены? Они используются в каком-то конкретном популярном устройстве? Они применяются в определённой нише, где присутствует (или хотела бы присутствовать) FreeBSD? Это самые быстрые сетевые карты на планете? В отчётах о состоянии работ часто встречаются такие фразы:
....
We imported Cyberdyne Systems T800 into the tree.
@@ -79,7 +79,7 @@
_Если требуется помощь, укажите это явно!_
-Нужна ли помощь с чем-то? Есть ли задачи, которые могут выполнить другие люди? Существует два способа использования раздела открытых пунктов в отчёте о состоянии: для запроса помощи или для быстрого обзора объёма оставшейся работы. Если над проектом уже работает достаточное количество людей или он находится в таком состоянии, что добавление новых участников не ускорит его, то лучше использовать второй вариант. Укажите крупные рабочие задачи, которые находятся в процессе выполнения, и, возможно, обозначьте, кто над каждой из них работает.
+Нужна ли помощь с чем-то? Есть ли задачи, которые могут выполнить другие люди? Имеются два способа использования раздела открытых вопросов в отчёте о состоянии работ: для запроса помощи или для быстрого обзора объёма оставшейся работы. Если над проектом уже работает достаточное количество людей или он находится в таком состоянии, что добавление новых участников не ускорит его, то лучше использовать второй вариант. Укажите крупные рабочие задачи, которые находятся в процессе выполнения, и, возможно, обозначьте, кто над каждой из них работает.
Перечислите задачи с достаточной детализацией, чтобы люди могли понять, смогут ли они их выполнить, и предложите им связаться с вами.
@@ -124,11 +124,11 @@
=== Сроки
-Отчёты всегда принимаются командой статуса, но основной процесс сбора происходит в последний месяц каждого квартала, то есть в марте, июне, сентябре и декабре. Месяцы январь, апрель, июль и октябрь посвящены сбору отчётов, представленных в предыдущем квартале. Отчёты за завершившийся квартал еще принимаются в первые 14 дней месяца, но не позже. Публикация статусных отчётов происходит в те же месяцы, как только отчёты будут готовы.
+Отчёты всегда принимаются командой статуса, но основной процесс сбора происходит в последний месяц каждого квартала, то есть в марте, июне, сентябре и декабре. Месяцы январь, апрель, июль и октябрь посвящены сбору отчётов, представленных в предыдущем квартале. Отчёты за завершившийся квартал ещё принимаются в первые 14 дней месяца, но не позже. Публикация статусных отчётов происходит в те же месяцы, как только отчёты будут готовы.
-Запросы отчётов о состоянии бдут отправляться с напоминанием о последнем дне для отправки отчёта.
+Запросы отчётов о состоянии работ будут отправляться с напоминанием о последнем дне для отправки отчёта.
-Проверка представленных отчётов людьми, не входящими в команду статуса, должна быть в основном завершена к середине января/апреля/июля/октября (срок заморозки отчётов для сторонней проверки). То есть, за исключением опечаток или других незначительных правок, команда статуса должна быть готова собирать представленные материалы в полный отчет начиная с 15-го числа.
+Проверка представленных отчётов людьми, не входящими в команду статуса, должна быть в основном завершена к середине января/апреля/июля/октября (срок заморозки отчётов для сторонней проверки). То есть, за исключением опечаток или других незначительных правок, команда статуса должна быть готова собирать представленные материалы в полный отчёт начиная с 15-го числа.
[cols="1,2,2,2,2"]
|===
@@ -181,7 +181,7 @@
[IMPORTANT]
====
-Если вы отвечаете за рассылку запросов отчётов о состоянии и используете задание cron, пожалуйста, запускайте его на freefall и подписывайте своим именем, чтобы в случае возникновения проблем можно было определить, кто настроил задание cron. Также, в качестве дополнительной меры предосторожности, обновите приведённый выше пример, указав свое имя.
+Если вы отвечаете за рассылку запросов отчётов о состоянии работ и используете задание cron, пожалуйста, запускайте его на freefall и подписывайте своим именем, чтобы в случае возникновения проблем можно было определить, кто настроил это задание cron. Также, в качестве дополнительной меры предосторожности, обновите приведённый выше пример, указав своё имя.
====
Также может быть полезно объявить сбор отчётов на форумах, как это link:https://forums.freebsd.org/threads/call-for-freebsd-2014q4-october-december-status-reports.49812/[делалось ранее].
@@ -227,7 +227,7 @@
[IMPORTANT]
====
-Это письмо должно быть одобрено, поэтому если вы отвечаете за отправку этого письма, убедитесь, что кто-то сделает это одобрение (напишите link:mailto:postmaster@FreeBSD.org[постмастеру], если одобрение займёт много времени).
+Это письмо должно быть одобрено, поэтому, если вы отвечаете за отправку этого письма, убедитесь, что кто-то сделает это одобрение (напишите link:mailto:postmaster@FreeBSD.org[постмастеру], если одобрение займёт много времени).
====
* одно на link:https://lists.freebsd.org/subscription/freebsd-hackers[freebsd-hackers@FreeBSD.org], которому добавьте link:https://lists.freebsd.org/subscription/freebsd-current[freebsd-current@FreeBSD.org] и link:https://lists.freebsd.org/subscription/freebsd-stable[freebsd-stable@FreeBSD.org] в копию (CC) и `developers@FreeBSD.org` в скрытую копию (BCC).
-Инструкции в этой статье относятся к более старой версии FreeBSD и могут не работать корректно в последних версиях ОС. В связи с появлением pkgbase, утилита freebsd-update планируется к удалению из FreeBSD в будущем. Когда это произойдет, статья будет либо обновлена с учетом новых процедур, либо полностью удалена.
+Инструкции в этой статье относятся к более старой версии FreeBSD и могут не работать корректно в последних версиях ОС. В связи с появлением pkgbase, утилита freebsd-update планируется к удалению из FreeBSD в будущем. Когда это произойдет, статья будет либо обновлена с учётом новых процедур, либо полностью удалена.
====
[.abstract-title]
@@ -64,7 +64,7 @@
[[introduction]]
== Введение
-Опытные пользователи или администраторы часто отвечают за несколько машин или окружений. Они понимают сложные требования и вызовы, связанные с поддержанием такой инфраструктуры. Запуск сервера обновлений FreeBSD упрощает развертывание исправлений безопасности и программного обеспечения на выбранных тестовых машинах перед их внедрением в рабочую среду. Это также означает, что множество систем могут быть обновлены из локальной сети, а не через потенциально медленное интернет-соединение. В этой статье описаны шаги, необходимые для создания внутреннего сервера обновлений FreeBSD.
+Опытные пользователи или администраторы часто отвечают за несколько машин или окружений. Они понимают сложные требования и вызовы, связанные с поддержанием такой инфраструктуры. Запуск сервера обновлений FreeBSD упрощает развёртывание исправлений безопасности и программного обеспечения на выбранных тестовых машинах перед их внедрением в рабочую среду. Это также означает, что множество систем могут быть обновлены из локальной сети, а не через потенциально медленное интернет-соединение. В этой статье описаны шаги, необходимые для создания внутреннего сервера обновлений FreeBSD.
[[prerequisites]]
== Предварительные требования
@@ -78,7 +78,7 @@
Минимальное требование для обновлений — сборка на версии FreeBSD, которая не меньше целевой версии для распространения.
====
* Пользовательская учётная запись с как минимум 4 ГБ свободного места. Это позволит создавать обновления для версий 7.1 и 7.2, но точные требования к месту могут меняться от версии к версии.
-* Учетная запись man:ssh[1] на удаленной машине для загрузки распределенных обновлений.
+* Учётная запись man:ssh[1] на удаленной машине для загрузки распределенных обновлений.
* Веб-сервер, например extref:{handbook}network-servers[Apache, network-apache], с более чем половиной пространства, необходимого для сборки. Например, тестовые сборки для версий 7.1 и 7.2 занимают в общей сложности 4 ГБ, а пространство веб-сервера, необходимое для распространения этих обновлений, составляет 2.6 ГБ.
* Базовые знания написания скриптов для оболочки Bourne shell, man:sh[1].
@@ -134,7 +134,7 @@
+
<.> Ключ SSH для загрузки файлов на сервер обновлений. Пару ключей можно создать, выполнив команду `ssh-keygen -t dsa`. Этот параметр необязателен; стандартная аутентификация по паролю будет использоваться в качестве резервного метода, если `SSHKEY` не определён. Более подробную информацию о SSH и соответствующих шагах по созданию и использованию ключей можно найти на man:ssh-keygen[1].
-<.> Учетная запись для загрузки файлов на сервер обновлений.
+<.> Учётная запись для загрузки файлов на сервер обновлений.
<.> Каталог на сервере обновлений, в который загружаются файлы.
Документация по программированию для ядра скудная, это одна из немногих областей программирования, где почти нет хороших учебных пособий, и совет "читай исходники!" - сохраняет свою справедливость. Однако, существует несколько статей и книг разной актуальности, которые рекомендуются к изучению перед тем, как начать программировать:
-* extref:{developers-handbook}[Руководство FreeBSD для разработчиков] - часть Проекта Документации FreeBSD, ничего специфичного о программировании ядра в нем нет, зато есть немного общей полезной информации.
+* extref:{developers-handbook}[Руководство FreeBSD для разработчиков] - часть Проекта Документации FreeBSD, ничего специфичного о программировании ядра в нём нет, зато есть немного общей полезной информации.
* extref:{arch-handbook}[Руководство по Архитектуре FreeBSD] - также является частью Проекта Документации FreeBSD, содержит описания некоторых низкоуровневых средств и процедур. Уделите внимание разделу номер 13 - extref:{arch-handbook}[Написание драйверов устройств для FreeBSD, driverbasics].
* Несколько интересных статей об устройстве ядра можно найти на сайте http://www.freebsddiary.com[FreeBSD Diary].
* Страницы из раздела номер 9 системного справочника, содержат важную документацию по функциям ядра.
@@ -137,7 +137,7 @@
Переменная `dumpdev` указывает на раздел подкачки, а `dumpdir` сообщает системе куда перемещать дамп ядра при следующей загрузке.
-Сохранение дампа ядра - процесс медленный, и, если у вашего компьютера много оперативной памяти (>256M) и если паники случаются часто, то ожидание сохранения дампов может начать раздражать (вспомним, что над дампом происходит две операции: сохранение в своп-файл и перемещение на файловую систему). В таком случае может оказаться удобным ограничивание объема используемой системой памяти путем установки переменной в [.filename]#/boot/loader.conf#:
+Сохранение дампа ядра - процесс медленный, и, если у вашего компьютера много оперативной памяти (>256M) и если паники случаются часто, то ожидание сохранения дампов может начать раздражать (вспомним, что над дампом происходит две операции: сохранение в своп-файл и перемещение на файловую систему). В таком случае может оказаться удобным ограничивание объёма используемой системой памяти путем установки переменной в [.filename]#/boot/loader.conf#:
[.programlisting]
....
@@ -192,23 +192,23 @@
Для того, чтобы можно было использовать этот макрос, необходимо включить следующие заголовочные файлы: [.filename]#sys/param.h#, [.filename]#sys/kernel.h# и [.filename]#sys/malloc.h#.
-Существует еще один механизм выделения памяти - UMA (Universal Memory Allocator), описанный в man:uma[9]. Это специфический метод, преимущественно предназначенный для быстрого выделения памяти под списки, состоящие из элементов одинакового размера (например, динамические массивы структур).
+Существует ещё один механизм выделения памяти - UMA (Universal Memory Allocator), описанный в man:uma[9]. Это специфический метод, преимущественно предназначенный для быстрого выделения памяти под списки, состоящие из элементов одинакового размера (например, динамические массивы структур).
[[kernelprog-lists]]
=== Очереди и списки
-Ознакомьтесь с man:queue[3] Во множестве случаев вам необходимо будет организовывать и управлять такой структурой данных, как списки. К счастью, эта структура данных реализована несколькими способами в виде макросов на Си, а также включена в систему. Наиболее гибкий и часто употребляемый тип списка - TAILQ. Этот тип списка также один из наиболее требовательных к памяти (его элементы - с двойными связями), а также - наиболее медленный (однако счет идет на несколько инструкций ЦПУ, поэтому последнее утверждение не следует воспринимать в всерьез).
+Ознакомьтесь с man:queue[3] Во множестве случаев вам необходимо будет организовывать и управлять такой структурой данных, как списки. К счастью, эта структура данных реализована несколькими способами в виде макросов на Си, а также включена в систему. Наиболее гибкий и часто употребляемый тип списка - TAILQ. Этот тип списка также один из наиболее требовательных к памяти (его элементы - с двойными связями), а также - наиболее медленный (однако счет идёт на несколько инструкций ЦПУ, поэтому последнее утверждение не следует воспринимать в всерьез).
Если важна скорость получения данных, то возьмите на вооружение man:tree[3] и man:hashinit[9].
[[kernelprog-bios]]
=== BIOs
-Структура `bio` используется для всех операций ввода/вывода, касающихся GEOM. Она содержит информацию о том, какое устройство ('поставщик geom') должно ответить на запрос, тип запроса, смещение, длину и указатель на буфер, а также набор "определенных пользователем" флагов и полей .
+Структура `bio` используется для всех операций ввода/вывода, касающихся GEOM. Она содержит информацию о том, какое устройство ('поставщик geom') должно ответить на запрос, тип запроса, смещение, длину и указатель на буфер, а также набор "определённых пользователем" флагов и полей .
-Важным моментом является то, что `bio` обрабатываются асинхронно. Это значит, что во многих частях кода нет аналога к man:read[2] и man:write[2] функциям из пространства пользовательских процессов, которые не возвращают управление пока не выполнится системный вызов. Скорее, по завершении обработки запроса (или в случае ошибки при обработке) как извещение вызывается определенная пользователем функция.
+Важным моментом является то, что `bio` обрабатываются асинхронно. Это значит, что во многих частях кода нет аналога к man:read[2] и man:write[2] функциям из пространства пользовательских процессов, которые не возвращают управление пока не выполнится системный вызов. Скорее, по завершении обработки запроса (или в случае ошибки при обработке) как извещение вызывается определённая пользователем функция.
-Асинхронная модель программирования в чем-то сложней, нежели чаще используемая императивная модель, используемая в пространстве пользовательских процессов; в любом случае, привыкание займет некоторое время. В некоторых случаях могут быть использованы вспомогательные функции `g_write_data`() и `g_read_data`(), но __далеко не всегда__. В частности, эти функции не могут использоваться когда захвачен мьютекс; например, мьютекс GEOM-топологии или внутренний мьютекс, удерживаемый в ходе выполнения `.start`() или `.stop`().
+Асинхронная модель программирования в чем-то сложней, нежели чаще используемая императивная модель, используемая в пространстве пользовательских процессов; в любом случае, привыкание займёт некоторое время. В некоторых случаях могут быть использованы вспомогательные функции `g_write_data`() и `g_read_data`(), но __далеко не всегда__. В частности, эти функции не могут использоваться когда захвачен мьютекс; например, мьютекс GEOM-топологии или внутренний мьютекс, удерживаемый в ходе выполнения `.start`() или `.stop`().
[[geom]]
== Программирование в системе GEOM
@@ -323,7 +323,7 @@
Системой GEOM в ядре ОС создаются и используются три потока выполнения (kernel threads):
-* `g_down` : Обрабатывает запросы, приходящие от высокоуровневых сущностей (таких, как запросы из пространства пользовательских процессов) на пути к физическим устройствам
+* `g_down` : Обрабатывает запросы, приходящие от высокоуровневых сущностей (таких как запросы из пространства пользовательских процессов) на пути к физическим устройствам
* `g_up` : Обрабатывает ответы от драйверов устройств на запросы, выполненные высокоуровневыми сущностями
* `g_event` : Отрабатывает в остальных случаях, как-то создание экземпляра geom, просчитывание прав доступа, события "повреждения" и т.п.
@@ -351,7 +351,7 @@
[[geom-kernelthreads]]
=== Ядерные потоки выполнения, предназначенные для использования в коде geom
-Ядерные потоки выполнения создаются функцией man:kthread_create[9], в своем поведении они схожи с потоками, созданными в пространстве пользовательских процессов, но есть одно отличие: они не могут известить вызвавший их поток о своем завершении; по завершению - необходимо вызывать man:kthread_exit[9].
+Ядерные потоки выполнения создаются функцией man:kthread_create[9], в своём поведении они схожи с потоками, созданными в пространстве пользовательских процессов, но есть одно отличие: они не могут известить вызвавший их поток о своём завершении; по завершению - необходимо вызывать man:kthread_exit[9].
В коде GEOM обычное назначение этих потоков - разгрузить поток `g_down` (функцию `.start`() ) от обработки запросов. Эти потоки подобны "обработчикам событий" ("event handlers"): у них есть очередь событий (которая наполняется событиями от разных функций из разных потоков; очередь необходимо защищать мьютексом), события из очереди выбираются одно за другим и обрабатываются в большом блоке `switch`().