What is make menuconfig in linux

Итак, как скомпилировать драйвер прямо в ядро?

Какую адаптацию ядра мы часто слышим во время фактического процесса конфигурации трансплантации ядра?

Когда мы настраиваем ядро ​​Linux, мы часто выполняем команду make menuconfig, после чего на экране появляется следующий интерфейс:

Как создается этот интерфейс?

О какой связи между конфигурацией ядра и компиляцией мы часто говорим?

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

Система конфигурации ядра Linux состоит из трех частей, а именно:

1. Makefile: Распространяется в корневом каталоге исходного кода ядра Linux и в каталогах различных уровней, определяя правила компиляции ядра Linux;

2. Файл конфигурации (config.in (ядро 2.4, ядро ​​2.6)): Предоставляет пользователям возможность выбора конфигурации;

3. Инструменты конфигурации: включая интерпретатор команд конфигурации (интерпретирует команды конфигурации, используемые в сценарии конфигурации) и пользовательский интерфейс конфигурации (обеспечивает символьный интерфейс, графический интерфейс на основе Ncurses и интерфейс конфигурации пользователя с графическим интерфейсом на основе Xwindows, каждый из которых соответствует Make config, сделайте menuconfig и сделайте xconfig).

Эти инструменты конфигурации написаны на языках сценариев, таких как Tcl / TK и Perl (и некоторые коды, написанные на C, также включены). В этой статье не анализируется сама система конфигурации, а рассказывается, как ее использовать. Поэтому, если вы не являетесь сопровождающим системы конфигурации, обычным разработчикам ядра не нужно понимать их принципы, а нужно только знать, как писать Makefile и файлы конфигурации.

Два, объяснение процесса makefile menuconfig

Когда мы выполняем команду make menuconfig, что именно делает для нас система?

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

Папка сценариев в корневом каталоге ядра Linux

файл arch / $ ARCH / Kconfig, файлы Kconfig на каждом уровне каталога

Файлы Makefile в корневом каталоге ядра Linux, файлы Makefile на каждом уровне каталога

Файл .config в корневом каталоге ядра Linux, файл конфигурации в arm / $ ARCH /

Файл include / generated / autoconf.h в корневом каталоге ядра Linux

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

2) Когда мы выполняем команду make menuconfig и появляется показанный выше синий интерфейс конфигурации, система помогает нам сделать следующее:

Сначала система прочитает файл Kconfig в каталоге arch / $ ARCH /, чтобы сгенерировать все параметры интерфейса конфигурации (Kconfig является ядром всего механизма конфигурации Linux), а затем каково значение переменной среды ARCH?

Это определяется файлом makefile в корневом каталоге ядра Linux. В make-файле есть определение этой переменной среды:

Или с помощью команды make ARCH = arm menuconfig для создания интерфейса конфигурации, По умолчанию сгенерированный интерфейс состоит в том, что все параметры не имеют значения.

Например, Управление по академическим вопросам проводит экзамены. В число экзаменационных предметов могут входить иностранный язык, китайский язык, математика и другие предметы. Это эквивалентно выбору руки для сдачи экзамена. Система прочитает файл arm / arm / kconfig, чтобы сгенерировать параметры конфигурации (выберите документ раздела arm), а также система предоставит экзаменационные вопросы для более чем 10 домашних заданий, таких как раздел x86 и раздел milps.

3) Предполагая, что Офис по академическим вопросам более «добрый», чтобы опасаться, что некоторые студенты будут отвечать на хорошие тестовые вопросы, мы также подготовили для нас справочный ответ (вариант конфигурации по умолчанию), который хранится в arch / $ ARCH / configs, который предназначен для руки Папка arch / arm / configs:

В этой папке много вариантов, какую из них прочитает система? По умолчанию ядро ​​будет читать файл .config в корневом каталоге ядра Linux как параметр ядра по умолчанию (справочный ответ на тестовый вопрос). Обычно мы выбираем серию, которая наиболее близка к нашей плате разработки в соответствии с типом платы разработки для корневого каталога ядра Linux. (Выберите наиболее близкий справочный ответ)

#cp arch/arm/configs/s3c2410_defconfig .config

4).config

Предполагая, что Управление по академическим вопросам оставило свой разум, предоставленный им справочный ответ не совсем правильный (файл .config не совсем соответствует нашей плате), тогда мы можем напрямую изменить файл .config и выполнить команду make menuconfig, чтобы прочитать новый. Параметры

Но обычно мы не принимаем это решение. Мы выбираем определенные параметры через пробел, esc и вводим в интерфейс конфигурации, чтобы выбрать или отменить выбор. При окончательном сохранении и выходе ядро ​​Linux обновит новые параметры (правильные справочные ответы) В .config мы можем переименовать .config в другие файлы и сохранить его (система удалит файл .config, когда вы выполните make distclean), и нам не нужно переходить в arch / arm / при настройке ядра в будущем. Соответствующие файлы получаются под конфигами, что избавляет от необходимости реконфигурировать, просто скопируйте сохраненный файл .config как .config.

5) После двух вышеуказанных шагов мы можем правильно читать и настраивать нужный нам интерфейс.

Итак, как они устанавливают отношения компиляции с make-файлом?

Когда вы сохраняете опцию make menuconfig, система не только автоматически обновит .config, но и сохранит все опции в виде макроса.

В файле include / generated / autoconf.h в корневом каталоге ядра Linux

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

Когда нам нужно выбрать, компилировать ли файл целиком, нам также необходимо изменить соответствующий make-файл, например:

Когда мы выбираем, компилировать ли файл s3c2410_ts.c, make-файл решает, компилировать ли этот файл в соответствии с CONFIG_TOUCHSCREEN_S3C2410. Этот макрос определен в файле Kconfig. После того, как мы его настроили, он появится в .config и autconf. Пока что мы Процесс компиляции всего ядра Linux завершен.

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

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

Первое, что нужно сделать: Измените файл Kconfig в соответствующем каталоге и добавьте соответствующие параметры в соответствии с синтаксисом Kconfig;

Выполните make menuconfig рядом с выбором: компилировать в ядро ​​или не компилировать в ядро, или компилировать в модуль, файлы .config и autoconf.h будут созданы автоматически;

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

Выполните команду make zImage в конце компиляции.

Три конкретных примера

Давайте возьмем эксперимент с модулем, который мы провели ранее, в качестве примера, чтобы объяснить, как скомпилировать отдельно скомпилированный модуль в ядро ​​или в модуль с помощью механизма make menuconfig.

Допустим, у меня уже есть такой драйвер:

Источник

Buildroot — часть 1. Общие сведения, сборка минимальной системы, настройка через меню

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

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

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

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

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Где взять и как начать

Сайт проекта — buildroot.org. Здесь можно скачать актуальную версию и прочитать руководство. Там же можно обратиться к сообществу, есть багтрекер, mail-lists и irc-канал.

Buildroot оперирует defconfig’aми для целевой платы сборки. Defconfig — это конфигурационный файл, хранящий в себе только опции, не имеющими значения по умолчанию. Именно он определяет, что и как будет собрано. При этом можно отдельно настроить конфиги busybox, linux-kernel, uClibc, загрузчиков u-boot и barebox, но все они будут привязаны к целевой плате.
После распаковки скачанного архива или клонировании из git получаем готовый к работе buildroot. Подробно о структуре каталогов можно прочитать в руководстве, расскажу о самых важных:

board — каталог с файлами, специфичными для каждой платы. Это могут быть скрипты формирования образов системы(iso, sdcart, cpio и прочие), каталог overlay, конфиг ядер и прочее
configs — собственно defconfig платы. Defconfig — это неполная конфигурация платы. В нем хранится только отличные от дефолтных настроек параметры
dl — каталог со скачанными исходными кодами/файлами для сборки
output/target — собранная файловая система полученной ОС. В дальнейшем из нее создаются образы для загрузки/установки
output/host — host-утилиты для сборки
output/build — собранные пакеты

Конфигурирование сборки осуществляется через KConfig. Эта же система используется для сборки ядра linux. Список самых часто используемых команд (выполнять в каталоге buildroot):

• make menuconfig — вызвать настройку сборки. Так же можно с использование графического интерфейса (make nconfig,make xconfig,make gconfig)
• make linux-menuconfig — вызвать конфигурацию ядра.
• make clean — очистить результаты сборки (всё что храниться в output)
• make — собрать систему. При этом не выполняется пересборка уже собранных процессов
• make defconfig_name — переключить конфигурацию на определенный defconfig
• make list-defconfigs — показать список defconfig’ов
• make source — только скачать установочный файлы, без сборки.
• make help — вывести список возможных команд

Важные замечания и полезные советы

Buildroot не пересобирает уже собранные пакеты! Поэтому может создаться ситуация, когда потребуется полная пересборка.

Можно пересобрать отдельный пакет командой make packagename-rebuild. Например, можно пересобрать ядро linux:

Buildroot хранит состояние любого пакета созданием .stamp-файлов в каталоге output/build/$packagename:

Следовательно, можно пересобрать root-fs и образы без пересборки пакетов:

Полезные переменные

В buildroot есть набор переменных для удобного конфигурирования

• $TOPDIR — корневой каталог buildroot
• $BASEDIR — каталог OUTPUT
• $HOST_DIR, $STAGING_DIR, $TARGET_DIR — каталоги сборки host fs, staging fs, target fs.
• $BUILD_DIR — каталог c распакованными и собранными пакетами

Визуализация

В buildroot есть возможность по визуализации.Можно построить схему зависимостей, график времени сборки, график размера пакетов в итоговой системе. Результаты в виде pdf файлов( на выбор есть svn,png) в каталоге output/graph.

Примеры команд визуализации:

• make graph-depends построить дерево зависимостей
• make

-graph-depends построить дерево зависимостей конкретного пакета

Полезные скрипты

В каталоге buildroot есть подкаталог utils c полезными скриптами. Например, там есть скрипт, проверяющий корректность описания пакетов. Это может быть полезно при добавлении своих пакетов (я это сделаю позже). В файле utils/readme.txt есть описание этих скриптов.

Соберем cтоковый дистрибутив

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

Смотрим список конфигураций:

Переключаемся на конфиг qemu_x86_64_defconfig

И запускаем сборку

Сборка завершается успешно, смотрим на результаты:

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

Результат — запущенная в qemu система:

Создание конфигурации собственной платы

Добавление файлов платы

Смотрим список конфигураций:

В списке видим pc_x86_64_bios_defconfig. Мы создадим свою плату, скопировав её с конфигурации:

Сразу же создадим каталог платы для хранения своих скриптов, rootfs-overlay и прочих нужных файлов:

Переключаемся на этот defconfig:

Таким образом, теперь конфиг сборки (хранится в .config в корне каталога buildroot’а) соответствует целевой машине x86-64 legacy(bios) загрузкой.

Скопируем конфигурацию linux-kernel (пригодится в дальнейшем):

Настройка параметров сборки через KConfig

Откроется окно KConfig. Есть возможность конфигурировать с графическим интерфейсом (make nconfig, make xconfig, make gconfig):

Входим в первый раздел Target Options. Здесь можно выбрать целевую архитектуру, под которую будет вестись сборка.

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

Toolchain – здесь настраивается сам инструментарий сборки. О нем подробнее.

Toolchain type – тип используемого тулчейна. Это может быть встроенный в buildroot или внешний тулчейн (можно указать каталог с уже собранным или url для скачивания). Для разных архитектур есть дополнительные опции. Например, для arm можно просто выбрать версию внешнего тулчейна Linaro.

C library – выбор библиотеки С. От этого зависит работа всей системы. Обычно используется glibc, поддерживающая весь возможный функционал. Но она может оказаться слишком большой для встроенной системы, поэтому часто выбирают uClibc или musl. Мы выберем glibc (в дальнейшем это потребуется для использования systemd).

Kernel Headers и Custom Kernel Headers series – должно совпадать с версией ядра, которое будет в собираемой системе. Для kernel headers можно так же указать путь к тарболу или git-репозиторий.

GCC COMPILER VERSIONS – выбор версии компилятора, которая будет использована для сборки
Enable C++ support – выберем для сборки с поддержкой библиотек c++ в системе. В дальнейшем нам это пригодится.

Additional gcc options – можно задать дополнительные опции компилятора. Нам без надобности пока что.

System configuration позволяет задать будущие параметры созданной системы:

Большинство пунктов понятны из названия. Обратим внимание на следующие пункты:
Path to the users tables — таблица с создаваемыми пользователями (https://buildroot.org/downloads/manual/manual.html#makeuser-syntax).

Пример файла. Будет создан пользователь user с паролем admin, автоматически gid/uid, /bin/sh шеллом, группой по-умолчанию user, член группы root, комментарием Foo user

Root filesystem overlay directories — каталог, накладываемый поверх собранной target-fs. Добавляет новые файлы и заменяет имеющиеся.

Custom scripts to run before creating filesystem images — Скрипты, выполняемые непосредственно перед сворачиванием файловой системы в образы. Сам скрипт пока оставим пустым

Перейдём в раздел Kernel

Здесь задаются настройки ядра. Само ядро конфигурируется через make linux-menuconfig.
Задать версию ядра можно по-разному: выбрать из предложенных, ввести версию вручную, указать репозиторий или готовый tarball.

Kernel configuration — путь к конфигу ядра. Можно выбрать конфигурацию по-умолчанию для выбранной архитектуры или defocnfig из Linux. В исходниках Linux есть набор defconfig’ов для разных целевых систем. НАйти нужный можно, глянув напрямую в исходники здесь. Например, для платы beagle bone black можно выбрать конфиг.

Раздел Target packages позволяет выбрать, какие пакеты будут установлены в собираемую систему. Пока оставим без изменений. Позже мы добавим свои пакеты в этот список.
Filesystem images — список образов файловых систем, которые будут собраны. Добавим iso-образ

Bootloaders — выбор собираемых загрузчиков. Выберем isolinix

Конфигурирование Systemd

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

Настраивается через make menuconfig, далее Target packages → System tools → systemd. Здесь можно указать, какие службы systemd будут установлены и запущены при старте системы.

Сохранение конфигурации системы

Сохраняем этот конфиг через KConfig.

После чего сохраним наш defconfig:

Конфигурирование ядра Linux

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

Добавим поддержку видеокарты Virtualbox

Добавим Virtualbox Guest integration support

Сохраняем и выходим. ВАЖНО: конфигурация сохранится в output/build/linux-$version/config, но не в board/my_x86_board/linux.config

Поэтому нужно вручную скопировать конфиг в место хранения:

Этой командой я копирую ПОЛНЫЙ конфиг ядра, что нужно не всегда. Более правильный путь — сохранять defconfig ядра:

После чего выполним полную пересборку всей системы.Т.к. buildroot не пересобирает уже собранное, то надо вручную указать пакеты для пересборки. Чтобы не терять время и нервы, небольшую систему проще пересобрать целиком):

По завершении сборки запускаем VirtualBox(проверялось на версии 5.2 и 6.0) с загрузкой с cd-диска.Параметры системы:

Источник

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —