Каталог ядра в открытом доступе: Исправление «Каталог ядра в открытом доступе» в MODX

Решение проблемы «Каталог ядра в открытом доступе» в Modx Revolution

Всем привет. Коротенькая статья, посвященная решению проблемы «Каталог ядра в открытом доступе», которая появляется в админке Modx Revolution в версии 2.4.0. Связана эта ошибка с безопасностью, а с ней лучше не шутить. Поэтому эту проблему нужно решить.

Решение проблемы​

1. Заходим в админку Modx Revo и видим такое

2. Открываем Файл менеджер или воспользуемся диспетчером файлов самого Modx Revo

3. Идем в папку core/

5. Открываем этот файл и заменяем содержимое на

IndexIgnore */*
<Files *.*>
    Order Deny,Allow
    Deny from all
</Files>

6. Очищаем кэш и смотрим страницу приветствия в админке. Ошибки не обнаружено.

Чем грозит, если оставить без внимания эту ошибку

Насколько это опасно для безопасности я точно не знаю, но даже ради нее (безопасности) эту ошибку надо исправить, а не просто выключить виджет, который отображается ошибку «Каталог ядра в открытом доступе». Но есть еще, по крайней мере, один нюанс, ради которого нужно исправить эту ошибку. Вы не сможете поставить «Использовать дружественные URL» в разделе системных настроек «Дружественные URL».

У вас просто будет зависать админка при включении этого параметра. Так что не ленитесь и устраните проблему, тем более что это делается в несколько кликов. На этом все, если что-то не работает пишите в комментариях, попробуем разобраться вместе.

P.S. еще столкнулся с проблемой, пока писал эту статью. Если вы заметили у меня отличается по дизайну 4-ый пункт. Это не текст, а картинка. Оказывается редактор и сама админка очень чувствительны к названию файла, которые указаны в 4-ом пункте. Если в статье имеется название данного файла, то она просто не сохраняется. Минут 20 не мог понять из-за чего у меня не сохраняется статья.

Помогла статья? Угости чашечкой кофе =)

Как исправить предупреждение Modx — каталог ядра в открытом доступе

Часто в панели администрирования MODX можно увидеть предупреждение с заголовком «Каталог ядра в открытом доступе». Согласно нему следует, что содержимое каталога «core» доступно для чтения. Это является уязвимостью, поэтому следует прислушаться к рекомендациям движка.

А движок рекомендует следующее. В корне «core» каталога лежит конфигурационный файл Apache — ht.access. Внутри него прописаны правила, которые запрещают просмотр содержимого каталога и удалённый доступ к файлам. Чтобы активировать конфигурационный файл, следует переименовать его в .htaccess.

В большинстве случаев надпись «Каталог ядра в открытом доступе» при такой защите не пропадает. Проблема в том, что многие хостинговые площадки используют связку Apache + Nginx, где Apache отвечает за отдачу содержимого html страницы, а Nginx — статичных файлов. Modx для проверки закрытия доступа к каталогу «core» проверяет доступность файла «core/docs/changelog.txt», за отдачу которого отвечает Nginx. И так как на Nginx правила из htaccess не действуют, он благополучно отдаёт его содержимое.

То есть текстовые файлы остаются всё равно доступны, что не является критичным, а значит сообщение можно игнорировать. Либо переимновать файл «changelog.txt», тем самым обманув движок. Сообщение будет скрыто.

Andy Si

21 фев 2017 г.

2376

Безопасность MODX — основные уязвимости и защита сайта от взлома.

Автор Алексей На чтение 8 мин. Просмотров 588 Опубликовано 29.06.2020 Обновлено 30.06.2020

В прошлом уроке мы произвели расширенную установку MODX, тем самым закрыли часть уязвимостей. После входа в админку, вы наверное заметили ошибку: «Каталог ядра в открытом доступе» и жирным написано: Это не рекомендуется из соображений безопасности. А ниже ссылка на руководство по закалке на английском языке.  У меня на блоге есть подобное руководство на русском — которое относится к любым сайтам и не только.

Сегодня мы поговорим о уязвимостях MODX, как защитится от взлома и избавится от ошибки «Каталог ядра в открытом доступе«.

Критические уязвимости modx

Ноябрь 2016 — обнаружена первая критической уязвимости, она основана на SQL иньекциях. Подвержены сайты — которые используют стандартный префикс modx — я так понимаю она еще актуальна.

Июль 2018 — найдены еще две критические уязвимости безопасности. Первая позволяет злоумышленникам удалять на сайте папки и файлы, вторая — загружать на сервер вредоносный код и и выполнять его. — Профикшено в MODX 2.6.5 и выше. Похожая уязвимость так же была найдена в дополнении Gallery версии 1.7.0 и ниже — обновите до 1.7.1.

Обновление до версии 2.6.5 с исправлением уязвимостей выпустили на следующий день. Дополнение Gallery было обновлено до версии 1.7.1.

Апрель 2019 — обнаружен exploit для сайтов, в которых где осталась директория setup. Данная «дыра» позволяет получить полный доступ к сайту, а если хостиг не айс, то и к веб-серверу. — Уязвимость на данный момент не устранена, так что проверьте свой сайт на нее: введите в адресную строку браузера адрес вашего домена + /setup (как в уроке по установке) — если установщик запустится, то зайдите на хостинг и удалите папку setup.

Защита MODX — руководство по закалке

Внимание! Если у вас боевой сайт — перед началом, сделайте его полный бэкап!

Защита ядра и служебных каталогов

Защитить ядро можно несколькими способами: вынести ядро (папка Core) из публичной папки. Далеко не на всех хостингах это можно сделать, либо переименовать каталог core.

Защитить служебные каталоги (connectors и manager) можно их переименованием их.

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

И наш сайт перестал работать! Исправим это, для этого нам нужно поправить пути в файлах конфирураций:

/config.core.php, manager/config.core.php, connectors/config.core.php

В файле core/config.core.php указываем все новые пути.

После чего удаляем папку с кэшем core/cache и проверяем работоспосбность сайта. Если сайт не работает, значит где-то не поправили путь.

По поводу каталога assets, его тоже можно спрятать (выше приведенным способом). Но есть много но, и об этом будет в конце статьи!

robots.txt

Глупо переименовывать системные папки, и затем писать в robots.txt Disallow: Ejdf20jkfg20ff_conectors, но спрятать их от роботов нужно. Выход: удаляем из робота все старые директивы (которые мы переименовали) и за место них пишем 1 сторку: Disallow: Ejdf20jkfg20* (указанный вам префикс без знака _ и нескольких последних символов до него) .

Таким образом мы скрываем от робота все что находится в переименованных каталогах с префиксом Ejdf20jkfg20ff_.

Здесь можно проверить правильность своего robots.txt — https://webmaster.yandex.ru/tools/robotstxt/

Скрытие конфигурационных файлов сайта и версии php

Открываем .htaccess и добавляем в него следующие строчки.

RewriteCond %{REQUEST_URI} ^/config.core.php*
RewriteRule ^(.*)$ [R=404]
php_flag display_errors off

Защита таблиц базы данных

Если во время установки MODX, в настройках БД, вы не изменили префикс таблиц, который предлагается по умолчанию «modx_». То меняем его на сложный, для этого идем в phpMyAdmin (управление базами данных в админке хостинга):

• в левой части phpMyAdmin кликаете на название нужной базы;
• в основной области появится список всех таблиц, внизу которого надо отметить чекбокс «Отметить все»;
• справа от чекбокса комбобокс «С отмеченными:» в котором надо выбрать «Заменить префикс таблицы»;
• в новом окне указать старый префикс и новый префикс, на который надо заменить старый.

после этого идем в core/config.core.php , меняем в нем префикс и удаляем папку с кэшем.

Базовая защита от определения CMS

Для тех кто устанавливал MODX не по моему мануалу, проверьте отключение «X-Powered-By», чтобы сайт не «палился», отправляя в заголовках информацию о том, что сайт сделан на MODX.

Идем в системные настройки, в поиск по ключу вбиваем send_poweredby_header — ставим нет.

Дополнительные примочки по защите

Кроме описанных выше приёмов, можно применить еще пару небольших хитростей.

Многие «попсовые» CMS добавляют свои мета теги с указанием названия и версии CMS, например джумла:

<meta name=»generator» content=»Joomla x.x.x» />

можно смело добавить такой код, чтобы увести возможных злоумышленников по ложному следу.

В добавок к этому, можно создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.

Большинство автоопределялок будут интерпретировать наш движок как Joomla, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки к нерабочему замку.

Каталог ядра в открытом доступе — решение проблемы

Если после всего выше перечисленного у вас все еще весит в админке данное уведомление (а оно в 90% еще весит). Можно смело избавиться от данной ошибки. Для этого переименуйте файл ht.access в .htaccess, который лежит в каталоге core. После этого идем в каталог «core/docs» и удаляем из него файл «changelog.txt».

Если ошибка не ушла, очистите кэш.

Полное скрытие информации о том что сайт работает на MODX

После проделанного выше большинство сервисов автоматического определения CMS, не поймут что сайт работает на MODX, но практически любой знающий модх человек, с большой долей вероятности определит ее, по подключенным скриптами пакетов из папки assets, и как я писал выше ее тоже можно скрыть, но влечет за собой кучу проблем.

1. Если сайт боевой, то в данном каталоге скорее всего лежат все картинки, скрипты, стили — следовательно к ним изменится путь — это пародист 404 ошибки (файл не найден) — в плюс со стороны поисковых систем думаю не с играет.
2. Если забить на поисковики, либо предположить что у вас свеже установленный сайт. То все равно это пародит кучу доп проблем. Например: нам нужно будет избавляться от всего что выводится в код из данного каталога: скриптов, которые подключаю пакеты, картинок которые вы режете при помощи pThumb (или подобных пакетов) и т.д.

Для тех кому трудности не почем, и кто решил все таки переименовать каталог assets, читаем далее, пути решения выше упомянутых проблем. Уточню! Актуально в первую очередь для тех у кого сайт с контентом!

Переделываем шаблоны

Если у вас все файлы хранились в assets/ то дизайн у вас весь поломался, так как такого каталога больше нет. Рекомендую в корне сайта создать каталог template (или просто в корень) и перенести все файлы шаблона (скрипты, стили и т.д. в него), далее сменить все пути в шаблонах, сделать это можно быстро при помощи пакета ModxDevTools (функция поиск и замена — работает для обычных шаблонов и чанков — в статических не ищет, там правите руками).

Изменяем путь к уменьшенным изображениям

При использовании pThumb, phpthumbof или phpthumbon, мы имеем путь к изображению вида /assets/components/pthumb/cache/7a...73.jpg. Так как папку assets мы переименовали. Но умный скрипт или зоркий глаз может увидеть components/pthumb/cache и все понять.

Чтобы поменять этот путь заходим в системные настройки и меняем значения в полях Images Base Directory (pthumb.ptcache_images_basedir) и pThumb Cache Location (pthumb.ptcache_location), на новые значения. Также рекомендую включить: Используйте pThumb Cache (pthumb.use_ptcache) — Да

После чего удаляем папки с кэшированными картинками из /assets/components/phpthumbof/cache/

Возможные проблемы с miniShop2

Если пропали картинки товаров miniShop2 — перейдите в Медиа -> Источники файлов -> MS2 Images, и отредактируйте настройки basePath и baseUrl. Укажите новый путь к папке assets или к папке с изображениями вне assets.

Прочие проблемы

Это далеко не все, открываем код и ищем в нем assets и смотрим что еще выводится, например js скрипты — их тоже нужно перенести! В будущем расширю данную статью решением прочих проблем. Если столкнулись с ними — пишите в комментариях, постараюсь вам помочь.

MODX Revolution: каталог ядра в открытом доступе

Исправим ошибку Каталог ядра в открытом доступе, которая наверняка отобразится у вас в панели управления после установки MODX Revolution.

Ошибка Каталог ядра в открытом доступе встречается часто.

Собственно, сама CMS подсказывает, что надо делать. Первым делом переименуйте файл ht.access в .htaccess в каталоге core. Сделать это можно как непосредственно из панели управления MODX Revolution, так и при помощи любого FTP-клиента, которым вы подключаетесь к серверу.

После этого удалите файл changelog.txt из core/docs.

Это уберет ошибку Каталог ядра в открытом доступе. Если же этого не произошло, очистите кэш через меню Управление.

Защищаем MODX Revolution / Хабр

Привет, друзья!

Немало статей написано и переписано о том, как защитить MODX, но в этой статье я опишу не только стандартные рекомендации по защите инстанса MODX Revolution (далее я буду писать просто MODX, потому что ветка MODX Evolution — это тупиковая ветвь «эволюции» являющаяся рудиментом не заслуживающим внимания современных разработчиков), но и некоторые новые методы «заметания следов».

Итак, начнем самого важного.

Существует две разновидности установщика MODX — это Traditional и Advanced.

Какая между ними разница?

Traditional — это простой вариант установки на любой хостинг соответствующий рекомендациям для установки MODX, где ядро устанавливается прямо в корень публичной папки сайта. Незатейливые «сайтоклёпы» ставят версию Tradtiional, не закрывают директории от просмотра и в итоге всё содержимое сайта, в т.ч. служебных директорий, попадает в индекс поисковиков. Не станем фантазировать на тему, к чему это может привести. Здесь всё понятно.

Advanced — версия для парней, которые, как минимум «смотрели кино про нидзей». Этот вид установщика позволяет разместить ядро MODX вне публичной папки, спрятав его от посягательств злоумышленников. Для серьезных проектов это рекомендуемый вариант, но лично я его использую всегда.

Защита ядра

Защитить ядро можно двумя способами:

1. На нормальном хостинге — вынести ядро из публичной папки и можно его не переименовывать и не настраивать .htaccess лежащий в этом каталоге (на VDS не стоит забывать о настройке прав доступа пользователя, от которого запускается Apache).

2. На дурацком хостинге — переименовать каталог ядра воспользовавшись, например, генератором паролей (без спецсимволов, конечно же — только буквы и цифры) И во время установки указать физический путь к каталогу ядра. Именно поэтому лучше использовать Advanced установщик.

Защита служебных каталогов

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

Что нам сделать для защиты от попыток взлома через коннекторы и попыток проникнуть в админку? Стандартные наименования каталога коннекторов /connectors, а для админки — /manager, и это палево.

Во время установки вам будет предложено изменить эти названия. В этом нам поможет, правильно, — генератор паролей и, как ни странно, в случае с админкой собственная голова. Название каталога админки лучше сделать человекопонятным, но не /admin, конечно же 🙂

Возможно, вы захотите спросить: Почему мы не прячем /assets?

И, возможно, я отвечу: А зачем? Все картинки и скрипты лежат в /assets, а в коде страницы есть все ссылки на картинки и скрипты 🙂

Защита таблиц БД

Во время установки, в настройках БД, по умолчанию предлагается префикс таблиц «modx_». Так дело не пойдет. И вновь нам поможет генератор паролей (Помнишь, товарищ? Только из букв и цифр!). Меняем стандартный префикс на кракозябры, в конце которых ставим нижнее подчеркивание. Например, «IU1xbp4_».

Защита от определения CMS

Сервисы автоматического определения CMS сайтов, конечно, не в курсе, что MODX — это CMF, но это не мешает им определить, что контентом на сайте рулит именно MODX. Казалось бы, мы уже спрятали всё что надо. А вот и нет.

Первым делом, при установке MODX Revolution необходимо отключить чекбокс «X-Powered-By», который включен по умолчанию (на картинке ниже). Это необходимо для того, чтобы MODX не «палился», отправляя в заголовках информацию о том, что сайт сделан на MODX.

Если сайт уже установлен, то проверить этот параметр можно в системных настройках по адресу: домен_вашего.сайта/manager/?a=system/settings

И в поле «Поиск по ключу» ввести «send_poweredby_header» или просто «header» и нажать Enter на клавиатуре. Значение «send_poweredby_header» должно быть установлено как «Нет».

Также не лишним будет скрыть файлы конфигурации.

Для примера, возьмем первую ссылку из приведенного выше списка поиска Google, и попробуем открыть файл настроек config.core.php, или, не смотря на то, что на этом сайте уже закрыт листинг каталогов, по ссылке «www.vvhotel.ru/core/config/config.inc.php», сайт отдает результат исполнения файла .php, а это значит что каждый из этих файлов существует и даже по первому из них можно предположить, что сайт на MODX.

Скрыть этот файл можно при помощи .htaccess, дописав:

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^(.*)config.core.php$
    RewriteRule ^(.*)$ [R=404]
</IfModule>

Кое-что ещё

Кроме описанных приёмов, можно применить небольшую хитрость, чтобы увести возможных злоумышленников по ложному следу. Некоторые «попсовые» CMS добавляли метатэги с указанием названия CMS:

<meta name="generator" content="WordPress x.x.x" />

Можно смело добавить в свой код такой тэг, и создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.

Автоопределялки будут интерпретировать наш MODX как WordPress, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки от простого замка к сканеру сетчатки глаза ( это метафора 🙂 ).

А что, если сайт уже установлен?

В час наименьшей нагрузки, переименуйте все указанные каталоги (/core, если позволяет хостинг, лучше вынести из паблика).

Смените префикс существующих, с помощью phpMyAdmin:

• в левой части phpMyAdmin кликаете на название нужной базы;
• в основной области появится список всех таблиц, внизу которого надо отметить чекбокс «Отметить все»;
• справа от чекбокса комбобокс «С отмеченными:» в котором надо выбрать «Заменить префикс таблицы»;
• в новом окне указать старый префикс и новый префикс, на который надо заменить старый.

Затем, если у вас Traditional, но вы хотите заменить на Advanced, то поверх содержимого /core (или как вы его по-новому назвали) надо записать содержимое каталога /core из архива Advanced установщика, а в корень сайта поместить /setup.

Проверить права и доступ (на каталоги 755, на файлы 644).

Запустить процесс установки.

Во время установки вам надо будет указать физический путь до каталога ядра.

ВАЖНО выбрать вариант установки «Расширенное обновление (с настройкой параметров базы данных)», потому что после ввода данных БД, появится диалог переименования каталогов.

Можно, конечно, было залезть в config.inc.php и отредактировать всё там. Но зачем что-то делать, если этого можно не делать? 🙂

На этом всё. Если информация из этой статьи окажется Вам полезной — супер. Если захотите что-то спросить, добавить или просто поумничать — вэлкам в коменты!

revenue.ru | Создание, поисковая оптимизация, продвижение и монетизация сайтов. Инструменты для веб-разработчиков, CMS сборки.

MODX Revo MODX AjaxForm — документация и примеры построения контактных форм

229.07.2020Алексей

В прошлом уроке мы разобрали документация по пакету

MODX Revo

128.07.2020Алексей

В данном уроке разберемся с правильными настройка файла .

MODX Revo MODX админка — обзор, как зайти

023.07.2020Алексей

В данной статье разберем MODX админку: как зайти в

MODX Revo Установка MODX Revolution

023.07.2020Алексей

Урок о том, как установить MODX Revolution на хостинг

MODX Revo MODX Revolution уроки для начинающих

023.07.2020Алексей

Изменена: 29 июля 2020 в 20:15Приветствую на бесплатном

MODX Revo

1022.07.2020Алексей

Изменена: 23 июля 2020 в 18:35В предыдущей статье мы

MODX Revo MODX pdoField — получение и вывод полей родителя (ей)

021.07.2020Алексей

Довольно часто требуется получить и вывести поля родителей

MODX Revo Многоуровневое MODX меню с использованием Bootstrap

2121.07.2020Алексей

В прошлых уроках мы уже создавали MODX меню: 1й —

MODX Revo pdoMenu — документация и примеры создания меню в MODX

3021.07.2020Алексей

Изменена: 31 июля 2020 в 14:38Приветствую вас уважаемые читатели.

MODX Revo Добавление страниц и разделов

1421.07.2020Алексей

Сегодня мы начнем наполнять контентом наш сайт, а конкретно

MODX Revo MODX теги — тегирование для ресурсов, при помощи MIGX.

018.07.2020Алексей

В данном уроке реализуем активные элементы —

MODX Revo Расширение файла «…» не допускается

017.07.2020Алексей

Данная коротенькая статья о том, как побороть ошибку

Навигация по записям

Версии MODX 2.4.0-pl и 2.3.6-pl / Русскоязычное сообщество MODX

Для обновления и установки доступны новые версии MODX: 2.4.0-pl и 2.3.6-pl.

2.4.0-pl

• Зависимости пакетов, которые заключаются в том, что установка пакета блокируется, пока не установлено требуемое. Документация здесь.
• Всякие разные улучшения UI
• Героические усилия @markwillis82 по покрытию движка тестами
• Новые индексы в БД для увеличения производительности
• Все изменения здесь

Объявление в официальном блоге. Обновляться на эту версию пока не рекомендуется, как минимум из-за этого бага.

Картинки по работе зависимостей:

Никакой автоустановки или обновления версий, как мы пишем сейчас в ресолверах, пока нет.

2.3.6-pl

• При установке через web-интерфейс можно сразу отключить сжатие файлов
• Закрыта потенциальная XSS уязвимость в процессорах создания и обновления ресурсов
• Исправлена ошибка с исчезанием пагинации при выборе категории элементов в некоторых combo-боксах
• Улучшено окошко настройки устанавливаемого дополнения
• Улучшено отображение картинок в превьюшках админки
• Версия CMS показывается при наведении курсора на логотип MODX в админке
• Все изменения можно посмотреть в changelog

Объявление в официальном блоге.

Новые версии уже доступны на modhost.pro. Пользуясь случаем, я выделил кнопку обновления оранжевым цветом и сделал так, чтобы в диалоге сразу выбиралась последняя стабильная версия.

Не забывайте про бэкапы при обновлении!

Обновлено 21.08.2015

В комментариях обнаружили баг с показом окошка свойств элемента при перетаскивании его в шаблон. Вот ссылка на pull-request с исправлением.

записей каталога — документация ядра Linux

В файловой системе ext4 каталог представляет собой более или менее плоский файл, который отображает
произвольная байтовая строка (обычно ASCII) к номеру inode на
файловая система. В файловой системе может быть много записей каталога
которые ссылаются на один и тот же номер inode — они известны как жесткие ссылки и
вот почему жесткие ссылки не могут ссылаться на файлы в других файловых системах. Как
например, записи каталога обнаруживаются путем чтения блока (ов) данных
связанный с файлом каталога для конкретной записи каталога, который
желательно.

Линейные (классические) каталоги

По умолчанию каждый каталог перечисляет свои записи в «почти линейном» виде.
массив. Я пишу «почти», потому что это не линейный массив в памяти
смысл, потому что записи каталога не разделены на блоки файловой системы.
Поэтому правильнее сказать, что каталог представляет собой серию
блоки данных и что каждый блок содержит линейный массив каталогов
записи. Конец каждого блочного массива обозначается достижением
конец блока; последняя запись в блоке имеет длину записи, которая
проходит весь путь до конца блока.Конец всего
каталог, конечно, обозначается достижением конца файла. Неиспользованный
записи каталога обозначаются inode = 0. По умолчанию файловая система
использует структуру struct ext4_dir_entry_2 для записей каталога, если только
Флаг функции «тип файла» не установлен, и в этом случае он использует
структура ext4_dir_entry .

Исходный формат записи каталога — struct ext4_dir_entry , что
не более 263 байтов, хотя на диске вам потребуется указать
dirent.rec_len , чтобы знать наверняка.

Поскольку имена файлов не могут быть длиннее 255 байт, новый каталог
формат записи сокращает поле name_len и использует пространство для файла
флаг типа, вероятно, чтобы избежать загрузки каждого inode во время каталога
обход дерева. Это формат ext4_dir_entry_2 , что не более
263 байта, хотя на диске вам нужно будет указать
dirent.rec_len , чтобы знать наверняка.

Тип файла каталога — одно из следующих значений:

Справочник

Чтобы добавить контрольные суммы к этим классическим блокам каталогов, фальшивый
struct ext4_dir_entry помещается в конец каждого листового блока, чтобы
держите контрольную сумму.Запись каталога имеет длину 12 байт. Inode
Поля number и name_len установлены в ноль, чтобы обмануть старое программное обеспечение.
игнорирование явно пустой записи в каталоге, и контрольная сумма сохраняется
в том месте, где обычно идет имя. Структура
структура ext4_dir_entry_tail :

Контрольная сумма блока конечного каталога рассчитывается по UUID FS,
номер inode каталога, номер генерации inode каталога и
весь блок записей каталога до (но не включая) подделки
запись в каталоге.

Каталоги хэш-деревьев

Линейный массив записей каталога не очень эффективен, поэтому
в ext3 была добавлена ​​новая функция для обеспечения более быстрого (но своеобразного)
сбалансированное дерево с хеш-кодом имени записи каталога.Если
В индексном дескрипторе установлен флаг EXT4_INDEX_FL (0x1000), в этом каталоге используется
хешированный btree (htree) для организации и поиска записей в каталоге. За
обратная совместимость с ext2 только для чтения, это дерево на самом деле
скрытый внутри файла каталога, маскирующийся под «пустые» данные каталога
блоки! Ранее было сказано, что конец линейного каталога
таблица записей была обозначена записью, указывающей на индекс 0; это
(ab) использовался, чтобы обмануть старый алгоритм линейного сканирования, заставив думать, что
остальная часть блока каталога пуста, поэтому он перемещается дальше.

Корень дерева всегда находится в первом блоке данных
каталог. По выбору ext2 записи «.» И «..» должны отображаться в
начало этого первого блока, поэтому они помещены здесь как два
struct ext4_dir_entry_2 s и не хранится в дереве. Остальные
корневой узел содержит метаданные о дереве и, наконец, блок hash->
map, чтобы найти узлы, расположенные ниже в h-дереве. Если
dx_root.info.indirect_levels не равно нулю, тогда у htree два
уровни; блок данных, на который указывает карта корневого узла, является внутренним
узел, который индексируется второстепенным хешем.Внутренние узлы в этом дереве
содержит обнуленную структуру struct ext4_dir_entry_2 , за которой следует
minor_hash-> карта блоков для поиска листовых узлов. Узлы листа содержат линейный
массив всех struct ext4_dir_entry_2 ; все эти записи
(предположительно) хеш с тем же значением. Если есть переполнение,
записи просто перетекают в следующий листовой узел, и
младший бит хэша (на карте внутреннего узла), который получает
мы устанавливаем этот следующий листовой узел.

Чтобы пройти по каталогу как по дереву, код вычисляет хэш
желаемое имя файла и использует его для поиска соответствующего блока
количество.Если дерево плоское, блок представляет собой линейный массив каталогов
записи, которые можно искать; в противном случае младший хэш имени файла
вычисляется и используется против этого второго блока, чтобы найти соответствующий
номер третьего блока. Номер третьего блока будет линейным массивом
записи каталога.

Чтобы пройти по каталогу как по линейному массиву (как в старом коде),
код просто считывает каждый блок данных в каталоге. Используемые блоки
для htree не будет записей (кроме ‘.’ а также ‘..’)
и поэтому только листовые узлы будут иметь какое-либо интересное содержимое.

Корень htree находится в struct dx_root , что является полной длиной
блока данных:

Хэш каталога имеет одно из следующих значений:

Внутренние узлы дерева htree записываются как struct dx_node , т.е.
также полная длина блока данных:

Хэш-карты, которые существуют как в структуре struct dx_root , так и в
struct dx_node записывается как struct dx_entry , что составляет 8 байтов
длинный:

(Если вы думаете, что все это довольно умно и необычно, то
автор.)

Если включены контрольные суммы метаданных, последние 8 байтов каталога
блок (точно длина одного dx_entry) используются для хранения
struct dx_tail , которая содержит контрольную сумму. Предел и
count записей в структурах dx_root / dx_node корректируются как
необходимо, чтобы dx_tail поместился в блок.Если нет места для
dx_tail, пользователь получает уведомление о необходимости запустить e2fsck -D, чтобы перестроить
каталог index (который гарантирует, что есть место для контрольной суммы.
Структура dx_tail имеет длину 8 байт и выглядит так:

Контрольная сумма вычисляется по UUID FS, заголовку индекса htree
(dx_root или dx_node), все индексы htree (dx_entry), которые находятся в
use, и хвостовой блок (dx_tail).

.

HOWTO по разработке ядра Linux — Документация по ядру Linux

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

Если что-либо в этом документе устареет, присылайте исправления
обслуживающему персоналу этого файла, который указан в нижней части
документ.

Введение

Итак, вы хотите узнать, как стать разработчиком ядра Linux? Или ты
ваш менеджер сказал: «Пойдите, напишите драйвер Linux для этого
устройство. » Цель этого документа — научить вас всему, что вам нужно
знать, как достичь этого, описав процесс, который вам нужно пройти,
и подсказывает, как работать с сообществом. Он также попытается
объясните некоторые причины, по которым сообщество работает именно так.

Ядро написано в основном на C, с некоторыми архитектурно-зависимыми
детали написаны в сборке.Хорошее понимание C требуется для
разработка ядра. Сборка (любая архитектура) не требуется, если только
вы планируете заняться разработкой этой архитектуры на низком уровне. Хотя они
не являются хорошей заменой твердому C-образованию и / или годам
опыта, следующие книги пригодны для справки:

• «Язык программирования C» Керниган и Ричи [Прентис Холл]
• «Практическое программирование на языке C», Стив Уаллин [O’Reilly]
• «C: Справочное руководство» Харбисона и Стила [Прентис Холл]

Ядро написано с использованием GNU C и набора инструментов GNU.Пока это
придерживается стандарта ISO C89, он использует ряд расширений, которые
не входит в стандарт. Ядро — это автономный C
среды, не полагаясь на стандартную библиотеку C, поэтому некоторые
части стандарта C не поддерживаются. Произвольный длинный длинный
деления и числа с плавающей запятой не допускаются. Иногда это может быть
трудно понять предположения, которые ядро ​​имеет в цепочке инструментов
и расширения, которые он использует, и, к сожалению, нет
исчерпывающая ссылка на них.Пожалуйста, проверьте страницы информации gcc (информация
gcc ) для получения информации о них.

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

Правовые вопросы

Исходный код ядра Linux выпущен под лицензией GPL. Пожалуйста, посмотрите файл
КОПИРОВАНИЕ в основной каталог исходного дерева. Лицензирование ядра Linux
правила и как использовать идентификаторы SPDX в исходном коде:
описано в Documentation / process / license-rules.rst.
Если у вас есть дополнительные вопросы по лицензии, обратитесь к юристу и
не спрашивайте в списке рассылки ядра Linux. Люди в списках рассылки
не юристы, и вам не следует полагаться на их заявления по юридическим вопросам.

Общие вопросы и ответы о GPL см. По адресу:

Документация

В дереве исходных текстов ядра Linux есть большой набор документов,
бесценен для изучения того, как взаимодействовать с сообществом ядра. когда
в ядро ​​добавлены новые функции, рекомендуется
Также добавлены файлы документации, в которых объясняется, как использовать эту функцию.
Когда изменение ядра приводит к тому, что интерфейс, который ядро ​​предоставляет
пользовательское пространство для изменения, рекомендуется отправить информацию или
патч к страницам руководства, объясняющий изменение страниц руководства
сопровождающий в [email protected] и отправьте копию списка
[email protected].

Вот список файлов в дереве исходного кода ядра, которые
требуется чтение:

Документация / руководство администратора / README.rst

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

Документация / процесс / changes.rst

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

Документация / процесс / coding-style.rst

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

Документация / процесс / submitting-patches.rst и Документация / process / submitting-drivers.rst

Эти файлы подробно описывают, как успешно создавать
и отправьте патч, включая (но не ограничиваясь):

• Содержание сообщения электронной почты
• Формат электронной почты
• Кому послать на

Следование этим правилам не гарантирует успеха (поскольку все патчи
подлежат тщательной проверке на предмет содержания и стиля), но не следуя им
почти всегда предотвратит это.

Другие отличные описания того, как правильно создавать патчи:

Документация / процесс / stable-api-nonsense.rst

Этот файл описывает обоснование сознательного решения
не иметь стабильного API в ядре, включая такие вещи, как:

• Подсистема регулировочных пластин (для совместимости?)
• Переносимость драйверов между операционными системами.
• Снижение риска быстрых изменений в дереве исходных текстов ядра (или
  предотвращение быстрой смены)

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

Документация / руководство администратора / security-bugs.rst

Если вы чувствуете, что обнаружили проблему безопасности в ядре Linux,
пожалуйста, следуйте инструкциям в этом документе, чтобы уведомить ядро
разработчиков и помогите решить проблему.

Документация / процесс / management-style.rst

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

Документация / процесс / stable-kernel-rules.rst

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

Документация / процесс / kernel-docs.rst

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

Документация / процесс / применение патчей.первый

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

Ядро также имеет большое количество документов, которые можно
автоматически генерируется из самого исходного кода или из
Разметка ReStructuredText (ReST), как эта. Это включает
полное описание встроенного в ядро ​​API и правила обработки
блокировка должным образом.

Все такие документы можно сгенерировать как PDF или HTML, запустив:

 сделать pdfdocs
сделать htmldocs
 

соответственно из основного исходного каталога ядра.

Документы, в которых используется разметка ReST, будут созданы в разделе «Документация / вывод».
Их также можно сгенерировать в форматах LaTeX и ePub с помощью:

 сделать latexdocs
сделать epubdocs
 

Стать разработчиком ядра

Если вы ничего не знаете о разработке ядра Linux, вам следует
посмотрите проект Linux KernelNewbies:

Он состоит из полезного списка рассылки, в котором вы можете задать почти любой тип
основного вопроса о разработке ядра (не забудьте поискать в архивах
сначала, прежде чем спрашивать то, на что уже был дан ответ в
прошлое.) Он также имеет канал IRC, который вы можете использовать, чтобы задавать вопросы в
в реальном времени и много полезной документации, которая полезна для
узнать о разработке ядра Linux.

На сайте представлена ​​основная информация об организации кода, подсистемах,
и текущие проекты (как в дереве, так и вне дерева). Он также описывает
некоторая базовая логистическая информация, например, как скомпилировать ядро ​​и
применить патч.

Если вы не знаете, с чего хотите начать, но хотите найти
какую-то задачу начать делать, чтобы присоединиться к сообществу разработчиков ядра,
перейти к проекту Linux Kernel Janitor:

Это отличное место для начала.Он описывает список относительно простых
проблемы, которые необходимо устранить и исправить в ядре Linux
исходное дерево. Работая с разработчиками, отвечающими за этот проект, вы
изучит основы добавления патча в дерево ядра Linux,
и, возможно, укажут направление, над чем работать дальше, если
у вас еще нет идеи.

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

Процесс разработки

Процесс разработки ядра Linux в настоящее время состоит из нескольких различных
основные «ветки» ядра и множество различных специфичных для подсистем ядра
ветви.Эти разные отделения:

• Основное дерево Линуса
• Различные стабильные деревья с несколькими старшими номерами
• Деревья, специфичные для подсистем
• дерево интеграционного тестирования linux-next

Основное дерево

Основное дерево обслуживает Линус Торвальдс, и его можно найти на
https://kernel.org или в репо. Процесс его разработки выглядит следующим образом:

• Как только выходит новое ядро, открывается двухнедельное окно,
  в течение этого периода времени сопровождающие могут отправлять большие изменения в
  Линус, обычно патчи, которые уже были включены в
  linux-next на несколько недель.Предпочтительный способ отправки больших изменений
  использует git (инструмент управления исходным кодом ядра, дополнительная информация
  можно найти на https://git-scm.com/), но простые патчи также просто
  хорошо.
• Через две недели выпускается ядро ​​-rc1, и основное внимание уделяется созданию
  новое ядро ​​как можно надежнее. Большинство патчей на данный момент
  следует исправить регресс. Ошибки, которые существовали всегда, не
  регрессии, поэтому предлагайте такие исправления, только если они важны.
  Обратите внимание, что может быть принят совершенно новый драйвер (или файловая система)
  после -rc1, потому что нет риска вызвать регрессию с таким
  изменение, пока изменение является самодостаточным и не затрагивает области
  вне добавляемого кода.git можно использовать для отправки
  патчи к Linus после выпуска -rc1, но патчи также должны быть
  отправлено в общедоступный список рассылки для проверки.
• Новый -rc выпускается всякий раз, когда Линус считает текущее дерево git
  быть в разумно нормальном состоянии, пригодном для тестирования. Цель состоит в том, чтобы
  выпускать новое ядро ​​-rc каждую неделю.
• Процесс продолжается до тех пор, пока ядро ​​не будет признано «готовым»,
  процесс должен длиться около 6 недель.

Стоит упомянуть, что написал Эндрю Мортон о linux-ядре
список рассылки о выпусках ядра:

«Никто не знает, когда будет выпущено ядро, потому что оно
выпущен в соответствии с предполагаемым статусом ошибки, а не в соответствии с
предвзятые сроки.”

Различные стабильные деревья с несколькими старшими номерами

Ядра с 3-частными версиями являются стабильными ядрами. Они содержат
относительно небольшие и критические исправления проблем безопасности или значительных
регрессии, обнаруженные в данной основной основной версии. Каждый выпуск
в основной стабильной серии приращает третья часть версии
число, сохраняя первые две части одинаковыми.

Это рекомендуемая ветка для пользователей, которым нужна последняя стабильная версия.
ядро и не заинтересованы в помощи в разработке тестов / экспериментальных
версии.

Стабильные деревья обслуживаются «стабильной» командой , и
выпускаются по мере необходимости. Нормальный период выпуска составляет примерно
две недели, но может быть и больше, если нет насущных проблем. А
проблема, связанная с безопасностью, вместо этого может привести к тому, что релиз произойдет почти
мгновенно.

Файл Documentation / process / stable-kernel-rules.rst
в документах дерева ядра, какие изменения допустимы для
-стабильное дерево и как работает процесс выпуска.

Деревья для конкретных подсистем

Сопровождающие различных подсистем ядра — а также многие
разработчики подсистем ядра — раскрывают их текущее состояние
разработка в исходных репозиториях. Таким образом, другие могут увидеть, что
происходит в разных частях ядра. В областях, где
разработка идет быстро, разработчика могут попросить обосновать свои предложения
на такое дерево ядра подсистемы, чтобы конфликты между
представление и другая уже текущая работа избегаются.

Большинство этих репозиториев представляют собой деревья git, но есть и другие SCM
уже используются, или очереди исправлений публикуются как серия quilt. Адреса
эти репозитории подсистем перечислены в файле MAINTAINERS. Много
из них можно просмотреть на https://git.kernel.org/.

Прежде чем предложенный патч будет зафиксирован в таком дереве подсистем, он
подлежат проверке, которая в основном происходит в списках рассылки (см.
соответствующий раздел ниже). Для нескольких подсистем ядра этот обзор
процесс отслеживается с помощью инструмента лоскутное одеяло.Пэчворк предлагает сеть
интерфейс, который показывает публикации патчей, любые комментарии к патчу или
изменения к нему, и сопровождающие могут отмечать исправления как находящиеся на рассмотрении,
принято или отклонено. Большинство этих лоскутных сайтов перечислены на
https://patchwork.kernel.org/.

дерево интеграционного тестирования linux-next

Перед тем, как обновления из деревьев подсистем будут объединены в основное дерево,
они должны быть проверены на интеграцию. Для этого есть специальный
существует репозиторий тестирования, в который помещены практически все деревья подсистем.
тянут практически ежедневно:

Таким образом, linux-next дает общее представление о том, что будет
ожидается, что он войдет в основное ядро ​​в следующий период слияния.Приглашаем отважных тестировщиков протестировать linux-next во время выполнения.

Сообщения об ошибках

https://bugzilla.kernel.org — это место, где разработчики ядра Linux отслеживают ядро
ошибки. Пользователям рекомендуется сообщать обо всех ошибках, которые они находят в этом
орудие труда. Для получения дополнительной информации о том, как использовать ядро ​​bugzilla, см .:

Файл admin-guide / reporting-bugs.rst
в основном каталоге исходного кода ядра есть хороший
шаблон о том, как сообщить о возможной ошибке ядра, и подробности о том, какого рода
разработчикам ядра требуется информация, чтобы помочь отследить
проблема.

Управление отчетами об ошибках

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

Для работы с отчетами об ошибках, о которых уже сообщалось, перейдите по адресу https: // bugzilla.kernel.org.

Списки рассылки

Как описано в некоторых из вышеперечисленных документов, большая часть ядра ядра
разработчики участвуют в списке рассылки ядра Linux. Подробно о том, как
подписаться и отказаться от рассылки можно по адресу:

В Интернете есть архивы списков рассылки в самых разных
места. Используйте поисковую систему, чтобы найти эти архивы. Например:

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

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

Многие списки размещены на kernel.org. Информация о них может быть
Найдено по адресу:

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

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

Не забудьте сохранить контекст и атрибуцию ваших ответов.
оставьте строки «Джон Кернелхакер написал…:» в верхней части ответа, и
добавьте свои утверждения между отдельными цитируемыми разделами вместо
писать в верхней части письма.

Если вы добавляете исправления в свою почту, убедитесь, что они представляют собой простой читаемый текст.
как указано в Documentation / process / submitting-patches.rst.
Разработчики ядра не хотят иметь дело с
вложения или сжатые патчи; они могут захотеть прокомментировать
отдельные строчки вашего патча, который работает только так.Убедись, что ты
используйте почтовую программу, которая не искажает пробелы и символы табуляции. А
Хороший первый тест — отправить письмо самому себе и попробовать применить свои
собственный патч самостоятельно. Если это не помогает, исправьте почтовую программу.
или меняйте, пока не заработает.

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

Различия между ядром сообщества и корпоративными структурами

Сообщество ядра работает иначе, чем большинство традиционных корпоративных
среды разработки.Вот список вещей, которые вы можете попробовать
сделать, чтобы избежать проблем:

Хорошие отзывы о предлагаемых вами изменениях:

• «Это решает несколько проблем».
• «Это удаляет 2000 строк кода».
• «Вот патч, объясняющий то, что я пытаюсь описать».
• «Я тестировал его на 5 разных архитектурах…»
• «Вот серия небольших заплаток, которые…»
• «Это увеличивает производительность на типичных машинах…»

Плохих вещей, о которых не следует говорить:

• «Мы сделали это в AIX / ptx / Solaris, поэтому, следовательно, это должно быть
  хорошо… »
• «Я занимаюсь этим 20 лет, так что…»
• «Это необходимо для моей компании, чтобы зарабатывать деньги»
• «Это для нашей линейки продуктов Enterprise.”
• «Вот мой дизайнерский документ на 1000 страниц, в котором описана моя идея»
• «Я работаю над этим 6 месяцев…»
• «Вот патч на 5000 строк, который…»
• «Я переписал весь текущий бардак, и вот он…»
• «У меня крайний срок, и этот патч нужно применить сейчас».

Другим отличием сообщества ядра от большинства традиционных
рабочая среда разработки программного обеспечения — безликая природа
взаимодействие.Одно из преимуществ использования электронной почты и IRC в качестве основных форм
общение — это отсутствие дискриминации по признаку пола или расы.
Рабочая среда ядра Linux принимает женщин и меньшинства
потому что все, что вы есть, это адрес электронной почты. Международный аспект также
помогает уравнять правила игры, потому что вы не можете угадать пол на основе
имя человека. Мужчину можно назвать Андреа, а женщину — Пэт.
Большинство женщин, которые работали с ядром Linux и выразили недовольство
мнение имели положительный опыт.

Языковой барьер может вызвать проблемы у некоторых людей, которые не
комфортно с английским. Хорошее знание языка может потребоваться в
чтобы правильно донести идеи до списков рассылки, так что это
рекомендовал вам проверить свою электронную почту, чтобы убедиться, что они имеют смысл
Английский перед отправкой.

Разбейте свои изменения

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

Причины разрыва следующие:

1. Небольшие исправления увеличивают вероятность того, что ваши исправления будут
   применяются, поскольку они не требуют много времени и усилий для проверки
   правильность.Патч из 5 строк может быть применен сопровождающим с
   едва ли второй взгляд. Однако исправление на 500 строк может занять несколько часов.
   проверка на правильность (время на это экспоненциально
   пропорционально размеру патча, что ли).

   Небольшие патчи также упрощают отладку, когда что-то идет
   неправильно. Гораздо легче откатить патчи один за другим, чем
   рассечь очень большой участок после того, как он был наложен (и сломан
   что нибудь).

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

Вот аналогия от разработчика ядра Al Viro:

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

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

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

Также следует понимать, что отправка патчей для включения недопустима.
которые не закончены и будут «отремонтированы позже».”

Обоснуйте изменение

Наряду с разделением патчей для вас очень важно разрешить
сообщество Linux знает, почему они должны добавить это изменение. Новые особенности
должны быть оправданы как необходимые и полезные.

Задокументируйте свои изменения

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

• зачем нужна смена
• общий подход к дизайну в патче
• подробности реализации
• результаты тестирования

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

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

Спасибо Паоло Чиаррокки, который разрешил «Процесс разработки»
(https://lwn.net/Articles/94386/) раздел
основываться на написанном им тексте, а Рэнди Данлэпу и Герриту
Huizenga — вот список того, что вам следует и не следует говорить.
Также спасибо Пэту Мочелю, Ханне Линдер, Рэнди Данлэпу, Кей Сиверс,
Войтех Павлик, Ян Кара, Джош Бойер, Кис Кук, Эндрю Мортон, Энди
Клин, Вадим Лобанов, Джеспер Джул, Адриан Банк, Кери Харрис, Франс Поп,
Дэвид А.Уилер, Джунио Хамано, Майкл Керриск и Алекс Шепард для
их обзоры, комментарии и вклады. Без их помощи это
документ было бы невозможно.

Сопровождающий: Greg Kroah-Hartman

.

Создание внешних модулей — Документация ядра Linux

В этом документе описывается, как собрать модуль ядра вне дерева.

1. Введение

«kbuild» — это система сборки, используемая ядром Linux. Модули должны использовать
kbuild, чтобы оставаться совместимым с изменениями в инфраструктуре сборки и
чтобы подобрать правильные флаги для «gcc». Функциональность для построения модулей
как в дереве, так и вне дерева. Метод построения
любой похож, и все модули изначально разработаны и построены
вне дерева.

В этом документе содержится информация, предназначенная для разработчиков, заинтересованных
в построении «внеплановых» (или «внешних») модулей. Автор
внешний модуль должен предоставлять make-файл, который скрывает большую часть
сложность, поэтому достаточно набрать «make», чтобы построить модуль. Это
легко выполняется, и полный пример будет представлен на
Раздел 3.

2. Как собрать внешние модули

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

Альтернативой является использование цели «make» «modules_prepare». Это будет
убедитесь, что ядро ​​содержит необходимую информацию. Цель
существует исключительно как простой способ подготовить дерево исходных текстов ядра для
построение внешних модулей.

ПРИМЕЧАНИЕ: «modules_prepare» не будет создавать Module.symvers, даже если
CONFIG_MODVERSIONS установлен; поэтому полная сборка ядра должна быть
выполняется для обеспечения работы управления версиями модуля.

2.1 Синтаксис команд

Команда для создания внешнего модуля:

 $ make -C  M = $ PWD
 

Система kbuild знает, что собирается внешний модуль
из-за параметра «M =

», указанного в команде.

Для сборки против работающего ядра используйте:

 $ make -C / lib / modules / ʻuname -r` / build M = $ PWD
 

Затем, чтобы установить только что построенные модули, добавьте целевой
«Modules_install» к команде:

 $ make -C / lib / modules / ʻuname -r` / build M = $ PWD modules_install
 

2.2 опции

($ KDIR — это путь к исходному каталогу ядра.)

марка -C $ KDIR M = $ PWD

-C $ KDIR

Каталог, в котором находится исходный код ядра.
«Make» фактически перейдет в указанный каталог
при выполнении и вернется обратно по завершении.

M =

$ PWD

Сообщает kbuild, что создается внешний модуль.
Значение, присвоенное «M», является абсолютным путем
каталог, в котором находится внешний модуль (файл kbuild)
расположены.

2.3 Цели

При сборке внешнего модуля только подмножество «make»
цели доступны.

make -C $ KDIR M = $ PWD [цель]

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

модулей

Целевой объект по умолчанию для внешних модулей. Он имеет
такая же функциональность, как если бы цель не была указана. Видеть
описание выше.

modules_install

Установите внешний модуль (и). Местоположение по умолчанию:
/ lib / modules / / extra /, но префикс может
быть добавленным с помощью INSTALL_MOD_PATH (обсуждается в разделе 5).

чистый

Удалите все сгенерированные файлы только в каталоге модуля.

справка

Список доступных целей для внешних модулей.

2.4 Создание отдельных файлов

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

Пример (модуль foo.ko, состоит из bar.o и baz.o):

 марка -C $ KDIR M = $ PWD bar.lst
make -C $ KDIR M = $ PWD baz.o
make -C $ KDIR M = $ PWD foo.ko
make -C $ KDIR M = $ PWD ./
 

3. Создание файла Kbuild для внешнего модуля

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

Система kbuild построит .o из .c,
и после компоновки будет получен модуль ядра .ko.
Вышеупомянутую строку можно поместить в файл «Kbuild» или «Makefile».
Когда модуль построен из нескольких источников, появляется дополнительная строка.
необходимо перечислить файлы:

 <имя_модуля> -y: = .o  .o ...
 

ПРИМЕЧАНИЕ. Дополнительная документация с описанием синтаксиса, используемого kbuild, приведена в
находится в Documentation / kbuild / makefiles.rst.

Примеры ниже демонстрируют, как создать файл сборки для
модуль 8123.ko, который собран из следующих файлов:

 8123_if.c
8123_if.h
8123_pci.c
8123_bin.o_shipped <= двоичный двоичный объект
 

3.1 Общий Makefile

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

Пример 1:

 -> имя файла: Makefile
ifneq ($ (KERNELRELEASE),)
# kbuild часть make-файла
obj-m: = 8123.o
8123-y: = 8123_if.o 8123_pci.o 8123_bin.o

еще
# нормальный make-файл
KDIR? = / Lib / modules / ʻuname -r` / build

дефолт:
        $ (СДЕЛАТЬ) -C $ (KDIR) M = $$ PWD

# Конкретные цели модуля
генбин:
        echo "X"> 8123_bin.o_shipped

endif
 

Чек для KERNELRELEASE используется для разделения двух частей
из make-файла. В этом примере kbuild увидит только два
назначения, тогда как make будет видеть все, кроме этих
два задания. Это связано с двумя проходами, выполненными с файлом:
первый проход выполняется экземпляром make, запущенным по команде
линия; второй проход выполняется системой kbuild, которая
инициируется параметризованным «make» в цели по умолчанию.

3.2 Отдельные файлы Kbuild и Makefile

В более новых версиях ядра kbuild сначала ищет
файл с именем «Kbuild», и только если он не найден, он
затем поищите make-файл.Использование файла «Kbuild» позволяет нам
чтобы разделить make-файл из примера 1 на два файла:

Пример 2:

 -> имя файла: Kbuild
obj-m: = 8123.o
8123-y: = 8123_if.o 8123_pci.o 8123_bin.o

-> имя файла: Makefile
KDIR? = / Lib / modules / ʻuname -r` / build

дефолт:
        $ (СДЕЛАТЬ) -C $ (KDIR) M = $$ PWD

# Конкретные цели модуля
генбин:
        echo "X"> 8123_bin.o_shipped
 

Разделение в примере 2 вызывает сомнения из-за простоты
каждый файл; однако некоторые внешние модули используют make-файлы
состоящий из нескольких сотен строк, и здесь действительно выгодно
off, чтобы отделить часть kbuild от остального.

В следующем примере показана версия с обратной совместимостью.

Пример 3:

 -> имя файла: Kbuild
obj-m: = 8123.o
8123-y: = 8123_if.o 8123_pci.o 8123_bin.o

-> имя файла: Makefile
ifneq ($ (KERNELRELEASE),)
# kbuild часть make-файла
включить Kbuild

еще
# нормальный make-файл
KDIR? = / Lib / modules / ʻuname -r` / build

дефолт:
        $ (СДЕЛАТЬ) -C $ (KDIR) M = $$ PWD

# Конкретные цели модуля
генбин:
        echo "X"> 8123_bin.o_shipped

endif
 

Здесь файл «Kbuild» включен из make-файла.Эта
позволяет более старую версию kbuild, которая знает только
make-файлы, которые будут использоваться, когда части make и kbuild
разбить на отдельные файлы.

3.3 Двоичные капли

Некоторые внешние модули должны включать объектный файл как большой двоичный объект.
kbuild поддерживает это, но требует, чтобы файл большого двоичного объекта был
с именем _shipped. Когда срабатывают правила kbuild, копия
из _shipped создается с удаленным _shipped,
давая нам <имя файла>. Это сокращенное имя файла можно использовать в
присвоение модулю.

В этом разделе 8123_bin.o_shipped используется для
собрать модуль ядра 8123.ko; он был включен как
8123_bin.o:

 8123-y: = 8123_if.o 8123_pci.o 8123_bin.o
 

Хотя нет различия между обычным источником
файлы и двоичный файл, kbuild подберет разные правила
при создании объектного файла для модуля.

3.4 Создание нескольких модулей

kbuild поддерживает создание нескольких модулей с помощью одной сборки
файл.Например, если вы хотите собрать два модуля, foo.ko
и bar.ko, строки kbuild будут такими:

 obj-m: = foo.o bar.o
foo-y: = 
bar-y: = 
 

Это так просто!

4. Включить файлы

В ядре файлы заголовков хранятся в стандартных местах.
по следующему правилу:

• Если файл заголовка описывает только внутренний интерфейс
  модуль, то файл помещается в тот же каталог, что и
  исходные файлы.

• Если файл заголовка описывает интерфейс, используемый другими частями
  ядра, которые находятся в разных каталогах, то
  файл находится в include / linux /.

  ПРИМЕЧАНИЕ:

  Есть два заметных исключения из этого правила: больше
  подсистемы имеют свой собственный каталог в include /, например
  включить / scsi; и заголовки, специфичные для архитектуры, расположены
  в разделе arch / $ (ARCH) / include /.

4.1 Ядро включает

Чтобы включить файл заголовка, расположенный в include / linux /, просто
использование:

 # включить 
 

kbuild добавит параметры в «gcc», чтобы соответствующие каталоги
ищутся.

4.2 Один подкаталог

Внешние модули обычно помещают файлы заголовков в отдельный
include / каталог, в котором находится их источник, хотя это
это не обычный стиль ядра. Чтобы сообщить kbuild о
каталог используйте либо ccflags-y, либо CFLAGS_ <имя файла> .o.

Используя пример из раздела 3, если бы мы переместили 8123_if.h в
подкаталог с именем include, результирующий файл kbuild будет
выглядит так:

 -> имя файла: Kbuild
obj-m: = 8123.о

ccflags-y: = -Iinclude
8123-y: = 8123_if.o 8123_pci.o 8123_bin.o
 

Обратите внимание, что в присвоении нет пробела между -I и
путь. Это ограничение kbuild: не должно быть
пространство присутствует.

4.3 Несколько подкаталогов

kbuild может обрабатывать файлы, расположенные в нескольких каталогах.
Рассмотрим следующий пример:

.
| __ src
| | __ complex_main.c
| | __ hal
| | __ hardwareif.c
| | __ включить
| | __ аппаратное обеспечениеif.час
| __ включить
| __ complex.h
 

Для сборки модуля complex.ko нам понадобятся следующие
kbuild файл:

 -> имя файла: Kbuild
obj-m: = complex.o
комплекс-y: = src / complex_main.o
комплекс-y + = src / hal / hardwareif.o

ccflags-y: = -I $ (src) / включить
ccflags-y + = -I $ (src) / src / hal / включить
 

Как видите, kbuild умеет обрабатывать объектные файлы, расположенные
в других каталогах. Хитрость заключается в том, чтобы указать каталог
относительно расположения файла kbuild. При этом это
НЕ рекомендуется.

Для файлов заголовков kbuild должно быть явно указано, куда
смотреть. Когда выполняется kbuild, текущий каталог всегда является
корень дерева ядра (аргумент «-C») и, следовательно,
нужен абсолютный путь. $ (src) предоставляет абсолютный путь по
указывая на каталог, в котором в данный момент выполняется kbuild
файл находится.

5. Установка модуля

Модули, входящие в состав ядра, устанавливаются в
каталог:

/ библиотека / модули / $ (KERNELRELEASE) / ядро ​​/

А внешние модули установлены в:

/ библиотека / модули / $ (KERNELRELEASE) / extra /

5.1 INSTALL_MOD_PATH

Выше указаны каталоги по умолчанию, но, как всегда, некоторый уровень
возможна настройка. К префиксу можно добавить
путь установки с помощью переменной INSTALL_MOD_PATH:

 $ make INSTALL_MOD_PATH = / frodo modules_install
=> Установить каталог: / frodo / lib / modules / $ (KERNELRELEASE) / kernel /
 

INSTALL_MOD_PATH может быть установлен как обычная переменная оболочки или,
как показано выше, можно указать в командной строке, когда
называя "сделать". Это действует при установке как в дереве
и модули вне дерева.

5.2 INSTALL_MOD_DIR

Внешние модули по умолчанию устанавливаются в каталог под
/ lib / modules / $ (KERNELRELEASE) / extra /, но вы можете пожелать
размещать модули для определенных функций в отдельном
каталог. Для этого используйте INSTALL_MOD_DIR, чтобы указать
альтернативное название для «extra.»:

 $ make INSTALL_MOD_DIR = gandalf -C $ KDIR \
       M = $ PWD modules_install
=> Установить каталог: / lib / modules / $ (KERNELRELEASE) / gandalf /
 

6.Управление версиями модуля

Управление версиями модуля включается тегом CONFIG_MODVERSIONS и используется
как простая проверка согласованности ABI. CRC-значение полного прототипа
для экспортируемого символа создается. Когда модуль загружен / используется,
Значения CRC, содержащиеся в ядре, сравниваются с аналогичными значениями в
модуль; если они не равны, ядро ​​отказывается загружать
модуль.

Module.symvers содержит список всех экспортируемых символов из ядра.
построить.

6.1 Символы из ядра (vmlinux + модули)

Во время сборки ядра файл с именем Module.симверы будут
генерируется. Module.symvers содержит все экспортированные символы из
ядро и скомпилированные модули. Для каждого символа
соответствующее значение CRC также сохраняется.

Синтаксис файла Module.symvers:

  <Символ> <Модуль> <Тип экспорта> <Пространство имен>

0xe1cc2a05 драйверы usb_stor_suspend / usb / storage / usb-storage EXPORT_SYMBOL_GPL USB_STORAGE
 

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

Для сборки ядра без включенной CONFIG_MODVERSIONS CRC
прочитал бы 0x00000000.

Module.symvers служит двум целям:

1. В нем перечислены все символы, экспортированные из vmlinux и всех модулей.
2. В нем отображается CRC, если включен параметр CONFIG_MODVERSIONS.

6.2 Символы и внешние модули

При сборке внешнего модуля системе сборки требуется доступ
к символам из ядра, чтобы проверить, все ли внешние символы
определены.Это делается на шаге MODPOST. modpost получает
символы, прочитав Module.symvers из исходного кода ядра
дерево. На этапе MODPOST будет создан новый файл Module.symvers.
написано, содержащее все символы, экспортированные из этого внешнего модуля.

6.3 Символы из другого внешнего модуля

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

ПРИМЕЧАНИЕ. Рекомендуется использовать метод с файлом kbuild верхнего уровня.
но может оказаться непрактичным в определенных ситуациях.

Использовать файл kbuild верхнего уровня

Если у вас два модуля, foo.ko и bar.ko, где
foo.ko нужны символы из bar.ko, вы можете использовать
общий файл kbuild верхнего уровня, поэтому оба модуля
скомпилирован в той же сборке. Рассмотрим следующее
макет каталога:

 ./foo/ <= содержит foo.ko
./bar/ <= содержит bar.ко
 

Тогда файл kbuild верхнего уровня будет выглядеть так:

 #. / Kbuild (или ./Makefile):
        obj-m: = foo / bar /
 

И исполняющий:

выполнит ожидаемое и скомпилирует оба модуля с
полное знание символов из любого модуля.

Использовать переменную make KBUILD_EXTRA_SYMBOLS

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

7. Советы и хитрости

7.1 Тестирование CONFIG_FOO_BAR

Модули

часто нуждаются в проверке определенных параметров CONFIG_ для
решить, включена ли в модуль конкретная функция. В
kbuild это делается путем ссылки на переменную CONFIG_
напрямую:

 # fs / ext2 / Makefile
obj - $ (CONFIG_EXT2_FS) + = ext2.o

ext2-y: = balloc.o bitmap.o dir.o
ext2 - $ (CONFIG_EXT2_FS_XATTR) + = xattr.o
 

Внешние модули традиционно использовали grep для проверки
конкретные настройки CONFIG_ прямо в .config. Это использование
сломан. Как было сказано ранее, внешние модули должны использовать
kbuild для сборки и поэтому может использовать те же методы, что и
в дереве модулей при тестировании определений CONFIG_ .

.

Yocto Project Руководство по разработке ядра Linux

Помимо поддержки фрагментов конфигурации и исправлений,
Инструменты ядра Yocto Project также поддерживают
Метаданные, которые вы можете
используйте для определения сложных политик и поддержки Board Support Package (BSP).
Назначение метаданных и инструментов для управления ими -
чтобы помочь вам управлять сложностью конфигурации и источников
используется для поддержки нескольких типов BSP и ядра Linux.

Метаданные ядра существуют во многих местах.
Одна область в Yocto Project
Исходные репозитории
- это репозиторий yocto-kernel-cache Git.
Вы можете найти этот репозиторий в группе «Ядро Yocto Linux».
заголовок в
Репозитории исходного кода проекта Yocto.

Инструменты разработки ядра ("kern-tools") существуют также в Yocto.
Репозитории исходного кода проекта под заголовком "Ядро Yocto Linux"
в репозитории yocto-kernel-tools Git.Рецепт создания этих инструментов:
мета / рецепты-ядро / kern-tools / kern-tools-native_git.bb
в
Исходный каталог
(например, poky ).

3.2. Использование метаданных ядра в рецепте¶

Как упоминалось во введении, Yocto Project содержит ядро
Метаданные, которые находятся в
yocto-kernel-cache Репозиторий Git.
Эти метаданные определяют пакеты поддержки платы (BSP), которые
соответствуют определениям в рецептах linux-yocto для соответствующих BSP.BSP состоит из совокупности политики ядра и включенных
аппаратные особенности.
На BSP можно повлиять из рецепта linux-yocto.

Примечание

Рецепт ядра Linux, содержащий метаданные ядра (например,
наследуется от файла linux-yocto.inc )
говорят, что это рецепт "в стиле linux-yocto".

Каждый рецепт стиля linux-yocto должен определять
МАШИНА
переменная.Эта переменная обычно имеет то же значение, что и
MACHINE переменная, которая используется
BitBake.
Однако в некоторых случаях переменная может вместо этого ссылаться на
базовая платформа МАШИНЫ .

Несколько BSP могут повторно использовать один и тот же KMACHINE
имя, если они построены с использованием одного и того же описания BSP.
Несколько BSP на базе Corei7 могут использовать один и тот же "intel-corei7-64"
значение для KMACHINE .Важно понимать, что KMACHINE - это
только для отображения ядра, а МАШИНА
- это тип машины на уровне BSP.
Однако даже с учетом этого различия эти две переменные могут выполняться
такое же значение.
См. Описания BSP
раздел для получения дополнительной информации.

В каждом рецепте стиля linux-yocto также должно быть указано ядро ​​Linux
ветка репозитория исходных текстов, используемая для сборки ядра Linux. KBRANCH
переменная должна быть установлена ​​для указания ветви.

Примечание

Вы можете использовать значение KBRANCH для определения
альтернативная ветвь обычно с переопределением машины, как показано здесь
из слоя meta-yocto-bsp :

     KBRANCH_edgerouter = "стандартный / edgerouter"
             

Рецепты стиля linux-yocto могут дополнительно определять следующие
переменные:

     KERNEL_FEATURES
     LINUX_KERNEL_TYPE
         

LINUX_KERNEL_TYPE
определяет тип ядра как
используется при сборке конфигурации.Если вы не укажете LINUX_KERNEL_TYPE ,
по умолчанию это "стандартный".
Вместе с KMACHINE ,
LINUX_KERNEL_TYPE определяет поиск
аргументы, используемые инструментами ядра для поиска
соответствующее описание в метаданных ядра, с помощью которого
соберите исходники и конфигурацию.
Рецепты linux-yocto определяют «стандартный», «крошечный» и «preempt-rt».
типы ядра.
См. Раздел «Типы ядер»
для получения дополнительной информации о типах ядра.

Во время сборки kern-tools ищет описание BSP
файл, который наиболее точно соответствует KMACHINE
и LINUX_KERNEL_TYPE переменных, переданных из
рецепт блюда.
Инструменты используют первое описание BSP, которое оно находит, что соответствует
обе переменные.
Если инструменты не могут найти совпадение, они выдают предупреждение.

Инструменты сначала ищут KMACHINE и
затем для LINUX_KERNEL_TYPE .Если инструменты не могут найти частичное совпадение, они будут использовать
исходники из KBRANCH и любой конфигурации
указано в
SRC_URI .

Вы можете использовать
ОСОБЕННОСТИ ЯДРА
переменная
для включения функций (фрагментов конфигурации, исправлений или того и другого), которые
еще не включены в KMACHINE и
LINUX_KERNEL_TYPE комбинация переменных.
Например, чтобы включить функцию, указанную как
"особенности / netfilter / netfilter.scc ",
уточнить:

     KERNEL_FEATURES + = "функции / netfilter / netfilter.scc"
         

Чтобы включить функцию под названием "cfg / sound.scc" только для
qemux86 машина, укажите:

     KERNEL_FEATURES_append_qemux86 = "cfg / sound.scc"
         

Значение записей в KERNEL_FEATURES
зависят от их расположения в самих метаданных ядра.
Примеры здесь взяты из
репозиторий yocto-kernel-cache .Каждая ветка этого репозитория содержит «особенности» и «cfg».
подкаталоги на верхнем уровне.
Для получения дополнительной информации см.
«Синтаксис метаданных ядра»
раздел.

3.3. Синтаксис метаданных ядра¶

Метаданные ядра состоят из трех основных типов файлов:
scc
^[]
файлы описания, фрагменты конфигурации и патчи.
Файлы scc определяют переменные и включают или
в противном случае укажите ссылку на любой из трех типов файлов.Файлы описания используются для объединения всех типов ядра.
Метаданные в
что в конечном итоге описывает источники и требуемую конфигурацию
для создания ядра Linux, адаптированного к конкретной машине.

Файлы описания scc используются для определения двух
основные типы метаданных ядра:

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

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

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

        основание   /
        bsp /
        cfg /
        функции/
        ktypes /
        патчи /
         

Каталог bsp содержит
Описание BSP.
Все остальные каталоги содержат «функции».
Отделение bsp от остальной части структуры
помогает концептуализировать предполагаемое использование.

Используйте эти инструкции, чтобы разместить свой scc
файлы описания в структуре:

• Если ваш файл содержит
  только фрагменты конфигурации, поместите файл в
  cfg каталог.

• Если ваш файл содержит
  только исправления исходного кода, поместите файл в папку
  патчей каталог.

• Если ваш файл инкапсулирует
  основная функция, часто объединяющая источники и конфигурации,
  поместите файл в каталог features .

• Если ваш файл агрегатируется
  неаппаратная конфигурация и исправления для определения
  базовая политика ядра или основной тип ядра для повторного использования
  несколько BSP, поместите файл в тыс. типов
  каталог.

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

Пути, используемые в файлах метаданных ядра, относятся к
база , которая либо
ЭКСТРАПАТЫ ФАЙЛОВ
если вы создаете метаданные в
рецепт-пространство,
или верхний уровень
йокто-ядро-кеш
если вы создаете
Метаданные вне области рецептов.

Самая простая единица метаданных ядра - это конфигурация.
особенность.
Эта функция состоит из одной или нескольких конфигураций ядра Linux.
параметры в файле фрагмента конфигурации
(.cfg ) и файл .scc
который описывает фрагмент.

В качестве примера рассмотрим симметричную многопроцессорную обработку (SMP).
фрагмент, используемый с linux-yocto-4.12
ядро, как определено вне области рецепта (т. е.
yocto-kernel-cache ).
Эти метаданные состоят из двух файлов: smp.scc
и smp.cfg .
Вы можете найти эти файлы в каталоге cfg
из йокто-4.12 филиал в г.
yocto-kernel-cache Репозиторий Git:

     cfg / smp.scc:
        определить KFEATURE_DESCRIPTION "Включить SMP для 32-битных сборок"
        определить KFEATURE_COMPATIBILITY все

        kconf оборудование smp.cfg

     cfg / smp.cfg:
        CONFIG_SMP = y
        CONFIG_SCHED_SMT = y
        # Увеличить NR_CPUS по умолчанию с 8 до 64, чтобы платформа с
        # более 8 процессоров могут быть активированы во время загрузки
        CONFIG_NR_CPUS = 64
        # При установке NR_CPUS на что-то необходимо следующее
        # больше 8 на архитектуре x86, должно быть автоматически
        # игнорируется Kconfig при использовании другой арки
        CONFIG_X86_BIGSMP = y
             

Вы можете найти общую информацию о файлах конфигурационных фрагментов в
в
«Создание фрагментов конфигурации»
раздел.

В файле smp.scc
KFEATURE_DESCRIPTION
оператор содержит краткое описание фрагмента.
Это описание используется в инструментах ядра более высокого уровня.

Также в файле smp.scc
kconf команда включает
фактический фрагмент конфигурации в .scc
файл, а ключевое слово "hardware" идентифицирует фрагмент как
будучи аппаратными средствами, в отличие от общей политики,
в котором будет использоваться ключевое слово "не аппаратное обеспечение".Различие сделано в пользу конфигурации
инструменты проверки, которые предупреждают вас, если фрагмент оборудования
отменяет политику, установленную неаппаратным фрагментом.

Примечание

Файл описания может включать несколько
kconf операторов, по одному на фрагмент.

Как описано в
«Проверка конфигурации»
раздел, вы можете использовать следующую команду BitBake для аудита вашего
конфигурация:

     $ bitbake linux-yocto -c kernel_configcheck -f
             

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

Типичный патч включает файл описания и сам патч.
В качестве примера рассмотрим патчи сборки, используемые с
linux-yocto-4.12 Ядро , как определено вне
пространство рецептов (т.е. yocto-kernel-cache ).
Эти метаданные состоят из нескольких файлов:
корп.scc и набор
* .patch файлов.
Вы можете найти эти файлы в патчах / сборка .
справочник отделения yocto-4.12 в
yocto-kernel-cache Репозиторий Git.

В следующих списках показан файл build.scc .
файл и часть
файл modpost-mask-trivial-warnings.patch :

     патчи / сборка / сборка.scc:
        патч рука-сериализовать-сборка-целиs.patch
        патч powerpc-serialize-image-targets.patch
        патч kbuild-exclude-meta-directory-from-distclean-processi.patch

        # применяется kgit
        # патч kbuild-add-meta-files-to-the-ignore-li.patch

        патч modpost-mask-trivial-warnings.patch
        патч menuconfig-check-lxdiaglog.sh-Allow-спецификация-of.patch

     патчи / build / modpost-mask-trivial-warnings.patch:
        От bd48931bc142bdd104668f3a062a1f22600aae61 Пн, 17 сен, 00:00:00 2001
        От: Пол Гортмейкер 
        Дата: 25 января 2009 г., 17:58:09 -0500
        Тема: [PATCH] modpost: маскировать тривиальные предупреждения

        Более новый HOSTCC будет жаловаться на различные stdio fcns, потому что
                          .
                          .
                          .
 char * dump_write = NULL, * files_source = NULL;
 int opt;
        -
        2.10.1

        сгенерировано cgit v0.10.2 в 2017-09-28 15:23:23 (GMT)
             

Файл описания может включать несколько операторов patch, где
каждый оператор обрабатывает один патч.В примере файла build.scc пять патчей
операторы существуют для пяти исправлений в каталоге.

Вы можете создать типичный файл .patch , используя
diff -Nurp или
git format-patch команд.
Для получения информации о том, как создавать патчи, см.
«Использование devtool для исправления ядра»
а также
«Использование традиционной разработки ядра для исправления ядра»
разделы.

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

     features /   myfeature   .scc
        определить KFEATURE_DESCRIPTION "Включить   myfeature  "

        патч 0001-  myfeature   -core.patch
        патч 0002-  myfeature   -интерфейс.патч

        включить cfg /   myfeature   _dependency.scc
        kconf не аппаратный   myfeature   .cfg
             

В этом примере показано, как патч и
kconf команд используются, а также
как дополнительный файл описания функции включен в
включает команду .

Обычно функции менее детализированы, чем конфигурация
фрагменты и более вероятны, чем фрагменты конфигурации
и патчи - это те типы вещей, которые вы хотите указать
в переменной KERNEL_FEATURES файла
Рецепт ядра Linux.См. «Использование метаданных ядра в рецепте»
раздел ранее в руководстве.

Тип ядра определяет высокоуровневую политику ядра посредством
агрегирование фрагментов неаппаратной конфигурации с
патчи, которые вы хотите использовать при сборке ядра Linux
конкретный тип (например, ядро ​​реального времени).
Синтаксически типы ядра не отличаются от функций
как описано в разделе «Возможности»
раздел.В
LINUX_KERNEL_TYPE
переменная в рецепте ядра выбирает тип ядра.
Например, в linux-yocto_4.12.bb
рецепт ядра найден в
poky / meta / recipes-kernel / linux , а
требуется
директива включает
poky / meta / recipes-kernel / linux / linux-yocto.inc
файл, в котором есть следующий оператор, определяющий значение по умолчанию
тип ядра:

     LINUX_KERNEL_TYPE ?? = "стандартный"
             

Другой пример - ядро ​​реального времени (т.е.
linux-yocto-rt_4.12.bb ).
Этот рецепт ядра напрямую устанавливает тип ядра следующим образом:

     LINUX_KERNEL_TYPE = "вытеснение-rt"
             

Три типа ядра («стандартное», «крошечное» и «preempt-rt») являются
поддерживается для ядер Linux Yocto:

• «стандартный»:
  Включает общую политику ядра Linux Yocto
  Рецепты ядра проекта linux-yocto.Эта политика включает, среди прочего, какой файл
  системы, сетевые параметры, основные функции ядра и
  поддерживаются параметры отладки и трассировки.

• «preempt-rt»:
  Применяется PREEMPT_RT
  патчи и параметры конфигурации, необходимые для
  построить ядро ​​Linux в реальном времени.
  Этот тип ядра наследуется от «стандартного» типа ядра.

• «крошечный»:
  Определяет минимальную конфигурацию, предназначенную для использования в качестве
  база для очень маленьких ядер Linux.
  Тип ядра "крошечный" не зависит от "стандартного".
  конфигурация.
  Хотя "крошечный" тип ядра в настоящее время не включает
  любой источник изменится, это может произойти в будущем.

Для любого данного типа ядра метаданные определяются
.scc (например, standard.scc ).
Вот частичный список для стандарта .scc
файл, который находится в ktypes / standard
каталог yocto-kernel-cache Git
репозиторий:

     # Включите этот фрагмент типа ядра, чтобы получить стандартные функции и
     # значения конфигурации.

     # Примечание: если требуются только функции, но не конфигурация
     # тогда это должно быть включено как:
     # включить ktypes / standard / standard.scc nocfg
     # если цепная конфигурация не требуется, включите ее как:
     # включить ktypes / standard / standard.scc nocfg inherit



     включить ktypes / base / base.scc
     отраслевой стандарт

     kconf неаппаратный standard.cfg

     включить функции / kgdb / kgdb.scc
                .
                .
                .

     включить cfg / net / ip6_nf.scc
     включить cfg / net / bridge.scc

     включить cfg / systemd.scc

     включить функции / rfkill / rfkill.scc
             

Как и любой .файл scc , a
определение типа ядра может объединять другие
.scc файлов с
включает команд.
Эти определения также могут напрямую влиять на
фрагменты конфигурации и патчи с
kconf и патч
команды соответственно.

Примечание

Создавать тип ядра не обязательно
.scc файл.
Файл пакета поддержки платы (BSP) может неявно определять
тип ядра с использованием определения
KTYPE myktype
линия.См. «Описание BSP»
раздел для получения дополнительной информации.

3.3.5. Описание BSP¶

Описание BSP (например, файлов * .scc, файлов)
сочетать типы ядра с аппаратными функциями.
Метаданные, специфичные для оборудования, обычно определяются
независимо на уровне BSP, а затем агрегированы с каждым
поддерживаемый тип ядра.

В этом разделе дается обзор структуры описания BSP,
концепции агрегирования и представляет подробный пример использования
BSP, поддерживаемый Yocto Project (т.е. Доска BeagleBone).
Для получения полной информации об иерархии файлов слоя BSP см.
Руководство разработчика Yocto Project Board Support Package (BSP).

Для простоты рассмотрим следующий корневой уровень BSP
файлы описания для платы BeagleBone.
Эти файлы используют как структуру, так и соглашение об именах.
для согласованности.
Соглашение об именах для файла следующее:

        bsp_root_name  -  kernel_type  .scc
                 

Вот несколько примеров имен файлов BSP корневого слоя для
BeagleBone Board BSP, поддерживаемый проектом Yocto:

     beaglebone-standard.scc
     beaglebone-preempt-rt.scc
                 

Каждый файл использует корневое имя (например, "beaglebone") имя BSP.
за которым следует тип ядра.

Изучите стандарт beaglebone-standard.scc
файл:

     определить KMACHINE beaglebone
     определить стандарт KTYPE
     определить руку КАРЧ

     включить ktypes / standard / standard.scc
     ветка биглебона

     включить beaglebone.scc

     # политика по умолчанию для стандартных ядер
     включить функции / latencytop / latencytop.scc
     включить функции / profiling / profiling.scc
                 

Каждый файл описания BSP верхнего уровня должен определять
МАШИНА ,
К ТИП ,
и КАРЧ
переменные.Эти переменные позволяют системе сборки OpenEmbedded определять
описание как отвечающее критериям, установленным рецептом
построен.
Этот пример поддерживает машину "beaglebone" для
«стандартное» ядро ​​и «армейская» архитектура.

Имейте в виду, что жесткая связь между
Переменная KTYPE и тип ядра
файл описания не существует.Таким образом, если в вашем ядре не определен тип ядра
Метаданные в том виде, в каком они есть здесь, вам нужно только убедиться, что
LINUX_KERNEL_TYPE
переменная в рецепте ядра и
KTYPE переменная в описании BSP
файл совпадение.

Чтобы отделить политику ядра от конфигурации оборудования,
вы включаете тип ядра ( ktype ), например
"стандарт".В предыдущем примере это делается следующим образом:

     включить ktypes / standard / standard.scc
                 

В этом файле собраны все фрагменты конфигурации, патчи,
и функции, составляющие стандартную политику ядра.
См. «Типы ядра»
раздел для получения дополнительной информации.

Для объединения общих конфигураций и функций, характерных для
Ядро для mybsp , используйте следующее:

     включают   mybsp  .scc
                 

Вы можете увидеть это в примере BeagleBone следующим образом:

     включить beaglebone.scc
                 

Для получения информации о том, как сломать полный
.config в различные
фрагменты конфигурации, см.
«Создание фрагментов конфигурации»
раздел.

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

     Оборудование kconf   mybsp  -  extra   .cfg
                 

Пример BeagleBone не включает эти типы
конфигурации.
Однако 32-битная плата Мальты поддерживает ("mti-malta32").
Вот mti-malta32-le-standard.scc
файл:

     определить KMACHINE mti-malta32-le
     определить KMACHINE qemumipsel
     определить стандарт KTYPE
     определить KARCH mips

     включить ktypes / standard / standard.scc
     филиал mti-malta32

     включить mti-malta32.scc
     kconf оборудование mti-malta32-le.cfg
                 

Многие примеры из реальной жизни более сложны.
Как и любой другой файл .scc , BSP
описания могут агрегировать функции.
Рассмотрим определение Minnow BSP с учетом
linux-yocto-4.4 филиал
yocto-kernel-cache (т.е.
йокто-ядро-кеш / bsp / minnow / minnow.scc ):

Примечание

Хотя BSP Minnow Board не используется, метаданные
остается и используется здесь как пример.

         включить cfg / x86.scc
         включить функции / eg20t / eg20t.scc
         включить cfg / dmaengine.scc
         включить функции / мощность / intel.scc
         включить cfg / efi.scc
         включить функции / usb / ehci-hcd.scc
         включить функции / usb / ohci-hcd.scc
         включить функции / usb / usb-gadgets.scc
         включить функции / usb / touchscreen-Composite.scc
         включить cfg / timer / hpet.scc
         включить функции / светодиоды / leds.scc
         включить функции / spi / spidev.scc
         включить функции / i2c / i2cdev.scc
         включить функции / mei / mei-txe.scc

         # Для отладки Earlyprintk и порта требуется 8250
         оборудование kconf cfg / 8250.cfg

         kconf оборудование minnow.cfg
         kconf оборудование minnow-dev.cfg
                 

Файл описания minnow.scc включает
фрагмент конфигурации оборудования
( гольян.cfg ), характерный для Minnow
BSP, а также несколько более общих настроек
фрагменты и функции, позволяющие использовать оборудование, обнаруженное на
машина.
Этот файл описания minnow.scc затем
включены в каждый из трех
файлы описания "minnow" для поддерживаемых типов ядра
(т.е. «стандартный», «preempt-rt» и «крошечный»).
Рассмотрим описание "гольяна" для "стандартного" ядра.
тип (т.е. minnow-standard.scc :

         определить KMACHINE minnow
         определить стандарт KTYPE
         определить KARCH i386

         включить ktypes / standard

         включить minnow.scc

         # Дополнительные конфигурации minnow выше минимальных, определенных в minnow.scc
         включить cfg / efi-ext.scc
         включить функции / media / media-all.scc
         включить функции / звук / snd_hda_intel.scc

         # Следующее действительно должно быть в standard.scc
         # Поддержка живых изображений USB
         включить cfg / usb-mass-storage.scc
         включить cfg / boot-live.scc

         # Базовое профилирование
         включить функции / latencytop / latencytop.scc
         включить функции / profiling / profiling.scc

         # Запрошенные драйверы, у которых нет существующего scc
         kconf оборудование minnow-drivers-extra.cfg
                 

включает команду в середине файла
включает описание minnow.scc , которое
определяет все включенное оборудование для BSP, которое является общим для
все типы ядер.Использование этой команды значительно сокращает дублирование.

Теперь рассмотрим описание "крошечного" ядра "гольян".
введите (например, minnow-tiny.scc ):

        определить KMACHINE minnow
        определить KTYPE tiny
        определить KARCH i386

        включить ktypes / tiny

        включить minnow.scc
                 

Как и следовало ожидать, "крошечное" описание включает в себя довольно
немного меньше.Фактически, он включает только минимальную политику, определенную
"крошечный" тип ядра и аппаратная конфигурация
требуется для загрузки машины вместе с самыми основными
функциональность системы, определенная в базовом "гольяне"
файл описания.

Еще раз обратите внимание на три критические переменные:
МАШИНА ,
К ТИП ,
а также
КАРЧ .Из этих переменных только KTYPE
изменился, чтобы указать тип ядра "крошечный".

3.4. Расположение метаданных ядра¶

Метаданные ядра всегда существуют вне дерева ядра.
определены в рецепте ядра (recipe-space) или вне рецепта.
То, где вы выберете определение метаданных, зависит от того, что вы хотите
что делать и как вы собираетесь работать.
Независимо от того, где вы определяете метаданные ядра, используемый синтаксис
применяется в равной степени.

Если вы не знакомы с ядром Linux и только желаете
применить конфигурацию и, возможно, пару исправлений, предоставленных
другие рекомендуют метод "рецепт-пространство".
Этот метод также подходит, если вы работаете с ядром Linux.
источники, которые вы не контролируете, или если вы просто не хотите поддерживать
Репозиторий Git ядра Linux самостоятельно.
Для частичной информации о том, как вы можете определить метаданные ядра в
рецепт-пространство, см.
«Изменение существующего рецепта»
раздел.

И наоборот, если вы активно разрабатываете ядро ​​и уже
поддерживая собственный репозиторий Git ядра Linux, вы можете найти
удобнее работать с метаданными ядра, хранящимися вне
рецепт-космос.
Работа с метаданными в этой области может сделать итеративную разработку
ядро Linux более эффективно вне среды BitBake.

3.4.1. Метаданные пространства рецептов¶

При хранении в пространстве рецептов файлы метаданных ядра находятся в
иерархия каталогов ниже
ЭКСТРАПАТЫ ФАЙЛОВ .Для рецепта linux-yocto или для рецепта ядра Linux, полученного
путем копирования и изменения
oe-core / мета-скелет / recipes-kernel / linux / linux-yocto-custom.bb
к рецепту в вашем слое, FILESEXTRAPATHS
обычно устанавливается на
$ { THISDIR } / $ { PN } .
См. «Изменение существующего рецепта»
раздел для получения дополнительной информации.

Вот пример, который показывает тривиальное дерево метаданных ядра.
хранится в пространстве рецептов в слое BSP:

     meta-   my_bsp_layer   /
     `- рецепты-ядро
         `- Linux
             `- linux-yocto
                 | - bsp-стандарт.scc
                 | - bsp.cfg
                 `- standard.cfg
             

Когда метаданные хранятся в пространстве рецептов, вы должны взять
шаги, чтобы убедиться, что BitBake имеет необходимую информацию для принятия решения
какие файлы загружать и когда их нужно получить снова.
Необходимо только указать .scc
файлы на
SRC_URI .
BitBake анализирует их и выбирает все файлы, указанные в
.scc файлы включают ,
patch или kconf команд.
Из-за этого рецепт необходимо натолкнуть
PR
значение при изменении содержимого файлов, не указанных явно
в SRC_URI .

Если описание BSP находится в области рецептов, вы не можете просто перечислить
* .scc в SRC_URI
заявление.Вам необходимо использовать следующую форму из файла добавления ядра:

     SRC_URI_append_   myplatform   = "\
        file: //   myplatform  ; type = kmeta; destsuffix =   myplatform   \
        "
             

3.4.2. Метаданные за пределами области рецептов

.