Отчёт о состоянии работ FreeBSD за третий квартал 2026

Контакт: FreeBSD Core Team <core@FreeBSD.org>

Основная команда FreeBSD является руководящим органом FreeBSD.

Ссылки:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Технологическая дорожная карта URL: https://freebsdfoundation.org/blog/technology-roadmap/
Пожертвовать URL: https://freebsdfoundation.org/donate/
Программа партнёрства Фонда URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Мероприятия Фонда URL: https://freebsdfoundation.org/our-work/events/

Контакт: Deb Goodkin <deb@FreeBSDFoundation.org>

FreeBSD Foundation — это некоммерческая организация в соответствии с 501(c)(3), посвящённая продвижению FreeBSD посредством как технической, так и нетехнической поддержки. Полностью финансируемый за счёт пожертвований, Фонд поддерживает разработку программного обеспечения, инфраструктуру, безопасность и усилия по сотрудничеству; организует мероприятия и саммиты разработчиков; предоставляет образовательные ресурсы; и представляет Проект FreeBSD в юридических вопросах.

Ссылки:
Анонс FreeBSD 14.5-RELEASE URL: https://www.freebsd.org/releases/14.5R/announce/
График FreeBSD 15.2-RELEASE URL: https://www.freebsd.org/releases/15.2R/schedule/
Релизы FreeBSD URL: https://download.freebsd.org/releases/ISO-IMAGES/
Снимки разработки FreeBSD URL: https://download.freebsd.org/snapshots/ISO-IMAGES/

Контактное лицо: Команда управления релизами FreeBSD <re@FreeBSD.org>

Команда управления релизами FreeBSD отвечает за установление и публикацию графиков выпуска официальных релизов FreeBSD, объявление заморозок кода и поддержку соответствующих веток, среди прочего.

Команда управляла процессом выпуска 14.5-RELEASE, что привело к официальной сборке RELEASE и объявлению в сентябре. Началось планирование предстоящего 15.2-RELEASE, который должен выйти в декабре.

Команда управления релизами продолжила предоставление еженедельных промежуточных сборок для разработчиков для веток main, stable/15 и stable/14.

Ссылки:
Члены команды администрирования кластера URL: https://www.freebsd.org/administration/#t-clusteradm

Контакт: Cluster Administration Team <clusteradm@FreeBSD.org>
Контакт: Philip Paeps <philip@FreeBSD.org>

Члены команды администрирования кластера FreeBSD отвечают за управление машинами, на которые опирается проект для синхронизации своей распределённой работы и коммуникаций.

В этом квартале команда занималась следующим:

Ссылки:
FreeBSD Bugzilla URL: https://bugs.freebsd.org/
Общее число открытых ошибок во времени URL: https://bugs.freebsd.org/bugzilla/page.cgi?id=showreport.html&type=total_open_bugs_over_time

Контакт: Bugmeister <bugmeister@FreeBSD.org>

Ссылки:
Alpha-Omega — проект Linux Foundation URL: https://alpha-omega.dev
FreeBSD Foundation URL: https://freebsdfoundation.org
Информация о безопасности FreeBSD URL: https://www.freebsd.org/security/

Контакт: Pierre Pronchery <pierre@freebsdfoundation.org>

Это мой второй квартал в FreeBSD Foundation в рамках инициативы Security Engineers In Residence (SEIRs) от Alpha-Omega. Благодаря вкладу, полученному от Security Team, я интегрировал промежуточный экземпляр Forgejo с самостоятельно размещённой LLM, продемонстрировав потенциал новых возможностей для Security Team без нарушения каких-либо требований конфиденциальности. Эта система способна обрабатывать поступающие отчёты об уязвимостях безопасности путём:

Это реализовано как типичная современная система CI/CD с инструментом runner от Forgejo в виде рабочего процесса, совместимого с GitHub. Цель — задействовать возможности LLM в наших процессах в соответствии с текущим рабочим процессом, не жертвуя ни конфиденциальностью, ни необходимостью проверки качества со стороны нас, смертных членов команды безопасности.

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

Параллельно я не жалел усилий для соответствия европейскому Cyber Resilience Act (CRA) для Проекта FreeBSD. После импорта pkgconf в базовую систему FreeBSD в прошлом квартале я прошёл через ряд итераций фреймворка, генерирующего артефакты Software Bill of Material (SBOM) во время сборки. Подготовленный совместно с Tuukka Pasanen, фреймворк доступен для рецензирования в D56474, и теперь я считаю его серьёзным кандидатом на интеграцию. Хочу поблагодарить всех, кто уже предоставлял отзывы! Это чрезвычайно помогло найти баланс, который ощущается более правильным, чем когда-либо ранее, — по крайней мере, для меня. Отдельный запрос на рецензирование метаданных теперь также доступен — D60352, который в настоящее время генерирует в общей сложности 218 артефактов для сборки amd64. Баланс состоит примерно из одного артефакта на генерируемый базовый пакет, а также одного артефакта на каждую библиотеку, фактически используемую во время сборки. Таким образом, можно отследить полную цепочку зависимостей, сохраняя гранулярность близкой к отдельным сторонним проектам или внутренним компонентам.

Я также хотел бы выразить благодарность Alice Sowerby и Peter Hansteen за прекрасный семинар по соответствию CRA во время EuroBSDCon 2026 в Брюсселе в сентябре 2026 года. Если вы его пропустили, вам может повезти, поскольку мы готовимся провести его снова на будущем мероприятии. Не стесняйтесь обращаться к нам, если вы заинтересованы, указав ваше примерное местоположение и гибкость в поездках, чтобы мы могли получить более точное представление о времени и местах, к которым стоит стремиться.

Спонсор: Alpha-Omega, Фонд FreeBSD

Ссылки:
Cyber Resilience Act Readiness URL: https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

Фонд в течение 2026 года ведёт проект по активной подготовке FreeBSD Foundation, Проекта и сообщества к EU Cyber Resilience Act. Есть шесть основных направлений: безопасность и обработка уязвимостей, инструментарий SBOM, публичная документация, взаимодействие сообщества с законодателями, публичный репозиторий проекта и коммуникации.

В третьем квартале проект продолжал переходить от планирования к реализации, с особым упором на готовность к требованиям CRA по сообщению об уязвимостях и инцидентах, которые вступили в силу для производителей 11 сентября 2026 года.

Фонд создал политику кибербезопасности и протокол отчётности CRA, чтобы помочь Фонду выполнять свои обязательства как распорядителя открытого программного обеспечения. Оба документа разработаны с участием Основной Команды (Core Team) и Команды инженера по безопасности (Security Team) FreeBSD и описывают, как Фонд будет работать с Проектом и реагировать, если для Фонда как распорядителя сработают обязательства по отчётности CRA. Отметим, что Европейская комиссия разъяснила, что обязательства по отчётности для распорядителей начинаются 11 декабря 2027 года. На данный момент эти документы останутся внутренними ресурсами.

Техническая работа над инструментарием Software Bill of Materials (SBOM) продолжалась в виде разработки, тестирования и рецензирования. Предлагаемый подход к генерации SBOM для базовой системы FreeBSD уточняется в ответ на отзывы и всё ещё требует дальнейшего рецензирования и сопутствующих изменений перед интеграцией. Работа также продвигается в более широкой экосистеме SBOM — как через Фонд, так и в сообществе, — включая планируемую поддержку портов, совместимую со SPDX информацию о лицензиях, а также поддержку SBOM CycloneDX и SPDX в pkgconf.

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

Фонд продолжал взаимодействовать с сообществом FreeBSD и более широким сообществом открытого исходного кода, особенно с рабочей группой Open Regulatory Compliance (ORC) фонда Eclipse Foundation. На EuroBSDCon 2026 мы совместно с Peter Hansteen провели однодневный учебный курс по CRA и SBOM. Мы также представили обновление по этому проекту на FreeBSD Developer Summit.

Обновления проекта и заметки о встречах продолжают публиковаться в публичном репозитории проекта. При переходе в четвёртый квартал основное внимание будет уделено продвижению реализации SBOM и вышестоящей работы, улучшению обнаруживаемости нашего публичного руководства по CRA, а также работе с Проектом FreeBSD по выявлению ключевых потребностей производителей, связанных с их обязательством по CRA внедрить безопасный жизненный цикл программного обеспечения к 11 декабря 2027 года.

Ссылки:
sys/arm/arm/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59528
sys/powerpc/powerpc/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59527
sys/powerpc/powerpc/busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59526
sys/x86/x86/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59525
sys/x86/x86/busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59524
sys/kern/subr_busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59523
D60352 URL: https://reviews.freebsd.org/D60352 D60441 URL: https://reviews.freebsd.org/D60441

Открытые upstream PR по SPDX license identifier:
ATF PR#128 URL: https://github.com/freebsd/atf/pull/128
bmake NetBSD GNATS#60308 URL: https://gnats.netbsd.org/60308
LDNS ISSUE#305 URL: https://github.com/NLnetLabs/ldns/issues/305
Less PR#792 URL: https://github.com/gwsw/less/pull/792
Libarchive PR#3129 URL: https://github.com/libarchive/libarchive/pull/3129
LibCBOR ISSUE#430 URL: https://github.com/PJK/libcbor/issues/430
Libevent ISSUE#1864 URL: https://github.com/libevent/libevent/issues/1864
LibPCAP PR#1689 URL: https://github.com/the-tcpdump-group/libpcap/pull/1689
LibUCL PR#386 URL: https://github.com/vstakhov/libucl/pull/386
TCSH Mantis#777 URL: https://bugs.astron.com/view.php?id=777

Контакт: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

Работа над перечнем программных компонентов FreeBSD (SBOM) продолжалась в третьем квартале 2026 года. Наконец, включение SBOM в исходники FreeBSD обретает реальные очертания и, как мы надеемся, будет завершено в четвёртом квартале. Благодаря Pierre Pronchery идёт обзор в Phabricator: D60352 для исходников FreeBSD. Кроме того, для портов есть обзор: D60441, сделанный Mathieu Arnold.

В качестве вариантов вывода SBOM сейчас доступны SPDX 2.2 и Lite 3.0.1. Инструмент CycloneDX SBOM находится в разработке и всё ещё требует доработки, чтобы быть столь же качественным, как вывод SPDX. В будущем все варианты вывода SBOM будут объединены в одном инструменте под названием sbomtool, и, поскольку оба решения полагаются на pkgconf, они получат поддержку CycloneDX, когда она появится в исходниках FreeBSD.

Кроме того, были приняты несколько новых SPDX License Identifiers. Все три присутствуют в исходниках FreeBSD: * BSD-2-Clause-pos-unchanged * BSD-Source-Code-no-disclaimer * BSD-Source-alt-GPL

На рассмотрении находится несколько обновлений с BSD-2-Clause на BSD-Source-beginning-file:

Кроме того, многие сторонние репозитории получили SPDX License Identifiers, например libxo (спасибо Juniper за это), и другие. Некоторые проекты не хотят добавлять заголовки, а некоторые всё ещё находятся в активной разработке.

Если вы хотите помочь в этой работе:

Спонсор: Фонд FreeBSD

Ссылки:
sys/arm/arm/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59528
sys/powerpc/powerpc/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59527
sys/powerpc/powerpc/busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59526
sys/x86/x86/busdma_machdep.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59525
sys/x86/x86/busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59524
sys/kern/subr_busdma_bounce.c: исправление SPDX-License-Identifier URL: https://reviews.freebsd.org/D59523
D60352 URL: https://reviews.freebsd.org/D60352 D60441 URL: https://reviews.freebsd.org/D60441

Открытые upstream PR по SPDX license identifier:
ATF PR#128 URL: https://github.com/freebsd/atf/pull/128
bmake NetBSD GNATS#60308 URL: https://gnats.netbsd.org/60308
LDNS ISSUE#305 URL: https://github.com/NLnetLabs/ldns/issues/305
Less PR#792 URL: https://github.com/gwsw/less/pull/792
Libarchive PR#3129 URL: https://github.com/libarchive/libarchive/pull/3129
LibCBOR ISSUE#430 URL: https://github.com/PJK/libcbor/issues/430
Libevent ISSUE#1864 URL: https://github.com/libevent/libevent/issues/1864
LibPCAP PR#1689 URL: https://github.com/the-tcpdump-group/libpcap/pull/1689
LibUCL PR#386 URL: https://github.com/vstakhov/libucl/pull/386
TCSH Mantis#777 URL: https://bugs.astron.com/view.php?id=777

Контакт: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

Работа над перечнем программных компонентов FreeBSD (SBOM) продолжалась в третьем квартале 2026 года. Наконец, включение SBOM в исходники FreeBSD обретает реальные очертания и, как мы надеемся, будет завершено в четвёртом квартале. Благодаря Pierre Pronchery идёт обзор в Phabricator: D60352 для исходников FreeBSD. Кроме того, для портов есть обзор: D60441, сделанный Mathieu Arnold.

В качестве вариантов вывода SBOM сейчас доступны SPDX 2.2 и Lite 3.0.1. Инструмент CycloneDX SBOM находится в разработке и всё ещё требует доработки, чтобы быть столь же качественным, как вывод SPDX. В будущем все варианты вывода SBOM будут объединены в одном инструменте под названием sbomtool, и, поскольку оба решения полагаются на pkgconf, они получат поддержку CycloneDX, когда она появится в исходниках FreeBSD.

Кроме того, были приняты несколько новых SPDX License Identifiers. Все три присутствуют в исходниках FreeBSD: * BSD-2-Clause-pos-unchanged * BSD-Source-Code-no-disclaimer * BSD-Source-alt-GPL

На рассмотрении находится несколько обновлений с BSD-2-Clause на BSD-Source-beginning-file:

Кроме того, многие сторонние репозитории получили SPDX License Identifiers, например libxo (спасибо Juniper за это), и другие. Некоторые проекты не хотят добавлять заголовки, а некоторые всё ещё находятся в активной разработке.

Если вы хотите помочь в этой работе:

Спонсор: Фонд FreeBSD

Ссылки:
Страница руководства fts(3) URL: https://man.freebsd.org/cgi/man.cgi?fts(3)

Контакт: Jitendra Bhati <jitendrabhati2026@gmail.com>
Контакт: Alan Somers <asomers@FreeBSD.org>

Библиотека обхода каталогов fts(3), используемая find(1), rm(1), ls(1), chflags(1) и другими утилитами, исторически полагалась на системные вызовы на основе путей, которые не работают в режиме возможностей capsicum(4).

В этом квартале fts получила новую точку входа fts_openat(), принимающую предварительно открытый дескриптор каталога, поле fts_dirfd для каждой записи и преобразование её внутренностей в операции относительно файловых дескрипторов, с сохранением совместимости ABI посредством версионирования символов ELF. Теперь обход может выполняться полностью внутри песочницы Capsicum.

В качестве первого потребителя chflags был переведён в Capsicum для выполнения своей работы через chflagsat() над дескрипторами, открытыми до входа в режим возможностей, что ограничивает его иерархиями, указанными в его командной строке.

Эта работа была выполнена в рамках проекта Google Summer of Code 2026.

Спонсор: Google Summer of Code 2026

Контакт: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Ссылки:
Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/
Bhyvemgrd URL: https://github.com/alonsobsd/bhyvemgrd/

Контакт: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr — это графический интерфейс управления bhyve, написанный на Freepascal/Lazarus во FreeBSD. Ему требуется набор инструментов, большинство из которых установлено в базовой системе, а некоторые устанавливаются из портов/пакетов. Основная цель — быть настольным приложением, ориентированным на пользователей настольных систем, чтобы легко и быстро настраивать и запускать виртуальные машины на хостах FreeBSD.

Начиная с версии v2.0.0, bhyvemgr был переведён на клиент-серверную архитектуру. В результате был разработан серверный компонент. Этот новый компонент называется bhyvemgrd.

Bhyvemgrd поддерживает два способа выполнения привилегированных задач: mac_do/mdo (FreeBSD >= 140000) и mac_do/setcred/exec_paths (только для FreeBSD >= 1501501). Сам процесс выполняется под непривилегированным пользователем bhyvemgrd.

За последние два квартала было внесено множество исправлений ошибок и улучшений в Bhyvemgr.

Вот некоторые из основных добавленных возможностей:

Bhyvemgr и Bhyvemgrd поддерживают aarch64 с 15.x до 16-CURRENT и amd64 с FreeBSD 14.x до 16-CURRENT. Bhyvemgr можно скомпилировать или установить из sysutils/bhyvemgr с поддержкой интерфейса gtk2, qt5 или qt6. Bhyvemgrd можно скомпилировать или установить из sysutils/bhyvemgrd.

Люди, заинтересованные в помощи или поддержке проектов, приглашаются.

Текущая версия bhyvemgr: 2.1.0 Текущая версия bhyvemgrd: 1.2.0

Спонсор: https://paypal.me/alonsocbsd

Ссылки:
Задача проекта поддержки и удобства использования ноутбуков URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/25
Репозиторий проекта URL: https://gitlab.com/alfix/kde-installer-dialogs

Контакт: Alfonso S. Siciliano <asiciliano@FreeBSD.org>

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

В первом отчёте о состоянии за 2026 год было описано возможное решение: shell-скрипт примерно из 400 строк кода для установки и автоматической настройки компонентов, необходимых для графического окружения рабочего стола, включая драйверы GPU, Xorg, KDE Plasma и SDDM. После призыва к тестированию, который получил значительное количество отзывов от пользователей, на рассмотрение была подана рецензия D56167 для добавления нового скрипта рабочего стола в bsdinstall.

После подачи рецензии состоялось несколько обсуждений предложенной реализации. По результатам рецензии было запрошено разделить скрипт на более мелкие компоненты и перенести часть его функциональности в отдельные порты. Рецензия D56167 теперь устарела. Затем было проанализировано и протестировано несколько возможных подходов.

Выбранное решение — создание новых портов с вариантами (flavors).

Базовый порт предоставляет инструменты для построения меню и/или возврата скрипту списка пакетов для установки. Утилиты меню реализованы как shell-скрипты, поскольку разработка API Lua для текстовых пользовательских интерфейсов всё ещё продолжается.

Каждый вариант предоставляет скрипт pkg-post-install-lua(5) для настройки пакета, установленного в новой системе. pkg-post-install-lua был выбран вместо shell-скрипта pkg-post-install(5), потому что это облегчит повторное использование кода, если в будущем возникнет необходимость использовать pkg-trigger(5).

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

В репозитории проекта также завершён новый черновик скрипта рабочего стола. Он существенно отличается от исходного скрипта и теперь составляет примерно 100 строк кода. Новая рецензия на добавление скрипта рабочего стола в bsdinstall будет подана после того, как новые порты будут добавлены в коллекцию портов.

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

Спонсор: Фонд FreeBSD

Ссылки:
Веб-сайт URL: https://sylve.io
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Контакт: Hayzam Sherif <hayzam@alchemilla.io>

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

Бэкенд реализован на Go, а фронтенд построен на Svelte. Проект делает упор на минимальный системный след. По умолчанию он не требует каких-либо пакетов вне базовой системы.

Необязательные зависимости среды выполнения, требуемые только при использовании соответствующих функций, включают:

Порт подтягивает эти зависимости для удобства пользователя, но сам по себе Sylve не требует зависимостей для работы.

Ссылки:
Руководство по доступности URL: https://docs.freebsd.org/en/books/accessibility/
Репозиторий проекта URL: https://gitlab.com/alfix/freebsd-accessibility/
LearnBraille URL: https://gitlab.com/-/snippets/6065143
bsddialog URL: https://gitlab.com/alfix/bsddialog

Контакт: Accessibility <accessibility@FreeBSD.org>
Контакт: Alfonso S. Siciliano <asiciliano@FreeBSD.org>

Vision Accessibility — это проект, направленный на улучшение визуальной доступности во FreeBSD путём документирования, разработки и интеграции вспомогательных технологий для слепых и слабовидящих пользователей.

Ссылки:
x11appjail на GitHub URL: https://github.com/DtxdF/x11appjail
Контакт: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

x11appjail — это специализированный инструмент для создания, проверки, установки и запуска AppJail. AppJail — это приложение CLI, TUI или X11, которое работает внутри джейла FreeBSD, но воспринимается конечным пользователем как идентичное (или по крайней мере очень похожее) приложению, работающему непосредственно в хост-системе.

Этот инструмент широко использует appjail(1) в качестве своего движка; однако, в отличие от последнего, основным пользователем в x11appjail является не root и не привилегированный пользователь, а непривилегированный пользователь. Фундаментальная цель этого проекта — предоставить пользователю ограниченный доступ к джейлу, ограниченный исключительно выполнением приложения CLI, TUI или X11.

Этот проект начался несколько месяцев назад как прототип для установления рабочего процесса с использованием appjail-x11(1); однако, начиная с версии 1.0.0, он был переписан с нуля в единый инструмент, который интегрирует все его проекты, такие как sysutils/appjail, sysutils/unixexec, archivers/appscript и sysutils/jtransfer, среди прочих. Что ещё лучше, он позволяет выполнять не только приложения X11, но и программы CLI и TUI.

Наиболее значимым проектом для x11appjail(1) является не только appjail(1), но и appscript(1). Моя цель с appscript(1) — создать сверхлёгкую альтернативу AppImage для FreeBSD, которая не зависит от FUSE, тем самым устраняя необходимость настройки vfs.usermount=1. appscript(1) позволяет создать исполняемый файл elf(5), который содержит всё необходимое для запуска самодостаточного исполняемого файла.

Наиболее значительные изменения и улучшения для appscript(1) и x11appjail(1):

Ещё одно заметное изменение, о котором стоит упомянуть для x11appjail(1), — это примеры, добавленные в ${EXAMPLESDIR}/Apps: badwolf, chromium, evince, feh, firefox, htop, linux-brave, mpv, nanonote, telegram-desktop и thunderbird. Помимо самих приложений, ключевым фактором является способ развёртывания. htop — это пример приложения CLI, linux-brave — приложение Linux, а остальные — приложения X11. Веб-браузеры, Mpv и Thunderbird — наиболее интересные примеры, поскольку они демонстрируют, как AppJail может использовать VirtualGL для правильного включения аппаратного ускорения внутри джейла FreeBSD, что обычно было бы невозможно, учитывая, что Xephyr является бэкендом, используемым appjail-x11(1). Что лучше всего, с точки зрения конечного пользователя, всё это прозрачно.

Демонстрационное видео: https://youtu.be/EBSMHBC0Phc

Спонсор: https://www.patreon.com/appjail

Ссылки:
link: Серия коммитов порта URL: https://github.com/linux-rdma/rdma-core/pull/1778
link: Проект LinuxAPI URL: https://github.com/freebsd/linuxapi

Контакт: Konstantin Belousov <kib@FreeBSD.org> Контакт: Ariel Ehrenberg <aehrenberg@nvidia.com> Контакт: Slava Shwartsman <slavash@nvidia.com> Контакт: Gleb Popov <arrowd@FreeBSD.org>

Инфраструктура Remote Direct Memory Access (RDMA) обеспечивает высокопроизводительное межсоединение между вычислительными узлами и узлами хранения. Она может работать поверх различных физических сетей, например Ethernet и Infiniband.

Реализация стека RDMA состоит из нескольких компонентов. Есть ядерная инфраструктура и драйверы для Host Channel Adapters (HCA), обеспечивающие доступ к verbs ядра (прим. переводчика: verbs — стандартный API RDMA/InfiniBand). Пользовательские приложения никогда не взаимодействуют с устройствами ядра напрямую; основная библиотека libibverbs и зависящие от вендора пользовательские драйверы предоставляют унифицированные и специфичные для устройства verbs.

Поскольку RDMA нацелена на операции с низкой задержкой и малыми накладными расходами, производительные HCA снимают с CPU множество операций. Кроме того, типичные встроенные операции, такие как отправка и приём, могут инициироваться и завершаться в пользовательском пространстве, где ядро лишь помогает при установлении и разрыве соединения. Из-за этого пользовательский программный стек RDMA критически важен для её работы.

Базовая система FreeBSD включает порт так называемого ядерного компонента OFED, ядерные драйверы, а также пользовательское ядро (libibverbs) и пользовательские драйверы, например libmlx5 для управления HCA Nvidia Connect-X4 и более поздними. Со временем ядерные части получают значительные обновления из кода infiniband в ядре Linux, который становится домом для обновлённого OFED. Пользовательская часть OFED была преобразована в пользовательский проект rdma-core, который поддерживает только Linux (и glibc). Поскольку пользовательские драйверы в rdma-core обеспечивают существенную функциональность, а пользовательские компоненты RDMA во FreeBSD довольно устарели, ситуация в целом требует решения.

Мы попытались обновить внутрисистемные пользовательские компоненты, импортировав серию коммитов rdma-core с зависимостями, но быстро выяснилось, что это нецелесообразно. Вместо этого мы начали изучать, что потребуется, чтобы заставить rdma-core компилироваться и работать во FreeBSD.

Во-первых, был ряд отсутствующих специфичных для glibc API, которые использовались в rdma-core, например strdupa() и подобные, main:tdestroy(3), некоторые функции pthread. Их было легко обработать в базовой системе, и их добавление пошло на пользу всей истории портирования FreeBSD.

Далее, и более серьёзно, непортируемые особенности glibc использовались повсюду в исходниках, и попытка охватить их все вызвала бы огромный патч портирования, который проблематично отправить в upstream, даже для сотрудничающего upstream. Вместо этого была сформирована и разработана идея использования подхода, аналогичного LinuxKPI для кода ядра, названного LinuxAPI. В отличие от LinuxKPI, который обрабатывает архитектурные несоответствия между ядром Linux и ядром FreeBSD в дополнение к различным C-интерфейсам, LinuxAPI должен сглаживать различия вокруг расширений одной и той же базовой функциональности, определённой POSIX. Речь в основном идёт о частях, которые не определены POSIX, но необходимы для работы RDMA, таких как перечисление сетевых интерфейсов или обнаружение устройств с поддержкой rdma и их возможностей и т. д.

Похоже, люди уже считают LinuxAPI полезным за пределами усилий по портированию rdma-core; есть проект github.com/freebsd/linuxapi, который берёт разработанный набор заголовков и расширяет его дальше. В настоящее время мы работаем над предоставлением разрешительной лицензии, чтобы сделать библиотеку полезной без дополнительных условий.

Наша первоначальная цель, также ограниченная доступным оборудованием, — заставить rdma-core работать с картами ConnectX-4. Разумеется, мы приветствуем всех вендоров, заинтересованных в RDMA во FreeBSD, улучшать порт для надлежащей поддержки их карт.

Результат портирования доступен в виде репозитория. Мы также стараемся отправить изменения в upstream, чтобы FreeBSD стала второй нативно поддерживаемой платформой для rdma-core. Pull Request в проект на github отправлен. В настоящее время идёт блокирующее обсуждение о способе организации CI для платформы FreeBSD. Глеб Попов создал порт net/rdma-core из ответвлённых исходников, который уже находится в дереве портов.

Изменения ядра, необходимые для работы порта, были на удивление небольшими и локализованными. Они в основном состояли из исправлений ошибок в путях кода, ранее не задействованных пользовательским пространством, поскольку пользовательского пространства не было. Самая интересная часть — пожалуй, разница в поведении ioctl(2) между Linux и FreeBSD, где Linux может одновременно вернуть ошибку и выполнить copyout структуры данных. Эта проблема уже наблюдалась в LinuxKPI, и работа по портированию предоставила там общее решение.

Спонсор: Nvidia networking

Ссылки:
Актуальные исходники NFS-сервера в ветке freebsd-rdma URL: https://github.com/viniciusferrao/freebsd-src.git nfs-over-rdma-setup.txt URL: https://people.freebsd.org/~rmacklem/nfs-over-rdma-setup.txt

Контакт: Rick Macklem <rmacklem@freebsd.org>, Vinicius Ferrao <ferrao@versatushpc.com.br>

В настоящее время NFS в FreeBSD поддерживается через TCP (и UDP для NFSv3). Этот проект добавляет поддержку NFS через RDMA, как описано в RFC-8166 и RFC-8267. Это должно позволить RDMA-совместимым сетевым картам разгрузить большую часть сетевого транспорта и повысить производительность в быстрых локальных сетях.

Благодаря Vinicius был достигнут значительный прогресс. У него работает серверная сторона NFS, и, насколько я знаю, довольно хорошо.

Клиентская сторона теперь довольно хорошо тестируется против сервера Vinicius, и как клиент, и сервер готовы к тестированию третьими сторонами. Для тестирования требуются клиент и сервер с сетевыми картами Mellanox ConnectX4→6, работающие на ядре, собранном из недавних исходников FreeBSD main.

Информацию о настройке тестовой среды см. в nfs-over-rdma-setup.txt.

Ядра stable/15 должно быть достаточно для загружаемых модулей через несколько недель. Клиентский код также должен быть закоммичен в FreeBSD main через несколько недель, с MFC в stable/15 к концу 2026 года. Серверный код был создан с помощью генеративного ИИ, и проект FreeBSD работает над политикой обработки материалов, созданных генеративным ИИ. Тем временем серверный код будет доступен как "неофициальный порт", собирающий загружаемый модуль ядра.

Мы были бы очень признательны тестированию третьими сторонами.

Спасибо Vinicius за работу над NFS-сервером и участникам кластера FreeBSD Netperf, без которых я бы никогда не протестировал этот код.

Спонсор серверного кода NFS: Verastus HPC

Ссылки:
D59438 URL: https://reviews.freebsd.org/D59438
rG60c7313074b9 URL: https://cgit.freebsd.org/src/commit/?id=60c7313074b93adf4ea70ff44b78b3b4fc15c29f

Контакт: Devin Teske <dteske@FreeBSD.org>

nfsstat(1) сообщает о сервере в целом. nfsdtop(8) сообщает о пользователе, группе или клиенте, стоящем за чтением и записью. Это дисплей в стиле top, снимаемый с помощью dtrace(1) с путей nfsd(8) nfsrvd_read, nfsvno_read, nfsrvd_write и nfsvno_write.

Представление по умолчанию — по пользователям. -g объединяет по группе, а -c — по IPv4-клиенту. На каждом интервале выводится итог, а затем строки, выполнявшие ввод-вывод, отсортированные по суммарному объёму чтения и записи. Интервал по умолчанию — две секунды. Столбцы показывают пропускную способность в человекочитаемом представлении, если только -b не запрашивает объём байтов, перемещённых за этот интервал. WRITE(IN) — данные, отправленные клиентами. READ(OUT) — данные, отправленные сервером.

UID, GID или адрес клиента на этих путях принадлежат клиенту, а не серверу. nfsdtop(8) не обращается к getent(1) для их именования во время выборки. Имена берутся из файлов сопоставления в текущем каталоге: .nfsd.passwd, .nfsd.group и .nfsd.hosts. Фильтр (-U, -G или -C) разрешается один раз из этих карт, а затем с помощью getent(1) или host(1), и результат компилируется в предикат dtrace(1).

-j выдаёт один JSON-объект для итога представления и один на каждый ключ, на каждом интервале, с количеством байтов и скоростями. -J выбирает представления клиентов, групп и пользователей вместе:

Запускать может только root или пользователь, способный запускать dtrace(1). Представление клиентов и -C работают только с IPv4. -R или непустой NFSDTOP_REDACT заменяет имена, не являющиеся общеизвестными системными учётными записями, случайными строками той же длины.

Введение присутствует в HEAD начиная с 60c7313074b9 (D59438), и nfsdtop(8) впервые выйдет в FreeBSD 16.0.

Спасибо Alexander Ziaee и Benedict Reuschling за страницу руководства, Adrian Chadd за рецензию и Rick Macklem за взгляд на сторону NFS.

Запускайте его на сервере, который уже под нагрузкой. Если вам нужна строка — не пользователь, не группа и не клиент, пожалуйста, напишите.

Ссылки:
Страница проекта GSoC в вики URL: https://wiki.freebsd.org/SummerOfCode2026Projects/EnhancingZonedStorageSupportOnFreeBSD

Контакт: voidanix <voidanix@FreeBSD.org>

Контакт: Minsoo Choo <mchoo@FreeBSD.org>

С мая по август я был занят в университете и теперь вернулся к работе над этим проектом. Поскольку я не смог выполнить эту задачу для LLVM 23, целевой выпуск для завершения изменён на LLVM 24.

Теперь кандидатами на поддержку являются armv7 и powerpc64be. Как только рефакторинг LLDB будет завершён, я реализую поддержку этих архитектур.

В отличие от KGDB, который использует собственный анализатор кадров для размотки trapframe, LLDB использует вместо этого DWARF CFI. DWARF CFI работает и в KGDB; когда кадр не распознаётся анализатором кадров KGDB, он переключается на CFI. Таким образом, на стороне KGDB никаких изменений не требуется.

Спонсор: Фонд FreeBSD

Контакт: Konstantin Belousov <kib@FreeBSD.org>

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

Полуочевидное решение здесь — ввести pdptrace(2), который эквивалентен ptrace(2), но принимает дескриптор процесса в качестве обозначения процесса. Нам нужно уметь получать уведомления о событиях отладки процесса, которые предоставляются семейством системных вызовов waitpid[2] для управления по pid. И нам нужен способ получать дескриптор процесса для нового потомка, ответвлённого от отлаживаемой программы, чтобы продолжать трассировку всех потомков.

Ранее был добавлен системный вызов pdopenpid(2), который позволяет получить дескриптор произвольного процесса. Существующие операции над дескрипторами процессов несколько ограничены: владелец дескриптора может ожидать уведомление о завершении с помощью kqueue(2) и при некоторой удаче получить статус завершения процесса.

Последний пункт требует некоторых пояснений. Поскольку вызов pdwait(2) был добавлен недавно, в ядре было некоторое количество обходных решений, позволявших вызовы waitpid(2) для pid процессов, созданных с помощью pdfork(2). В результате вызывающий waitpid(2) мог забрать процесс раньше, чем владелец дескриптора процесса смог вызвать pdwait(2). Аналогично, если на один и тот же процесс открыто более одного дескриптора процесса, только первый вызывающий pdwait(2) мог получить статус завершения с помощью pdwait(2), делая остальные дескрипторы бесполезными.

Перечисленный набор проблем также делал очень трудным корректное использование предложенного pdptrace(2). Отлаживаемый процесс мог перехватывать события у дескрипторов процессов, и наоборот. Простое запрещение wait(2) для процессов с открытыми дескрипторами не является вариантом по двум причинам: * обратная совместимость: waitpid(2) уже был разрешён, и существующие бинарные файлы полагались на него * если отлаживаемая программа использовала fork(2) для создания потомка, она ожидает получить уведомление о завершении (например, SIGCHLD) и статус завершения от wait(2)

Решение было многосторонним. Во-первых, мы должны отложить сбор (reaping), если есть открытые дескрипторы процессов, или, если процесс был создан с помощью fork(2), мы не должны собирать его до тех пор, пока родитель не вызовет wait(2) по pid. Во-вторых, статус завершения нужно сохранять в приватных данных дескрипторов процесса даже после сбора, чтобы позволить pdwait(2) по любому из дескрипторов. Это было реализовано путём предоставления битовой карты «ссылок зомби» в структуре ядра struct proc. Каждая ссылка зомби предотвращает сбор и очищается соответствующим вызовом waitpid(2) или pdwait(2). Только когда все зарегистрированные ссылки очищены, зомби может быть собран. Если процесс создан с помощью pdfork(2) или открыт с помощью pdopenpid[2], он получает ссылку зомби procdesc. Если процесс был создан с помощью fork(2), он получает ссылку зомби «родитель». По умолчанию pdfork[2] также устанавливает родительскую ссылку, чтобы разрешить waitpid(2) для совместимости. Новый флаг pdfork(2) PD_NOWAITPID предотвращает это.

Затем события, подобные wait, должны работать с дескрипторами процессов. Фильтр событий kqueue(2) для procdesc был расширен подсказками NOTE_PDSIGCHLD, чтобы сообщать, что pdwait(2) может получить событие трассировки или завершения по дескриптору.

Затем pdptrace(2) смог полезно управлять целевой программой. Новый вызов ptrace для получения списка присоединённых процессов PT_GET_CHILDREN позволил pdptrace(2) получать дескрипторы потомков, созданных через fork.

Со всеми реализованными функциями стало возможным преобразовать truss(1) так, чтобы он использовал только дескрипторы процессов для управления трассируемыми процессами. Существующий режим использования pid был сохранён и может быть выбран опцией '-y' как аварийный переключатель, а также для удобного сравнения и отладки нового режима.

Спонсор: Фонд FreeBSD

Ссылки:
Вики-страница DevSummit EuroBSDCon 2026 URL: https://wiki.freebsd.org/DevSummit/202609
Слайды URL: https://wiki.freebsd.org/DevSummit/202609?action=AttachFile&do=view&target=EuroBSDCon2026-Scheduler.pdf

Контакт: Olivier Certner <olce@FreeBSD.org>
Контакт: Minsoo Choo <mchoo@FreeBSD.org>

В этом квартале в ULE и 4BSD был влит ряд исправлений и чисток:

Работа продолжается и близится к завершению по очистке механизма, позволяющего нескольким реализациям планировщика (так называемым «экземплярам») сосуществовать в одном ядре. Из единого списка дескрипторов функций он теперь автоматически порождает объявление функций в интерфейсе планировщика и в экземплярах планировщика, поля структуры дескриптора экземпляра планировщика и функции диспетчеризации. Готовится второй раунд изменений с целью потенциально удалить пространства имён функций реализации (например, наличие ule или 4bsd в их именах) в исходном коде, фактически переименовав их обратно в их старые имена, которые являются именами интерфейсных функций, сохраняя при этом пространства имён для символов C, что требуется для отладки и в целом для манипуляций различными инструментами ELF.

В фоновом режиме продолжается работа над решениями давних недостатков планировщика ULE, таких как несправедливость для неинтерактивных потоков в некоторых особых обстоятельствах и очень слабый эффект значений nice. Для получения дополнительной информации обратитесь к предыдущему отчёту и слайдам последней презентации на DevSummit EuroBSDCon 2026.

Спонсор: Фонд FreeBSD

Ссылки:
D59275 URL: https://reviews.freebsd.org/D59275
rGaf25f2476230 URL: https://cgit.freebsd.org/src/commit/?id=af25f24762307bf606690c0aca6a3205a0515914

Контакт: Devin Teske <dteske@FreeBSD.org>

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

HEAD теперь принимает -t с выражением через запятую, называющим системные вызовы для отчёта. Буква опции — та же, которую используют System V Release 4 и SunOS truss. Терм может быть именем системного вызова, glob-шаблоном fnmatch(3) (readlink*), номером системного вызова в ABI трассируемого процесса или @group для семейства связанных вызовов. Ведущий ! исключает то, что соответствует этому одному терму, и не применяется к другим термам — в отличие от SVR4 truss и Linux strace, где ! действует на весь остаток списка. Термы применяются по порядку; побеждает последнее совпадение. truss -t без выражения перечисляет группы и завершается.

Группы сами являются -t-выражениями, поэтому они компонуются без второго языка. @desc строится из @read и @write, а не повторяет их элементы. Списки элементов — это шаблоны (extattr_*file, sctp*), а не замороженные списки имён, поэтому более поздний системный вызов, следующий той же конвенции именования, присоединяется к нужной группе без изменения исходников здесь.

Поставляются тринадцать групп для начала: @all, @creds, @desc, @file, @ipc, @memory, @net, @none, @proc, @read, @signal, @time и @write. Они не являются клоном классов % Linux strace: @read и @write разделяют ввод данных дескриптора и вывод данных, а @time охватывает часы, таймеры и сон, а не только часы.

Показать только файловую и сетевую активность команды:

Показать всё, что делает команда, кроме управления памятью:

Показать активность дескрипторов работающего процесса отдельно от самих передач данных:

Подсчитать вызовы readlink(2) и readlinkat(2), сделанные при запуске программы:

Системный вызов, исключённый -t, не декодируется, поэтому фильтр также пропускает стоимость форматирования аргументов, которые никогда не были бы напечатаны, и он исключается из сводки -c. Без -t поведение не меняется.

Работа находится в HEAD начиная с af25f2476230, с планируемым MFC через две недели. Спасибо Robert Clausecker за рецензирование, а Alexander Ziaee — за вычитку страницы руководства.

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

Ссылки:
D58066 URL: https://reviews.freebsd.org/D58066
rG3fe5961a0b70 URL: https://cgit.freebsd.org/src/commit/?id=3fe5961a0b708da599d42cbb6b5e4f030c28ea45

Контакт: Devin Teske <dteske@FreeBSD.org> Контакт: Faraz Vahedi <kfv@FreeBSD.org>

sysctl(8) обращается к работающему ядру. sysrc(8) обращается к rc.conf(5). В этом квартале набор стал троицей, и новый инструмент приятен в использовании. sysconf(8) читает и записывает остальную часть базовой конфигурации: loader.conf(5), sysctl.conf(5) и семейство make.conf(5) (make.conf, src.conf и src-env.conf). Синтаксис — тот, который ваши пальцы уже знают. Если просто указать имя, возвращается значение указанного имени. name=value записывает, а ответ возвращается в привычной строке: name: old → new.

Настройка следующей загрузки умещается в одной строке:

rc.conf(5) сохраняет инструмент, который уже делает это лучше всего. sysconf rc sshd_enable=YES передаёт каждый аргумент после rc напрямую в sysrc(8). Одна входная дверь, и за ней нужный специалист.

В основе утилиты лежит bsdconf(3) — движок figpar, представленный как один читатель и один писатель, в соавторстве с Faraz Vahedi. Каждое семейство файлов — это небольшой дескриптор: ключевое слово, файлы и правила кавычек программы, которая фактически будет их читать. Значения loader записываются в кавычках, потому что именно это принимает загрузчик. Значения sysctl заключаются в кавычки только тогда, когда это необходимо для корректного обратного преобразования. Семейство make сохраняет свои настоящие операторы (+=, ?=, :=, !=) и пустое присваивание WITH_ / WITHOUT_, потому что для этих переключателей наличие и есть настройка. Вы задаёте формат с помощью цели. -f задаёт путь, поэтому файл в формате loader, размещённый где угодно, всё равно остаётся файлом loader, а цель generic охватывает файл, не соответствующий ни одному встроенному. Там, где загрузчик читает несколько файлов, sysconf читает те же самые файлы в том же самом порядке. Цель loader начинает там, где начинает загрузчик, — с /boot/defaults/loader.conf, — и следует за loader_conf_files, loader_conf_dirs и local_loader_conf_files, включая раскладку, которая указывает эти списки в другое место. Значение, которое вы читаете, — это значение, которое вступает в силу. Значение, которое вы записываете, сохраняется там, где оно всё ещё будет действовать при следующей загрузке. Удаление очищает каждый файл, в котором указана директива, чтобы более ранняя настройка просто не оказалась снова незамаскированной. Та же команда перечисляет файлы и выводит действующий набор:

-d сообщает описания, содержащиеся в файле значений по умолчанию. -A расширяет дамп так, чтобы директивы, всё ещё находящиеся на значении по умолчанию, были частью картины.

Запись заменяет файл целиком. Новый текст записывается во временный файл в том же каталоге, синхронизируется на диск (fsync) и переименовывается поверх оригинала с сохранением режима и владельца. Если машина остановится на полпути, на диске останется предыдущий файл. Использование только для чтения, включая проверку -c, выполняется внутри песочницы capsicum(4): файлы открываются, все остальные возможности отбрасываются, и только затем разбирается строка.

Цель sysctl спрашивает работающее ядро, прежде чем что-либо сохранить. Неизвестный OID, OID только для чтения, тюнинг только для загрузчика или значение вне диапазона типа сообщается и пропускается, а тюнинг только для загрузчика направляется к цели loader, где и должно находиться параметр загрузки. Каждое другое присваивание в той же команде всё равно применяется. Для make и src записывается WITH_foo=no, и вам сразу сообщают использовать вместо этого WITHOUT_foo=1. Это совет из share/mk/bsd.mkopt.mk, доставленный прямо на клавиатуру и повторяемый при последующем чтении с указанием файла и строки, чтобы старый WITH_*=no оставался на виду.

-j и -R направляют те же самые предложения в jail или другой корень.

Введение находится в HEAD начиная с 3fe5961a0b70 (D58066), и sysconf(8) впервые выходит в релиз во FreeBSD 16.0. Он уже вырос с того коммита. Достаточно уникального префикса цели (lo — это loader, sy — sysctl, sr — src), а цель poudriere несёт те же глаголы в poudriere.conf и в overlays make в poudriere.d.

Спасибо Robert Clausecker и Faraz Vahedi за рецензирование, а Alexander Ziaee — за примечания к выпуску.

Попробуйте его в HEAD на файле, который вы обычно открываете вручную. Если формат, в котором вы живёте, отсутствует, пожалуйста, напишите. Слой дескрипторов — это то, как присоединится следующий, и было бы хорошо услышать, какой файл вы хотите следующим.

Контакт: Christos Margiolis <christos@FreeBSD.org>

В конце этого квартала я начал работу над улучшением cuse(3). Помимо мелких исправлений и рефакторинга, я исправил известные зависания в модуле ядра во время ввода-вывода (872c36cb6f2d) и горячей выгрузки модуля (d38ef1aca969).

Вы также можете следить за процессом разработки в репозитории status-updates Фонда FreeBSD, где я публикую еженедельные отчёты.

Спонсор: Фонд FreeBSD

Ссылки:
Рабочая ветка URL: https://github.com/realchonk/freebsd-src/tree/ext2fs-user-tools

Контакт: Benjamin Stürz <benni@FreeBSD.org>

Цель этого проекта — реализовать утилиты для управления файловыми системами ext2fs в базовой системе FreeBSD.

Проект включает следующее: - dumpfs_ext2fs(8) - newfs_ext2fs(8) - fsck_ext2fs(8) - tunefs_ext2fs(8) - libext2fs (та же идея, что и libufs) - интеграция в makefs - тесты для упомянутых компонентов

Спонсор: Фонд FreeBSD

Ссылки:
Тестовый фреймворк загрузчика URL: https://reviews.freebsd.org/D58008
Распаковка XZ для EFI-дисков памяти URL: https://reviews.freebsd.org/D58073
Диски памяти динамического загрузчика URL: https://reviews.freebsd.org/D59418
Независимые EFI HTTP-устройства URL: https://reviews.freebsd.org/D59423
Опция начального диска памяти по DHCP URL: https://reviews.freebsd.org/D59428
Исправление раздела цепной загрузки EFI URL: https://cgit.freebsd.org/src/commit/?id=9ecc2493ca5fbba852e175674b5cb8975b99af84

Контакт: Warner Losh <imp@FreeBSD.org>

Работа в этом квартале расширила поддержку загрузчиком сжатых образов, дисков памяти и сетевой загрузки по HTTP, с вниманием как к интеграции с iPXE, так и к полноте loader.efi(8). Она также представила тестовый фреймворк на основе QEMU, охватывающий многие варианты загрузки FreeBSD.

Загрузчик теперь может читать файлы, сжатые с помощью XZ или Zstandard, так же, как он уже обрабатывал файлы gzip и bzip2. Поддержка XZ включена по умолчанию в загрузчиках BIOS и EFI, включая поддержку сжатых образов дисков памяти, таких как установочные образы FreeBSD. Поддержка Zstandard доступна как опция сборки.

Обработка дисков памяти была обобщена, чтобы загрузчик мог динамически создавать устройство md. Это обеспечивает запасной вариант на системах, чья прошивка UEFI не реализует протокол RamDisk, — ситуация, встречающаяся на некоторых малых и встраиваемых системах. Полученный диск памяти экспортируется в ядро и может содержать как ядро, так и корневую файловую систему. Загруженные образы дисков памяти теперь используют правильный тип памяти UEFI, а загрузку можно прервать клавишей Escape. Это заменяет необходимость использования сторонней надстройки memdisk_uefi.efi, которая требовалась людям ранее для интеграции с iPXE. Теперь loader.efi также может загружать образы через службы загрузки iPXE, требуя только базовые сетевые модули DXE в образе прошивки UEFI.

Поддержка EFI HTTP ранее зависела от того, что прошивка загрузила loader.efi через UEFI HTTP Boot, и была ограничена сервером, выбранным прошивкой. Теперь загрузчик принимает произвольные спецификации устройств http[N]://host[:port]/path. Их можно использовать как rootdev, в loader.conf или интерактивно, независимо от того, как был запущен сам загрузчик. Реализация может либо повторно использовать существующую сетевую конфигурацию загрузчика, либо попросить сетевой стек прошивки выполнить DHCP.

Клиент DHCP теперь запрашивает опцию производителя FreeBSD, содержащую URL начального образа диска памяти. С этой опцией машина может запустить loader.efi напрямую по сети, обнаружить отсоединённый корневой образ через DHCP, получить этот образ по HTTP и загрузиться с него. Была проявлена осторожность при передаче владения сетевым интерфейсом между собственным сетевым стеком загрузчика и стеком UEFI HTTP. Это необходимо, поскольку каждому стеку требуется различный доступ к сетевым протоколам прошивки.

Новый фреймворк tools/boot/boot-test.sh использует QEMU для тестирования загрузки на aarch64, amd64, armv7, powerpc64, powerpc64le и riscv64. Он задействует применимые окружения BIOS, UEFI, OpenFirmware и PReP с конфигурациями CD, MBR, GPT, сети и дисков памяти, а также загрузчики Lua, Forth и simple. Тесты сетевой загрузки по HTTP и цепной загрузки gptboot.efi были добавлены позже в квартале. Фреймворк пока не является установленным тестом, поскольку он собирает и тестирует несколько целевых архитектур с одного хоста.

Тесты цепной загрузки сопровождали исправление для систем, использующих gptboot.efi для выбора между системными разделами A/B. После цепной загрузки loader.efi мог пропустить выбранный раздел и вместо этого загрузить другой системный раздел. Теперь выбранный раздел пробуется первым, а обычный поиск родственных разделов остаётся как запасной вариант. Отдельное изменение загрузчика, которое мешало некоторым конфигурациям цепной загрузки ZFS, было отменено.

Другая работа добавила страницу руководства loader.kboot(8), параметры сборки для исключения загрузчиков x86 BIOS и userboot из систем только с UEFI, а также защитные проверки для прошивок, которые объявляют непригодные протоколы графического вывода.

Спонсор: Netflix

Ссылки:
Блог URL: https://obiw.ac/s0ix/
Доклад на BSDCan о s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Рабочая ветка URL: https://github.com/obiwac/freebsd-s0ix/pull/15

Контакт: Aymeric Wibo <obiwac@FreeBSD.org>
Контакт: Olivier Certner <olce@FreeBSD.org>

В FreeBSD в настоящее время добавляется приостановка в простой (suspend-to-idle) и поддержка сна S0ix.

Это позволит современным ноутбукам на Intel и AMD, некоторые из которых не поддерживают сон ACPI S3, переходить в состояния низкого энергопотребления для увеличения времени автономной работы.

amdsmu(4) теперь проактивно диагностирует вход в S0i3 после возобновления из приостановки в простой с помощью нового обработчика событий. Если вход в S0i3 не произошёл, он выведет в dmesg IP-блоки, которые блокировали вход, вместе с подсказками о том, как их устранить.

Драйвер acpi_spmc(4) теперь проверяет пакеты ограничений Intel и AMD. Некорректные ограничения пропускаются вместо аварийного завершения.

В драйвер thunderbolt(4) был внесён ряд улучшений: поддержка записи в конфигурационное пространство маршрутизатора, сбросы контроллера и исправление учёта CRC для сообщений записи конфигурации. Контроллеры Thunderbolt теперь можно возобновлять (на рецензировании), что позволяет выполнять несколько циклов приостановки-возобновления без необходимости перезагружать модуль ядра.

На данный момент современный ждущий режим (modern standby) надёжно работает на целевых ноутбуках, и большинство паник устранено. Основная проблема, над которой ведётся работа, — события GPE, генерируемые, пока машина находится в приостановленном состоянии, например, подключение или отключение питания от сети, вызывающие паники.

Спонсор: Фонд FreeBSD

Контакт: Christos Margiolis <christos@FreeBSD.org>

Я работаю над звуковой подсистемой с 2024Q1. Ниже приведён список предыдущих отчётов о состоянии работ:

2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL: https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL: https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements
2026Q1 URL: https://www.freebsd.org/status/report-2026-01-2026-03/#_audio_stack_improvements
2026Q2 URL: https://www.freebsd.org/status/report-2026-04-2026-06/#_audio_stack_improvements

Важная работа с момента последнего отчёта:

Вы также можете следить за процессом разработки в репозитории status-updates Фонда FreeBSD, где я публикую еженедельные отчёты.

Спонсор: Фонд FreeBSD

Ссылки:
Страница вики URL: https://wiki.freebsd.org/BoundsSafety
Страница проекта URL: https://freebsdfoundation.org/project/adopt-fbounds-safety-in-the-freebsd-kernel-tcp-ip-stack/

Контакт: Abhijeet Sharma <abhijeetsharma2002@gmail.com>

Флаг -fbounds-safety в Clang позволяет коду на C указывать длину буфера, как в __counted_by(len). Затем компилятор проверяет обращения через этот указатель. Обращение за границы диапазона вызывает срабатывание вместо повреждения памяти. Стек TCP/IP разбирает недоверенный сетевой ввод, поэтому это хорошее место для начала. Этот проект добавляет макросы и поддержку сборки, затем преобразует файлы TCP по одному. Без этого флага аннотации разворачиваются в пустоту. Дерево по-прежнему собирается с компилятором базовой системы и с GCC.

Контакт: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Вслед за работой над geneve(4) я занимался переносом наших других туннельных драйверов на новый KPI if_clone и добавлением для них поддержки netlink как в ядре, так и в ifconfig(8). Теперь они доступны в CURRENT.

На данный момент я добавил поддержку:

Попутно я исправил следующие ошибки:

Ведущаяся работа:

Ссылки:
Страница проекта

Контакт: Ishan Agrawal <ishan@freebsd.org>

Наставник: Kristof Provost <kp@freebsd.org>

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

Этот проект добавляет многоразовую инфраструктуру декодирования полезной нагрузки Netlink в libsysdecode и интегрирует её с truss(1), позволяя структурированно декодировать сообщения Netlink, а не раскрывать только их необработанное содержимое.

Ядром инфраструктуры является универсальный декодер атрибутов на основе таблиц декодеров. Инфраструктура поддерживает декодирование различных типов атрибутов, включая целочисленные значения, строки, логические значения и вложенные атрибуты. Затем команды Netlink могут предоставлять собственные таблицы декодеров, описывающие содержащиеся в них атрибуты, без необходимости отдельного механизма декодирования для каждой команды.

Инфраструктура была использована для добавления декодирования нескольких команд PF Netlink, включая PFNL_CMD_KILLSTATES, PFNL_CMD_GETRULES и PFNL_CMD_GET_LIMIT.

Например, сообщение PF Netlink, которое ранее отображалось в основном как непрозрачный буфер:

С новой инфраструктурой декодирования truss(1) может декодировать сообщение Netlink и полезную нагрузку PF в осмысленные поля, например:

truss(1) также был расширен для отслеживания протокола, связанного с сокетами AF_NETLINK, чтобы сообщения можно было передавать соответствующему декодеру. Флаги сообщений Netlink декодируются как комбинации флагов NLM_F_*, при этом неизвестные биты сохраняются.

Работа в этом квартале заложила инфраструктуру, необходимую для продолжения добавления декодеров полезной нагрузки PF Netlink без дублирования логики разбора для каждой команды.

Спонсор: Google LLC (GSoC 2026)

Ссылки:
Поддержка беспроводных карт MediaTek URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Страница MediaTek mt76 в Wiki URL: https://wiki.freebsd.org/WiFi/Mt76
Отчёты о проблемах с беспроводными сетями URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1
Espressif Systems ESP32-E22 URL: https://www.espressif.com/en/products/socs/esp32-e22
Драйвер WiFi Espressif на github URL: https://github.com/espressif/esp32e22-linux-driver

Контакт: Bjoern A. Zeeb <bz@FreeBSD.org>
Контакт: Рассылка FreeBSD по беспроводным сетям <wireless@FreeBSD.org>

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

Контакт: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

С момента последнего отчёта я продолжал обновлять наш стек IPv6 и реализовывать ожидающие RFC, и результаты теперь доступны в CURRENT.

На данный момент я добавил поддержку:

Я также исправил несколько ошибок в стеке:

Ведущаяся работа:

Я хочу особенно поблагодарить Marek Zarychta за его тесты и рецензии.

Контакт: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Последние 3 месяца я работал над повышением устойчивости нашего стека маршрутизации, и результаты теперь доступны в CURRENT.

Ранее доступность каждого nexthop проверялась по статусу канала интерфейса для каждого пакета. Теперь nexthop подписываются на события канала интерфейса, и в пути пересылки проверяется только флаг доступности конечного nexthop. Когда nexthop становится недоступным, группы nexthop, содержащие его, немедленно перекомпилируются путём замены недоступных nexthop на доступные. Как только канал возвращается, nexthop возвращаются в свои обычные слоты в группе nexthop. Это означает, что многопутевой маршрут продолжает пересылать трафик, когда один из его каналов выходит из строя, без удаления маршрута. Я действительно горжусь этим.

На данный момент я добавил поддержку:

Я также исправил пару ошибок в fib_algo:

Я хочу особенно поблагодарить Gleb Smirnoff, Alexander Chernikov и Mark Johnston за их рецензии и руководство по этим работам.

Ссылки:
Ревизия в Phabricator URL: https://reviews.freebsd.org/D59140
Репродьюсер и эпистемическая запись URL: Репродьюсер и эпистемическая запись

Контакт: Luis Castellanos <ing.castellanosdz@gmail.com>

Ссылки:
DTrace-пробы жизненного цикла CAM URL: https://reviews.freebsd.org/D58523
События аннулирования периферийных устройств CAM URL: https://reviews.freebsd.org/D58527
Информация об обнаружении mpsutil URL: https://reviews.freebsd.org/D58528

Контакт: Warner Losh <imp@FreeBSD.org>

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

Провайдер DTrace CAM получил пробы для ошибок ввода-вывода периферийных устройств, восстановления после ошибок и аннулирования периферийных устройств. Дополнительные пробы сообщают, когда CAM удерживает или освобождает процесс загрузки и когда регистрируется новая шина. Вместе эти пробы охватывают гораздо большую часть пути от начального обнаружения шины до создания дисковых периферийных устройств. Их также можно использовать с анонимной трассировкой DTrace для исследования проблем, возникающих до того, как система достигнет многопользовательского режима. Новые пробы документированы в dtrace_cam(4).

CAM теперь отправляет уведомление devctl(4), когда периферийное устройство аннулируется. Уведомление включает серийный номер устройства, когда он доступен, или в противном случае его путь CAM, чтобы программное обеспечение управления системой могло идентифицировать исчезнувшее устройство. Общий код, используемый для построения уведомлений CAM, был выделен для поддержки этого и будущих типов событий.

Два исправления улучшили обработку дисков, которые отказывают во время проверки. CAM теперь прекращает проверку после аннулирования периферийного устройства вместо отправки дополнительных команд заброшенному устройству, где они могли вызвать длительные тайм-ауты и запутанные ошибки. Было исправлено связанное условие для определения того, когда аннулировать диск. Ошибки, сообщаемые для дисков NVMe через периферийное устройство CAM nda, теперь идентифицируют набор команд, что упрощает интерпретацию кодов операций команд.

mpsutil(8) получил команду show discovery, которая выводит таблицы обнаружения контроллера. Это раскрывает представление контроллера о подключённых устройствах SAS и экспандерах и полезно при диагностике устройств, которые отсутствуют или подключены через неожиданный путь.

Наконец, nvmecontrol(8) получил исправления корректности для данных Autonomous Power State Transition. Значения переходов теперь кодируются без промежуточного целочисленного переполнения, а данные идентификации, сообщающие чрезмерное число состояний питания, обрабатываются с помощью проверки границ вместо утверждения.

Спонсор: Netflix

Контакт: Konstantin Belousov <kib@FreeBSD.org>

Большинство не-x86 платформ относительно строги в отношении правильного выравнивания типов данных. С другой стороны, ISA x86 допускает любое выравнивание для операндов целочисленных скалярных операций.

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

Особенно интересный случай невыровненного доступа — когда расположение операнда приводит к тому, что он охватывает две строки кэша (что невозможно для естественно выровненных данных). Обычные (незаблокированные) операции вызывают так называемые torn reads и writes (рваные чтения и записи). Этот эффект становится наблюдаемым начиная с микроархитектуры Intel Core2.

Ещё более интересный случай предоставляют заблокированные операции с использованием префикса LOCK в инструкции read-modify-write с невыровненными данными. Чтобы удовлетворить гарантии ISA в этом случае, CPU должен либо захватить более одной строки кэша для эксклюзивного владения в протоколе когерентности кэша, подобном MESI, либо задействовать так называемую блокировку шины (bus lock), обеспечивающую глобальное владение кэшем. Любой из вариантов имеет очень высокую стоимость и вызывает наблюдаемые вредные эффекты для других процессов и виртуальных машин, выполняющихся на том же физическом хосте.

Некоторое время назад Intel предоставил управление для операций блокировки, которым требуется охватывать более одной строки кэша (split locks). Включение этого управления приводит к тому, что split locks генерируют то же исключение #AC, что и флаг AC, но только для split locks, а не для всех невыровненных доступов.

Эта функция управляется MSR платформы и является глобальной для каждого CPU, что исключает возможность сделать MSR напрямую доступным для пользовательского пространства. Была разработана новая операция sysarch(2) I386_SET_SPLITLOCK, которая включает это управление для вызывающего потока. Управление является частью машинного состояния, поддерживаемого при переключении контекста.

Цель — в основном помочь в отлове ошибок, когда создаются неправильно выровненные структуры блокировки, в отличие от Linux, который использует эту функцию для искусственного наказания таких процессов путём их замедления. Если модификация кода программы невозможна, пользователи и администраторы могут через LD_PRELOAD загрузить тривиальный разделяемый объект, который включает это управление.

Спонсор: Фонд FreeBSD

Ссылки:
Коммит, добавляющий снимок драйвера aq(4) URL: https://cgit.freebsd.org/src/commit/?id=493d26c58e732dcfcdd87993ef71880adfe9d0cb
Коммит, добавляющий инфраструктуру сборки aq(4) URL: https://cgit.freebsd.org/src/commit/?id=75177aebf0397af36b1f28f6b6e64207ec3d8188
Коммит, добавляющий поддержку Atlantic 2 (AQC113) URL: https://cgit.freebsd.org/src/commit/?id=dc5c0fc51cf47d6dfc737343e06805db294258e9

Контакт: Ed Maste <emaste@freebsd.org>
Контакт: Nick Price <nprice@freebsd.org>

Устройства Aquantia (ныне Marvell) AQtion — это мультигигабитные Ethernet-контроллеры PCIe, поддерживающие скорости до 10 Гбит/с. Они встречаются на материнских платах рабочих станций и настольных компьютеров, а также на дополнительных сетевых картах.

Aquantia опубликовала драйвер FreeBSD для своих контроллеров первого поколения "Atlantic", но он некоторое время не поддерживался. Разработчики FreeBSD внесли некоторые исправления в репозиторий производителя, но несколько pull-запросов так и остались без ответа. Драйвер был доступен в коллекции портов как пакет net/aquantia-atlantic-kmod с некоторыми дополнительными патчами, но он не входил в базовую систему и не поддерживал новые устройства.

Ed Maste импортировал снимок драйвера производителя, применил патчи из неслитых pull-запросов и порта, написал страницу руководства aq(4) и подключил драйвер к сборке.

С тех пор Nick Price добавил поддержку контроллеров второго поколения Atlantic 2 (AQC113) и внёс обширные исправления и улучшения по всему драйверу. Среди них — включение jumbo-фреймов, программного LRO и приостановки/возобновления; исправление распределения очередей RSS и соблюдение политики RSS ядра; расширение и исправление разгрузки контрольных сумм и VLAN, а также фильтрации VLAN/многоадресных рассылок; повышение надёжности путей attach, detach, reset, interrupt и RX/TX; обработка теплового отключения PHY; улучшение диагностики и отчётности о состоянии канала.

Драйвер доступен в снимках -CURRENT и был перенесён (MFC) в stable/15 для включения в FreeBSD 15.2.

Спонсор: The FreeBSD Foundation (работа Ed)

Ссылки:
Banana Pi на вики FreeBSD URL: https://wiki.freebsd.org/arm/Bananapi

Контакт: Martin Filla <freebsd@sysctl.cz>

Этот проект добавляет поддержку FreeBSD для трёх роутерных плат Banana Pi: BPI-R2 (MediaTek MT7623, armv7), BPI-R64 (MediaTek MT7622, arm64) и BPI-R2 Pro (Rockchip RK3568, arm64).

Ссылки:
Форк rocm-systems с поддержкой FreeBSD URL: https://github.com/Yohello1/rocm-systems/tree/rebase-systems
Форк drm-kmod с частичной поддержкой amdkfd URL: https://github.com/Yohello1/drm-kmod-rocm/tree/super-special

Контакт: Sourojeet Adhikari <siri@racha.ca>

ROCm — это вычислительная платформа AMD, представляющая собой набор библиотек, драйверов и инструментов, используемых для программирования их ИИ-ускорителей и/или графических процессоров. Во FreeBSD есть лишь несколько способов выполнять вычислительные задачи (ИИ/машинное обучение, графика и т. д.) на GPU, и, насколько мне известно, это Vulkan и OpenGL. Оба хороши для графики, а иногда и для машинного обучения, но многие задачи просто плохо подходят для них и в итоге выполняются в ROCm или CUDA, поскольку те дают разработчику гораздо больше контроля над тем, как фактически выполняется задача.

Поэтому я постепенно переношу инструментарий ROCm во FreeBSD, что позволило бы экосистеме ИИ-ускорителей работать здесь нативно.

Большая часть моего времени в последнее время ушла на то, чтобы заставить rocr-runtime работать из моего форка rocm-systems, при этом передавая в вышестоящий проект необходимые изменения в ядре FreeBSD. Как только работа над ядром будет завершена, я смогу влить код amdkfd в drm-kmod (после большой чистки), и оттуда это в основном вопрос времени — запустить оставшиеся части rocr-runtime.

Ссылки:
Запуск настольных AMI FreeBSD/EC2 URL: https://www.daemonology.net/blog/2026-09-24-Launching-FreeBSD-EC2-desktop-AMIs.html

Контакт: Colin Percival <cperciva@FreeBSD.org>

FreeBSD доступен на экземплярах EC2 как amd64 (Intel и AMD), так и arm64 (Graviton).

Применено исправление привязки taskqueue к NUMA в ena(4), что начиная с 14.5-RELEASE дало значительное улучшение пропускной способности сети на системах c8gn.48xlarge.

EC2 теперь поддерживает автоматическое увеличение файловых систем при расширении томов EBS; это включено по умолчанию в 16.0-CURRENT и будет доступно как необязательная опция в 15.2-RELEASE.

Инструмент ebsnvme, поставляемый в образах EC2, теперь поддерживает команду "ebsnvme stats", совместимую с Amazon Linux.

Теперь для FreeBSD 15 доступен новый «настольный» вариант AMI, который использует xrdp для предоставления среды KDE.

Спонсор: Amazon
Спонсор: https://www.patreon.com/cperciva

Ссылки:
Портал проекта документации URL: https://docs.freebsd.org/
Руководство по проекту документации для новых участников URL: https://docs.freebsd.org/en/books/fdp-primer/
Команда документационной инженерии URL: https://www.freebsd.org/administration/#t-doceng

Контакт: Documentation Engineering Team <doceng@FreeBSD.org>

Команда документационной инженерии отвечает за определение целей документации для коммиттеров проекта документации и контроль за их выполнением. Устав команды doceng подробно описывает обязанности и сферу ответственности команды документационной инженерии.

В этом квартале в проекте документации, помимо текущего сопровождения, несколько проектов были завершены или находились в работе:

В этом квартале Vladlen Popolitov <vladlen@FreeBSD.org> был повышен до doc commit bit. Другие commit bit в этом квартале не выдавались и не изымались на хранение.

Ссылки:
Официальный веб-сайт FreeBSD на русском языке URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
Сайт проекта русской документации FreeBSD URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Контакт: Андрей Захватов (Andrey Zakhvatov) <andy@FreeBSD.org>
Контакт: Владлен Пополитов (Vladlen Popolitov) <vladlen@FreeBSD.org>

Текущая цель Проекта русскоязычной документации FreeBSD — предоставлять актуальные русские переводы наиболее важных частей документации FreeBSD (FAQ, Руководство, содержимое веб-сайта). Это необходимо для поддержки русскоязычных пользователей качественными официальными техническими материалами и для расширения распространённости операционной системы по всему миру. Мы надеемся, что эта инициатива получит поддержку в русскоязычном сообществе FreeBSD и приведёт к увеличению объёма переведённых материалов.

В течение последнего квартала:

План на следующий квартал:

Ознакомьтесь с официальным руководством по переводу, если вы хотите помочь.

Мы будем признательны за вашу помощь:

Ссылки:
FreshPorts URL: https://www.freshports.org/
Тестовый сайт FreshPorts с переводами URL: https://test.freshports.org/
Как переводить FreshPorts URL: https://github.com/FreshPorts/freshports/tree/main/locale
Задача поддержки переводов URL: https://github.com/FreshPorts/freshports/issues/678

Контакт: Dan Langille <dvl@FreeBSD.org>

FreshPorts и его родственный сайт FreshSource сообщают о коммитах FreeBSD уже более 25 лет. Они охватывают все коммиты, но их основное внимание уделяется портам.

FreshPorts отслеживает коммиты и извлекает данные из Makefile портов, чтобы создать базу данных информации, полезной как разработчикам портов, так и пользователям портов. Например, https://www.freshports.org/security/acme.sh/ показывает историю этого порта, вплоть до его создания в мае 2017 года.

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

Ссылки:
https://github.com/Martinfx/FreeBSD-Ports/tree/master/brave

Контакт: Martin Filla <freebsd@sysctl.cz>

Ссылки:
freebsd-dockerbox Github URL: https://github.com/leafoliage/freebsd-dockerbox
dockerbox-broker Github URL: https://github.com/leafoliage/dockerbox-broker
freebsd-dockerbox-debian Github URL: https://github.com/leafoliage/freebsd-dockerbox-debian

Контакт: Chun-Cheng Yeh <leafoliage@FreeBSD.org>

Dockerbox — это виртуализированный демон Docker. Хотя демон Docker изначально недоступен во FreeBSD, Dockerbox запускает его внутри виртуальной машины Debian Bhyve, чтобы обеспечить к нему доступ.

Ссылки:
Инициатива KDE/FreeBSD URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Контакт: KDE on FreeBSD Mailing List <kde@FreeBSD.org>

Проект KDE во FreeBSD делает порты CMake, Qt и программного обеспечения сообщества KDE для дерева портов FreeBSD. Программное обеспечение включает полноценную среду рабочего стола KDE Plasma (как для X11, так и для Wayland) и сотни приложений, которые можно использовать на любой машине FreeBSD. Команда KDE входит в desktop@ и создаёт программный стек, чтобы сделать FreeBSD красивой и пригодной для повседневного использования в качестве графической рабочей станции.

Ссылки:
Описание проекта URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Репозиторий проекта URL: https://github.com/freebsd/openjdk
Вышестоящий репозиторий BSD-порта URL: https://github.com/openjdk/bsd-port

Контакт:
Harald Eilertsen <haraldei@FreeBSD.org>
Список рассылки FreeBSD Java <freebsd-java@lists.freebsd.org>

Цель этого проекта — улучшить поддержку OpenJDK для FreeBSD/amd64 и FreeBSD/arm64.

Java — важная среда выполнения для многих высокопроизводительных, критически важных корпоративных систем. Обеспечение корректной и эффективной работы приложений на основе Java во FreeBSD важно для того, чтобы FreeBSD продолжала оставаться жизнеспособной и привлекательной платформой для предприятий, а также компаний и организаций любого размера.

В этом квартале в вышестоящий проект были влиты несколько довольно крупных, инвазивных функций (JEP 401: Value Objects и JEP 539: Strict Field Initialization), из-за чего в этот период было трудно получать рецензии и принятие наших изменений. Мы потратили время на исправление проблем с BSD-портом, а также на поддержание его в актуальном состоянии по мере появления вышестоящих изменений.

В этом квартале были выполнены следующие исправления/улучшения:

Спонсор: Фонд FreeBSD

Ссылки:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
net/openmpi URL: https://cgit.freebsd.org/ports/tree/net/openmpi/
benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
sysutils/py-clustershell URL: https://cgit.freebsd.org/ports/tree/sysutils/py-clustershell/
SchedMD bug 25911: proctrack/freebsd-reaper URL: https://bugs.schedmd.com/show_bug.cgi?id=25911
SchedMD bug 25912: configless OS-specific Include files URL: https://bugs.schedmd.com/show_bug.cgi?id=25912
openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms URL: https://github.com/openucx/ucx/pull/11549
hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds URL: https://github.com/hpc/mpifileutils/pull/664

Контакт: Generic Rikka <rikka.goering@outlook.de>

Этот отчёт продолжает инициативу по модернизации HPC-портов FreeBSD, цель которой — сделать FreeBSD практичной и поддерживаемой платформой для современных стеков программного обеспечения высокопроизводительных вычислений (HPC). В предыдущих кварталах основное внимание уделялось приведению стека Slurm, PMIx, PRRTE и UCX в актуальное состояние и заполнению пробелов в окружающей экосистеме. Работа этого квартала была сосредоточена на трёх вещах: поддержании актуальности планировщика и библиотек связи (включая исправления безопасности), углублении специфичной для FreeBSD поддержки среды выполнения в UCX и обеспечении комбинации Open MPI/UCX, а также передаче первых нативных для FreeBSD функций Slurm в вышестоящий проект SchedMD.

Ссылки:
libvirt: драйвер Bhyve URL: https://libvirt.org/drvbhyve.html

Контакт: Roman Bogorodskiy <novel@FreeBSD.org>