В минимальном bare-metal проекте без HAL и без CubeMX вся эта цепочка видна почти по шагам. Именно поэтому такой проект хорошо подходит для первого глубокого знакомства со STM32: становится понятно, что происходит в памяти, как работает линкер, зачем нужен startup и почему обычный C-код не может стартовать “сам по себе”.

В этой статье собирается минимальный проект с нуля:

• собственный linker script;

• startup-файл;

• ручная инициализация .data и .bss;

• настройка GPIO;

• управление встроенным светодиодом на PC13;

• запуск аппаратного таймера TIM2.

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

Что получится в итоге

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

1. включать светодиод на PC13;

2. ждать 1 секунду;

3. выключать светодиод;

4. снова ждать 1 секунду.

Структура проекта

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

full_program_from_scratch/
├── inc/
│   ├── config.h
│   ├── GPIO.h
│   ├── LED.h
│   ├── main.h
│   └── Timers.h
├── src/
│   ├── config.c
│   ├── GPIO.c
│   ├── LED.c
│   ├── main.c
│   └── Timers.c
├── startup/
│   └── startup.c
├── myLinker.ld
├── firmware.elf
└── firmware.bin

Базовая идея bare-metal подхода

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

*(volatile uint32_t*)0x40021018 |= (1 << 4);

Разберём эту строку по частям.

volatile

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

uint32_t

Регистр STM32F1 обычно имеет ширину 32 бита, поэтому используется именно uint32_t.

0x40021018

Это адрес регистра RCC_APB2ENR. Через него включается тактирование периферии на шине APB2.

(1 « 4)

Бит 4 соответствует порту GPIOC. Пока этот бит не установлен, периферия GPIOC формально существует в адресном пространстве, но не получает clock и не работает.

Такой способ записи выглядит грубовато, зато он очень хорошо показывает сам принцип: код не вызывает “магическую функцию библиотеки”, а меняет конкретный бит в конкретном регистре микроконтроллера.

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

Linker script: карта памяти проекта

Linker script объясняет линкеру, где в памяти микроконтроллера должны лежать разные части программы. Именно он связывает логические секции .text, .data, .bss, .isr_vector с физической памятью STM32.

У linker script в этом проекте четыре основных задачи:

• описать области памяти;

• разложить секции программы по этим областям;

• создать служебные символы для startup-кода;

• обеспечить правильный старт программы после сброса.

  Предлагаю взглянуть на линкер файл:

_estack = = ORIGIN(RAM) + LENGTH(RAM);

MEMORY{
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 0x00010000
    RAM   (rwx): ORIGIN = 0x20000000, LENGTH = 0x00005000
}

SECTIONS{
    .isr_vector :
    {
        KEEP(*(.isr_vector))
    } > FLASH

    .text :
    {
        *(.text)
        *(.text*)
    } > FLASH

    .rodata :
    {
        *(.rodata)
        *(.rodata*)
    } > FLASH

    .data :
    {
        _sdata = .;  //Точный адрес в RAM
        *(.data)
        *(.data*)
        _edata = .;
    } > RAM AT > FLASH

    _sidata = LOADADDR(.data); //Точный адрес во FLASH памяти

    .bss :
    {
        _sbss = .;
        *(.bss)
        *(.bss*)
        _ebss = .;
    } > RAM
}

Области памяти

Для STM32F103C8T6 используются две основные области:

В ссылке на стек используется символ:

_estack = ORIGIN(RAM) + LENGTH(RAM);

Он указывает на вершину RAM и становится первым элементом векторной таблицы. Именно это значение Cortex-M3 загружает в регистр SP при старте.

Секции

.isr_vector

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

.text

Секция исполняемого кода. Обычно она хранится во FLASH.

.rodata

Константные данные. Тоже размещаются во FLASH.

.data

Инициализированные переменные. После старта они должны находиться в RAM, но их начальные значения хранятся во FLASH, поэтому эта секция размещается как > RAM AT > FLASH.

.bss

Неинициализированные переменные. На старте они зануляются вручную.

Зачем нужны sidata, sdata, edata, sbss, _ebss

Эти символы создаёт линкер, а затем использует startup-код.

• _sidata — адрес исходных данных во FLASH;

• _sdata — начало .data в RAM;

• _edata — конец .data в RAM;

• _sbss — начало .bss;

• _ebss — конец .bss.

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

И теперь очень простым языком

*(.data) : Это поиск секций с точным именем .data. Сюда попадают обычные инициализированные глобальные переменные.

*(.data*) : Звездочка в конце означает «любое продолжение».

Представьте, что у вас есть два файла: main.c и sensor.c. Компилятор делает из них main.o и sensor.o. В каждом из них есть своя маленькая коробочка с надписью .data. Линковщик видит вашу инструкцию *(.data). Он идет в main.o, забирает оттуда содержимое .data, затем идет в sensor.o, забирает данные оттуда и склеивает их в одну большую секцию .data в итоговом бинарном файле.

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

Startup-файл: что происходит сразу после сброса

Startup-код — это первый код, который выполняется после подачи питания или аппаратного сброса. До вызова main() микроконтроллер ещё не готов к обычной работе, поэтому сначала нужно подготовить память.

Линкерные символы

В startup-файле обычно объявляются внешние символы:

extern uint32_t _estack;
extern uint32_t _sidata;
extern uint32_t _sdata;
extern uint32_t _edata;
extern uint32_t _sbss;
extern uint32_t _ebss;

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

Векторная таблица

Векторная таблица — это массив адресов обработчиков. Процессор не ищет обработчик по имени. Он просто берёт адрес из нужной позиции таблицы.

В минимальном варианте достаточно описать Reset_Handler, NMI_Handler и HardFault_Handler. Остальные обработчики можно пока направить в Default_Handler.

weak alias

Конструкция **attribute**((weak, alias("Default_Handler"))) означает: если отдельный обработчик не определён, вместо него будет использоваться Default_Handler.

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

Reset_Handler

После сброса процессор выполняет Reset_Handler. В нём нужно сделать три обязательные вещи:

1. скопировать .data из FLASH в RAM;

2. занулить .bss.

3. вызывать main().

   Здесь main() и есть та самая функция, которая фигурирует во всех наших проектах.

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

Полный startup.c

#include <stdint.h>

extern uint32_t _estack;
extern uint32_t _sidata;
extern uint32_t _sdata;
extern uint32_t _edata;
extern uint32_t _sbss;
extern uint32_t _ebss;

int main(void);

void Reset_Handler(void);
void Default_Handler(void);

void NMI_Handler(void)       __attribute__((weak, alias("Default_Handler")));
void HardFault_Handler(void)  __attribute__((weak, alias("Default_Handler")));

__attribute__((used, section(".isr_vector")))
const void* vector_table[] =
{
    &_estack,
    Reset_Handler,
    NMI_Handler,
    HardFault_Handler
};

void Reset_Handler(void){
    uint32_t* src = &_sidata; // Адрес начала данных во FLASH
    uint32_t* dst = &_sdata;  // Адрес начала данных в RAM

    while (dst < &_edata){
        *dst++ = *src++;      // Копируем данные из FLASH в RAM
    }

    dst = &_sbss;

    while (dst < &_ebss){  // Адрес начала секции .bss в RAM
        *dst++ = 0;        //Зануляем неинициализированные переменные
    }

    main();

    while (1){
    }
}

void Default_Handler(void){
    while (1){
    }
}

Заголовочные файлы: интерфейсы модулей

В inc/ лежат заголовочные файлы. Их задача — описать, какие функции и структуры доступны другим частям проекта.

Такой подход помогает не смешивать реализацию и интерфейс. Один .c-файл не должен “знать лишнего” о внутренностях другого .c-файла, если достаточно просто увидеть его прототипы.

При включении питания CPU смотрит в адрес 0x00000000, берёт оттуда указатель на стек. Далее CPU читает адрес 0x00000004 - это адрес Reset_Handler.После CPU начинает выполнять ResetHandler() и оттуда уже прыгает в main().

inc/GPIO.h

#ifndef GPIO_H
#define GPIO_H

#include <stdint.h>

void GPIO_init(void);

#endif

inc/LED.h

#ifndef LED_H
#define LED_H

#include <stdint.h>

void turnOnLED(void);
void turnOffLED(void);

#endif

inc/Timers.h

Именно здесь удобно описать структуру регистра таймера.

#ifndef TIMERS_H
#define TIMERS_H

#include <stdint.h>

void TIMERS_init(void);
void delayOneSecond(void);

typedef struct
{
    volatile uint32_t CR1;   // 0x00
    volatile uint32_t CR2;   // 0x04
    volatile uint32_t SMCR;  // 0x08
    volatile uint32_t DIER;  // 0x0C
    volatile uint32_t SR;    // 0x10
    volatile uint32_t EGR;   // 0x14
    volatile uint32_t CCMR1; // 0x18
    volatile uint32_t CCMR2; // 0x1C
    volatile uint32_t CCER;  // 0x20
    volatile uint32_t CNT;   // 0x24
    volatile uint32_t PSC;   // 0x28
    volatile uint32_t ARR;   // 0x2C
    volatile uint32_t RCR;   // 0x30
    volatile uint32_t CCR1;  // 0x34
    volatile uint32_t CCR2;  // 0x38
    volatile uint32_t CCR3;  // 0x3C
    volatile uint32_t CCR4;  // 0x40
    volatile uint32_t BDTR;  // 0x44
    volatile uint32_t DCR;   // 0x48
    volatile uint32_t DMAR;  // 0x4C
} TIM_TypeDef;

#define TIM2 ((TIM_TypeDef*)0x40000000)

#endif

Здесь TIM2 — это не “обычный объект” C, а типизированный доступ к блоку регистров по фиксированному адресу. В итоге запись вида TIM2->PSC = 7999; становится простой и читаемой.

inc/config.h

#ifndef CONFIG_H
#define CONFIG_H

#include "GPIO.h"
#include "Timers.h"

void MCU_init(void);

#endif

inc/main.h

#ifndef MAIN_H
#define MAIN_H

#include "config.h"
#include "LED.h"

#endif

Единая точка инициализации: MCU_init()

Когда проект растёт, удобно собрать все базовые настройки в одну функцию. В этом проекте такой точкой входа становится MCU_init().

#include "config.h"

void MCU_init(void)
{
    GPIO_init();
    TIMERS_init();
}

Такой подход делает main() короче и понятнее: в нём остаётся только прикладная логика, а детали инициализации уходят в отдельные модули.

Настройка GPIOC и ножки PC13

Теперь можно перейти к периферии. Первая задача — включить тактирование порта GPIOC и настроить вывод PC13.

Включение clock для GPIOC

Регистр RCC_APB2ENR находится по адресу 0x40021018. Бит 4 включает тактирование GPIOC.

Если этот бит не установить, регистры порта останутся доступны по адресу, но сама периферия не начнёт работать.

Настройка режима PC13

Регистр GPIOC_CRH находится по адресу 0x40011004. Он отвечает за ножки с 8-й по 15-ю.

Для PC13 используются биты [23:20]. Сначала они очищаются, затем записывается комбинация:

• MODE = 10 — выход 2 МГц;

• CNF = 00 — обычный push-pull output.

Полный GPIO.c

#include "GPIO.h"

void GPIO_init(void)
{
    //Бит 4-й регистра RCC_APB2ENR устанавливается в единицу
    *(volatile uint32_t*)0x40021018 |= (1 << 4);

    //Очищение битов [23:20] регистра GPIOC_CRH
    *(volatile uint32_t*)0x40011004 &= ~(0b1111 << 20);  

    //Запись битов [23:20] регистра   GPIOC_CRH
    *(volatile uint32_t*)0x40011004 |=  (0b0010 << 20);  
}

Управление светодиодом

На многих платах с STM32F103C8T6 встроенный светодиод на PC13 подключён по схеме active-low.

Это означает:

• чтобы включить светодиод, нужно записать 0;

• чтобы выключить — 1.

Из-за этого логика включения и выключения выглядит немного “наоборот”, но для платы это совершенно нормально.

Полный LED.c

#include "LED.h"

void turnOnLED(void)
{
    *(volatile uint32_t*)0x4001100C &= ~(1 << 13);
}

void turnOffLED(void)
{
    *(volatile uint32_t*)0x4001100C |= (1 << 13);
}

Адрес 0x4001100C — это GPIOC_ODR, то есть регистр данных выхода.

Таймер TIM2

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

Основные сокращения

Частота таймера

После сброса STM32F103 обычно использует внутренний генератор HSI на 8 МГц.

Если отдельная настройка clock tree не выполняется, можно считать, что:

• HCLK = 8 MHz;

• PCLK1 = 8 MHz;

• TIM2CLK = 8 MHz.

Формирование задержки 1 секунда

В проекте используются параметры:

TIM2->PSC = 7999;
TIM2->ARR = 999;

Формула работы таймера:

f_counter = f_tim / (PSC + 1)

Подставляем значения:

f_counter = 8 000 000 / (7999 + 1) = 1000 Hz

Это значит, что один тик счётчика длится 1 миллисекунду.

Дальше ARR = 999 даёт 1000 тиков, то есть ровно 1 секунду.

Важная деталь: включение clock для TIM2

Чтобы таймер реально начал считать, нужно включить его тактирование через RCC_APB1ENR, бит TIM2EN.

Адрес регистра: 0x4002101C

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

Бит TIM2->SR становится единицей после каждого переполнения таймера. Следовательно, выставлять его в ноль перед запуском таймера - стандартная практика.

Полный Timers.c

#include "Timers.h"

static void TIM2_init(void);

void TIMERS_init(void)
{
    TIM2_init();
}

static void TIM2_init(void)
{
    //Ставим единичку в регистр RCC_APB1ENR в бит TIM2EN
    *(volatile uint32_t*)0x4002101C |= (1 << 0);

    TIM2->SR  &= ~(1 << 0);
    TIM2->PSC  = 7999;
    TIM2->ARR  = 999;
    TIM2->CR1 |= (1 << 0);
}

void delayOneSecond(void)
{
    //Как только TIM2->SR бит UIF = 1, значит прошла 1 секунда
    while ((TIM2->SR & (1 << 0)) == 0){}

    //Сбрасываем Status Register, чтобы продолжить фиксировать переполнения
    TIM2->SR &= ~(1 << 0); 
}

Как работает delayOneSecond()

Функция построена на опросе флага UIF.

Сначала код ждёт, пока бит UIF в SR не станет равен 1. После этого флаг сбрасывается, и функция завершается.

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

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

Основной файл main.c

Когда инициализация уже вынесена в отдельные модули, main() остаётся очень короткой. И это хороший признак: прикладная логика читается сразу, без лишнего шума.

#include "main.h"

int main(void){
    MCU_init();

    while (1){
        turnOnLED();
        delayOneSecond();

        turnOffLED();
        delayOneSecond();
    }
}

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

Как получается firmware.elf и firmware.bin

На этапе сборки исходники превращаются сначала в ELF-файл, а затем в плоский бинарный образ.

firmware.elf

ELF (Executable and Linkable Format) содержит не только машинный код, но и информацию о секциях, символах и отладочных данных.

firmware.bin

BIN — это уже чистый бинарный образ без служебной структуры. Именно его обычно прошивают во FLASH микроконтроллера.

Пример сборки

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -nostdlib -Iinc \
-T myLinker.ld startup/startup.c src/main.c src/config.c src/GPIO.c \
src/LED.c src/Timers.c -o firmware.elf

arm-none-eabi-objcopy -O binary firmware.elf firmware.bin

Сначала линкер собирает все объекты в firmware.elf, учитывая startup.c и myLinker.ld. Затем objcopy извлекает из ELF только полезный бинарный образ.

Словарь аббревиатур

Полные исходники проекта

Все исходники проекта можете посмотреть на GitHub: https://github.com/dimchickka/codeForSTM32_fromScrath

Итог

Этот проект полезен тем, что в нём видно весь путь старта микроконтроллера: от векторной таблицы и linker script до первой реальной работы GPIO и таймера. Такой разбор хорошо помогает не просто “собрать пример”, а понять, почему микроконтроллер вообще начинает выполнять программу и как именно он доходит до main().

• h move cursor to the left
• j move down
• k move up
• l move right
• i Go into Insert mode
• <ESC><C-C><C-[> Go back to Normal mode

Move Fast Word by Word

• w move to the beginning of next word
• b move to the beginning of the previous word
• e move to the end of the next word

• ge move to the end of the previous word

• W move to the beginning of next WORD
• B move to the beginning of the previous WORD
• E move to the end of the next WORD
• gE move to the end of the previous WORD

Find Character

• f{character} Find next occurrence of character

• F{character} Find previous occurrence of character

• t{character} Find next occurrence of character and place cursor just before it

• T{character} Find previous occurrence of character and place cursor just before it

• ; Go to next occurrence of {character}
• , Go to previous occurrence of {character}

Move Extremely Horizontally

• 0 Moves to the first character of a line
• ^ Moves to the first non-blank character of a line
• $ Moves to the end of a line
• g_ Moves to the non-blank character at the end of a line

Move Faster Vertically

• } Jumps entire paragraphs downwards
• { similarly but upwards
• CTRL-D lets you move down half a page by scrolling the page
• CTRL-U lets you move up half a page also by scrolling

High Precision Vertical Motions with Search

• /{pattern} Search for {pattern}. {pattern} is a regex.

• ?{pattern} Search for {pattern} backwards.

• / Repeat last search forwards

• ? Repeat last search backwards

• n Go to next match
• N Go to previous match

Move Faster with Counts

• {count}{motion} Repeat {motion} {count} times

• 2w Jump to second word
• 4f" Jump to fourth occurrence of the “ character
• 3/cucumber Jump to third match of “cucumber”

Move Semantically

• gd Go to definition (of the word under the cursor)
• gf Go to file (for file under the cursor)

More Nifty Core Motions

• gg Go to the top of the file
• {line}gg Go to {line}
• G Go to the end of the file
• % jump to matching ({[]})

Edit Like Magic With Vim Operators

• {operator}{count}{motion} Apply operator on bit of text covered by motion

• d delete
• c change
• y yank (copy)
• p p (paste)
• g~ switch case
• > shift right
• < shift left
• = format

Linewise Operators

• dd delete a line
• cc change a line
• yy yank (copy) a line
• g~~ switch case of a line
• >> shift line right
• << shift lineleft
• == format line

Capital case (Stronger version) Operators

• D delete from cursor to the end of the line
• C change from cursor to the end of the line
• Y yank (copy) a line. Like yy
• P put (paste) before the cursor

Text objects

• {operator}a{text-object} Apply operator to all text-object including trailing whitespace

• {operator}i{text-object} Apply operator inside text-object

• diw delete inner word
• daw delete a word
• dis delete inner sentence
• das delete a sentence
• dip delete inner paragraph
• dap delete a paragraph
• di(dib delete inside parentheses
• da(dab delete text inside parentheses (including parentheses)
• di{diB delete inside braces
• da{daB delete text inside braces (including braces)
• di[ delete inside brackets
• da[ delete text inside brackets (including brackets)
• di" delete inside quotes
• da" delete a quoted text (including quotes)
• dit delete inside tag

• dat delete a tag (including tag)

• ciw same goes for other operators…

Repeat Last Change

• . Repeat the last change

Character Editing Commands

• x delete a character. Like dl
• X delete character before the cursor. Like dh
• s change a character. Like cl
• ~ switch case of a character

Undo and redo

• u undo last change
• C-R redo last undo
• {count}u undo last {count} changes

Inserting Text

• i go into insert mode before the cursor

• a go into insert mode after the cursor

• I go into insert mode at the beginning of a line

• A go into insert mode at the end of a line

• o insert new line below current line and go into insert mode

• O insert new line above current line and go into insert mode

• gi go to the last place you left insert mode

• C-H delete last character
• C-W delete last word
• C-U delete last line

Visual Mode

• v go into character-wise visual mode
• V go into line-wise visual mode

• C-V go into block-wise visual mode (to select rectangular blocks of text)

• {trigger visual mode}{motion}{operator} Visual mode operates in kind of the opposite way to normal mode. First you specify the motion to select text, and then you apply the operator

Operate on Next Search Match

• {operator}gn Apply operator on next match

• . After using {op}gn, the dot commant repeats the last change on the next match. Woooot!

Copying and pasting

• y{motion} yank (copy) text covered by motion
• p put (paste) after cursor

• P paste before cursor

• yy copy line

• Y copy line

• yyp duplicate line
• ddp swap lines

• xp swap characters

• "ay{motion} copy to register a
• "Ay{motion} copy and append to register a

• "ap paste from register a

• " unnamed register
• 0 yank register
• 1-9 delete registers

• [a-z] named registers

• C-R a paste from register a when in Insert mode

Command-line mode

• :edit {file}:e {file} create or edit file
• :write:w save file
• :quit:q close file
• :write!:w! force save file
• :quit!:q! close file without saving
• :wq save and close file
• :wall:wa save all files
• :qall:qa close all files
• :wqall:wqa save and close all files

• :qall!:qa! close all files without saving

• :[range]delete [register]:[r]d [r] delete multiple lines into register

• @: repeat last ex command
• @@ after repeating it once, you can continue repeating with this

Command-line mode Ranges

• :{start},{end} start and end lines of range e.g. :1,2d
• :{start},{offset} start and offset lines of range e.g. :1,+2d
• . current line e.g. :.,+2d
• % whole file e.g. :%d
• 0 beginning of file e.g. :0,10d
• $ end of file e.g. :10,$d
• :'<,'> visual selection

Command-line mode Substitute

• :[range]/{pattern}/{substitute}/[flags] substitute matched pattern for string literal in given range

• g flag substitute all matches in a line
• i flag case insensitive search
• c flag confirm substitution for each match

Split Windows

• :sp {file} Open file in a horizontal split

• :vsp {file} Open file in a vertical split

• C-W S Open same file in a horizontal split

• C-W V Open same file in a vertical split

• C-W h Move to split to the left
• C-W j Move to split below
• C-W k Move to split above
• C-W l Move to split to the right

Tabs

• :tabnew {file} Open file in new tab
• :tabnext:tabn Jump to next tab
• :tabprev:tabp Jump to previous tab
• :tabonly:tabo Close all other tabs

Vim surround

• ds delete surroundings e.g. ds”
• cs change surroundings e.g. cs*tem>

• ys add surroundings e.g. ysiw”

• ds" delete surrounding quotes
• cs*tem> change surrounding * for the tag

• ysiw" surround word under the cursor with quotes

• S In visual mode you can select some text, then type S to add surroundings. e.g. Stp> to wrap the selection in a <p> tag

Custom mappings (they need to be added to your config)

Insert mode

• jk Go back to normal mode

Normal mode

• J Go down faster
• K Go up faster
• <leader>j Join lines
• <leader>/ Clear highlighted text

• <leader>w Save file

• <leader>p Open command palette

• <leader>t Go to symbol in file

• <C-H> Move to the window on the left
• <C-J> Move to the window below
• <C-K> Move to the window above

• <C-L> Move to the window on the right

• <leader>tt Create new tab
• <leader>tn Move to next tab
• <leader>tp Move to previous tab
• <leader>to Close all tabs but the current one

Moving Faster with Vim-sneak

• s{char}{char} Jump to the next ocurrence of {char}{char}
• S{char}{char} Jump to the previous ocurrence of {char}{char}
• ; Go to next occurrence of {char}{char}
• , Go to previous occurrence of {char}{char}
• {op}z{char}{char} Apply operator on text traversed by vim sneak motion

Moving Faster with Easymotion

• <leader><leader>w start of words
• <leader><leader>b start of words backwards
• <leader><leader>bdw start of words everywhere. The bd stands for bidirectional
• <leader><leader>e end of words
• <leader><leader>ge end of words backwards
• <leader><leader>bdw end of words everywhere
• <leader><leader>j beginning of lines
• <leader><leader>k beginning of lines backwards
• <leader><leader>f{char} find character
• <leader><leader>F{char} find character backwards
• <leader><leader>t{char} until character
• <leader><leader>T{char} until character backwards
• <leader><leader>s{char} search character everywhere

Multiple Cursors

Based on Search

• <CMD-D><C-D>gb Adds an additional cursor. This command puts you in visual mode. In effect, it selects all the words under each new cursor at once.
• {operator} Applies operator on words selected by the multiple cursors.
• I Insert before multiple words at the same time
• A Append after multiple words at the same time

In Consecutive Rows

• <C-V> Go into Visual-block mode and select text using motions
• {operator} Applies operator on visual selection.
• I Insert before visual selection
• A Append after visual selection

Reusable Editing with Macros

• q{register} Start recording a new macro in {register}
• q Stop recording macro
• @{register} Replay macro in {register}
• @@ Replay the last macro that you executed

Integrating with Neovim

• :[range]copy {address} Copy lines after {address} line
• :[range]move {address} Move lines after {address} line
• :[range]normal {commands} Apply normal mode commands on a range of lines
• :execute "{ex-command}" Execute string as an Ex command. Useful in combination with normal when the normal mode commands include special characters.
• :[range]global/{pattern}/{command} Execute an Ex command on lines within a range that match a pattern. The default range is the whole file. Really useful in combination with the normal command.
• :[range]global!/{pattern}/{command} Execute an Ex command on lines within a range that do not match a pattern.

Some Handy VSCode Only Mappings

• af Select increasingly bigger blocks of text
• gh Equivalent to hovering the mouse over a bit of text.

Bonus 01: Entire and Arguments Text Objects

• dae Delete complete buffer
• yae Yank complete buffer
• cia Change function argument
• daa Delete function argument including separator

If you mostly understand Make, consider checking out the Makefile Cookbook, which has a template for medium sized projects with ample comments about what each part of the Makefile is doing.

Good luck, and I hope you are able to slay the confusing world of Makefiles!

Getting Started

Why do Makefiles exist?

Makefiles are used to help decide which parts of a large program need to be recompiled. In the vast majority of cases, C or C++ files are compiled. Other languages typically have their own tools that serve a similar purpose as Make. Make can also be used beyond compilation too, when you need a series of instructions to run depending on what files have changed. This tutorial will focus on the C/C++ compilation use case.

Here’s an example dependency graph that you might build with Make. If any file’s dependencies changes, then the file will get recompiled:

What alternatives are there to Make?

Popular C/C++ alternative build systems are SCons, CMake, Bazel, and Ninja. Some code editors like Microsoft Visual Studio have their own built in build tools. For Java, there’s Ant, Maven, and Gradle. Other languages like Go, Rust, and TypeScript have their own build tools.

Interpreted languages like Python, Ruby, and raw Javascript don’t require an analogue to Makefiles. The goal of Makefiles is to compile whatever files need to be compiled, based on what files have changed. But when files in interpreted languages change, nothing needs to get recompiled. When the program runs, the most recent version of the file is used.

The versions and types of Make

There are a variety of implementations of Make, but most of this guide will work on whatever version you’re using. However, it’s specifically written for GNU Make, which is the standard implementation on Linux and MacOS. All the examples work for Make versions 3 and 4, which are nearly equivalent other than some esoteric differences.

Running the Examples

To run these examples, you’ll need a terminal and “make” installed. For each example, put the contents in a file called Makefile, and in that directory run the command make. Let’s start with the simplest of Makefiles:

hello:
	echo "Hello, World"

Note: Makefiles must be indented using TABs and not spaces or make will fail.

Here is the output of running the above example:

$ make
echo "Hello, World"
Hello, World

That’s it! If you’re a bit confused, here’s a video that goes through these steps, along with describing the basic structure of Makefiles.

Makefile Syntax

A Makefile consists of a set of rules. A rule generally looks like this:

targets: prerequisites
	command
	command
	command

• The targets are file names, separated by spaces. Typically, there is only one per rule.
• The commands are a series of steps typically used to make the target(s). These need to start with a tab character, not spaces.
• The prerequisites are also file names, separated by spaces. These files need to exist before the commands for the target are run. These are also called dependencies

The essence of Make

Let’s start with a hello world example:

hello:
	echo "Hello, World"
	echo "This line will print if the file hello does not exist."

There’s already a lot to take in here. Let’s break it down:

• We have one target called hello
• This target has two commands
• This target has no prerequisites

We’ll then run make hello. As long as the hello file does not exist, the commands will run. If hello does exist, no commands will run.

It’s important to realize that I’m talking about hello as both a target and a file. That’s because the two are directly tied together. Typically, when a target is run (aka when the commands of a target are run), the commands will create a file with the same name as the target. In this case, the hello target does not create the hello file.

Let’s create a more typical Makefile - one that compiles a single C file. But before we do, make a file called blah.c that has the following contents:

// blah.c
int main() { return 0; }

Then create the Makefile (called Makefile, as always):

blah:
	cc blah.c -o blah

This time, try simply running make. Since there’s no target supplied as an argument to the make command, the first target is run. In this case, there’s only one target (blah). The first time you run this, blah will be created. The second time, you’ll see make: 'blah' is up to date. That’s because the blah file already exists. But there’s a problem: if we modify blah.c and then run make, nothing gets recompiled.

We solve this by adding a prerequisite:

blah: blah.c
	cc blah.c -o blah

When we run make again, the following set of steps happens:

• The first target is selected, because the first target is the default target
• This has a prerequisite of blah.c
• Make decides if it should run the blah target. It will only run if blah doesn’t exist, or blah.c is newer than blah

This last step is critical, and is the essence of make. What it’s attempting to do is decide if the prerequisites of blah have changed since blah was last compiled. That is, if blah.c is modified, running make should recompile the file. And conversely, if blah.c has not changed, then it should not be recompiled.

To make this happen, it uses the filesystem timestamps as a proxy to determine if something has changed. This is a reasonable heuristic, because file timestamps typically will only change if the files are modified. But it’s important to realize that this isn’t always the case. You could, for example, modify a file, and then change the modified timestamp of that file to something old. If you did, Make would incorrectly guess that the file hadn’t changed and thus could be ignored.

Whew, what a mouthful. Make sure that you understand this. It’s the crux of Makefiles, and might take you a few minutes to properly understand. Play around with the above examples or watch the video above if things are still confusing.

More quick examples

The following Makefile ultimately runs all three targets. When you run make in the terminal, it will build a program called blah in a series of steps:

• Make selects the target blah, because the first target is the default target
• blah requires blah.o, so make searches for the blah.o target
• blah.o requires blah.c, so make searches for the blah.c target
• blah.c has no dependencies, so the echo command is run
• The cc -c command is then run, because all of the blah.o dependencies are finished
• The top cc command is run, because all the blah dependencies are finished
• That’s it: blah is a compiled c program

blah: blah.o
	cc blah.o -o blah # Runs third

blah.o: blah.c
	cc -c blah.c -o blah.o # Runs second

# Typically blah.c would already exist, but I want to limit any additional required files
blah.c:
	echo "int main() { return 0; }" > blah.c # Runs first

If you delete blah.c, all three targets will be rerun. If you edit it (and thus change the timestamp to newer than blah.o), the first two targets will run. If you run touch blah.o (and thus change the timestamp to newer than blah), then only the first target will run. If you change nothing, none of the targets will run. Try it out!

This next example doesn’t do anything new, but is nontheless a good additional example. It will always run both targets, because some_file depends on other_file, which is never created.

some_file: other_file
	echo "This will always run, and runs second"
	touch some_file

other_file:
	echo "This will always run, and runs first"

Make clean

clean is often used as a target that removes the output of other targets, but it is not a special word in Make. You can run make and make clean on this to create and delete some_file.

Note that clean is doing two new things here:

• It’s a target that is not first (the default), and not a prerequisite. That means it’ll never run unless you explicitly call make clean
• It’s not intended to be a filename. If you happen to have a file named clean, this target won’t run, which is not what we want. See .PHONY later in this tutorial on how to fix this

some_file:
	touch some_file

clean:
	rm -f some_file

Variables

Variables can only be strings. You’ll typically want to use :=, but = also works. See Variables Pt 2.

Here’s an example of using variables:

files := file1 file2
some_file: $(files)
	echo "Look at this variable: " $(files)
	touch some_file

file1:
	touch file1
file2:
	touch file2

clean:
	rm -f file1 file2 some_file

Single or double quotes have no meaning to Make. They are simply characters that are assigned to the variable. Quotes are useful to shell/bash, though, and you need them in commands like printf. In this example, the two commands behave the same:

a := one two# a is set to the string "one two"
b := 'one two' # Not recommended. b is set to the string "'one two'"
all:
	printf '$a'
	printf $b

Reference variables using either ${} or $()

x := dude

all:
	echo $(x)
	echo ${x}

	# Bad practice, but works
	echo $x

Targets

The all target

Making multiple targets and you want all of them to run? Make an all target. Since this is the first rule listed, it will run by default if make is called without specifying a target.

all: one two three

one:
	touch one
two:
	touch two
three:
	touch three

clean:
	rm -f one two three

Multiple targets

When there are multiple targets for a rule, the commands will be run for each target. $@ is an automatic variable that contains the target name.

all: f1.o f2.o

f1.o f2.o:
	echo $@
# Equivalent to:
# f1.o:
# 	echo f1.o
# f2.o:
# 	echo f2.o

Automatic Variables and Wildcards

* Wildcard

Both * and % are called wildcards in Make, but they mean entirely different things. * searches your filesystem for matching filenames. I suggest that you always wrap it in the wildcard function, because otherwise you may fall into a common pitfall described below.

# Print out file information about every .c file
print: $(wildcard *.c)
	ls -la  $?

* may be used in the target, prerequisites, or in the wildcard function.

Danger: * may not be directly used in a variable definitions

Danger: When * matches no files, it is left as it is (unless run in the wildcard function)

thing_wrong := *.o # Don't do this! '*' will not get expanded
thing_right := $(wildcard *.o)

all: one two three four

# Fails, because $(thing_wrong) is the string "*.o"
one: $(thing_wrong)

# Stays as *.o if there are no files that match this pattern :(
two: *.o

# Works as you would expect! In this case, it does nothing.
three: $(thing_right)

# Same as rule three
four: $(wildcard *.o)

% Wildcard

% is really useful, but is somewhat confusing because of the variety of situations it can be used in.

• When used in “matching” mode, it matches one or more characters in a string. This match is called the stem.
• When used in “replacing” mode, it takes the stem that was matched and replaces that in a string.
• % is most often used in rule definitions and in some specific functions.

See these sections on examples of it being used:

• Static Pattern Rules
• Pattern Rules
• String Substitution
• The vpath Directive

Automatic Variables

There are many automatic variables, but often only a few show up:

hey: one two
	# Outputs "hey", since this is the target name
	echo $@

	# Outputs all prerequisites newer than the target
	echo $?

	# Outputs all prerequisites
	echo $^

	# Outputs the first prerequisite
	echo $<

	touch hey

one:
	touch one

two:
	touch two

clean:
	rm -f hey one two

Fancy Rules

Implicit Rules

Make loves c compilation. And every time it expresses its love, things get confusing. Perhaps the most confusing part of Make is the magic/automatic rules that are made. Make calls these “implicit” rules. I don’t personally agree with this design decision, and I don’t recommend using them, but they’re often used and are thus useful to know. Here’s a list of implicit rules:

• Compiling a C program: n.o is made automatically from n.c with a command of the form $(CC) -c $(CPPFLAGS) $(CFLAGS) $^ -o $@
• Compiling a C++ program: n.o is made automatically from n.cc or n.cpp with a command of the form $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $^ -o $@
• Linking a single object file: n is made automatically from n.o by running the command $(CC) $(LDFLAGS) $^ $(LOADLIBES) $(LDLIBS) -o $@

The important variables used by implicit rules are:

• CC: Program for compiling C programs; default cc
• CXX: Program for compiling C++ programs; default g++
• CFLAGS: Extra flags to give to the C compiler
• CXXFLAGS: Extra flags to give to the C++ compiler
• CPPFLAGS: Extra flags to give to the C preprocessor
• LDFLAGS: Extra flags to give to compilers when they are supposed to invoke the linker

Let’s see how we can now build a C program without ever explicitly telling Make how to do the compilation:

CC = gcc # Flag for implicit rules
CFLAGS = -g # Flag for implicit rules. Turn on debug info

# Implicit rule #1: blah is built via the C linker implicit rule
# Implicit rule #2: blah.o is built via the C compilation implicit rule, because blah.c exists
blah: blah.o

blah.c:
	echo "int main() { return 0; }" > blah.c

clean:
	rm -f blah*

Static Pattern Rules

Static pattern rules are another way to write less in a Makefile. Here’s their syntax:

targets...: target-pattern: prereq-patterns ...
   commands

The essence is that the given target is matched by the target-pattern (via a % wildcard). Whatever was matched is called the stem. The stem is then substituted into the prereq-pattern, to generate the target’s prereqs.

A typical use case is to compile .c files into .o files. Here’s the manual way:

objects = foo.o bar.o all.o
all: $(objects)
	$(CC) $^ -o all

foo.o: foo.c
	$(CC) -c foo.c -o foo.o

bar.o: bar.c
	$(CC) -c bar.c -o bar.o

all.o: all.c
	$(CC) -c all.c -o all.o

all.c:
	echo "int main() { return 0; }" > all.c

# Note: all.c does not use this rule because Make prioritizes more specific matches when there is more than one match.
%.c:
	touch $@

clean:
	rm -f *.c *.o all

Here’s the more efficient way, using a static pattern rule:

objects = foo.o bar.o all.o
all: $(objects)
	$(CC) $^ -o all

# Syntax - targets ...: target-pattern: prereq-patterns ...
# In the case of the first target, foo.o, the target-pattern matches foo.o and sets the "stem" to be "foo".
# It then replaces the '%' in prereq-patterns with that stem
$(objects): %.o: %.c
	$(CC) -c $^ -o $@

all.c:
	echo "int main() { return 0; }" > all.c

# Note: all.c does not use this rule because Make prioritizes more specific matches when there is more than one match.
%.c:
	touch $@

clean:
	rm -f *.c *.o all

Static Pattern Rules and Filter

While I introduce the filter function later on, it’s common to use in static pattern rules, so I’ll mention that here. The filter function can be used in Static pattern rules to match the correct files. In this example, I made up the .raw and .result extensions.

obj_files = foo.result bar.o lose.o
src_files = foo.raw bar.c lose.c

all: $(obj_files)
# Note: PHONY is important here. Without it, implicit rules will try to build the executable "all", since the prereqs are ".o" files.
.PHONY: all

# Ex 1: .o files depend on .c files. Though we don't actually make the .o file.
$(filter %.o,$(obj_files)): %.o: %.c
	echo "target: $@ prereq: $<"

# Ex 2: .result files depend on .raw files. Though we don't actually make the .result file.
$(filter %.result,$(obj_files)): %.result: %.raw
	echo "target: $@ prereq: $<"

%.c %.raw:
	touch $@

clean:
	rm -f $(src_files)

Pattern Rules

Pattern rules are often used but quite confusing. You can look at them as two ways:

• A way to define your own implicit rules
• A simpler form of static pattern rules

Let’s start with an example first:

# Define a pattern rule that compiles every .c file into a .o file
%.o : %.c
        $(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@

Pattern rules contain a ‘%’ in the target. This ‘%’ matches any nonempty string, and the other characters match themselves. ‘%’ in a prerequisite of a pattern rule stands for the same stem that was matched by the ‘%’ in the target.

Here’s another example:

# Define a pattern rule that has no pattern in the prerequisites.
# This just creates empty .c files when needed.
%.c:
   touch $@

Double-Colon Rules

Double-Colon Rules are rarely used, but allow multiple rules to be defined for the same target. If these were single colons, a warning would be printed and only the second set of commands would run.

all: blah

blah::
	echo "hello"

blah::
	echo "hello again"

Commands and execution

Command Echoing/Silencing

Add an @ before a command to stop it from being printed You can also run make with -s to add an @ before each line

all:
	@echo "This make line will not be printed"
	echo "But this will"

Command Execution

Each command is run in a new shell (or at least the effect is as such)

all:
	cd ..
	# The cd above does not affect this line, because each command is effectively run in a new shell
	echo `pwd`

	# This cd command affects the next because they are on the same line
	cd ..;echo `pwd`

	# Same as above
	cd ..; \
	echo `pwd`

Default Shell

The default shell is /bin/sh. You can change this by changing the variable SHELL:

SHELL=/bin/bash

cool:
	echo "Hello from bash"

Double dollar sign

If you want a string to have a dollar sign, you can use $$. This is how to use a shell variable in bash or sh.

Note the differences between Makefile variables and Shell variables in this next example.

make_var = I am a make variable
all:
	# Same as running "sh_var='I am a shell variable'; echo $sh_var" in the shell
	sh_var='I am a shell variable'; echo $$sh_var

	# Same as running "echo I am a make variable" in the shell
	echo $(make_var)

Error handling with -k, -i, and -

Add -k when running make to continue running even in the face of errors. Helpful if you want to see all the errors of Make at once. Add a - before a command to suppress the error Add -i to make to have this happen for every command.

one:
	# This error will be printed but ignored, and make will continue to run
	-false
	touch one

Interrupting or killing make

Note only: If you ctrl+c make, it will delete the newer targets it just made.

Recursive use of make

To recursively call a makefile, use the special $(MAKE) instead of make because it will pass the make flags for you and won’t itself be affected by them.

new_contents = "hello:\n\ttouch inside_file"
all:
	mkdir -p subdir
	printf $(new_contents) | sed -e 's/^ //' > subdir/makefile
	cd subdir && $(MAKE)

clean:
	rm -rf subdir

Export, environments, and recursive make

When Make starts, it automatically creates Make variables out of all the environment variables that are set when it’s executed.

# Run this with "export shell_env_var='I am an environment variable'; make"
all:
	# Print out the Shell variable
	echo $$shell_env_var

	# Print out the Make variable
	echo $(shell_env_var)

The export directive takes a variable and sets it the environment for all shell commands in all the recipes:

shell_env_var=Shell env var, created inside of Make
export shell_env_var
all:
	echo $(shell_env_var)
	echo $$shell_env_var

As such, when you run the make command inside of make, you can use the export directive to make it accessible to sub-make commands. In this example, cooly is exported such that the makefile in subdir can use it.

new_contents = "hello:\n\techo \$$(cooly)"

all:
	mkdir -p subdir
	printf $(new_contents) | sed -e 's/^ //' > subdir/makefile
	@echo "---MAKEFILE CONTENTS---"
	@cd subdir && cat makefile
	@echo "---END MAKEFILE CONTENTS---"
	cd subdir && $(MAKE)

# Note that variables and exports. They are set/affected globally.
cooly = "The subdirectory can see me!"
export cooly
# This would nullify the line above: unexport cooly

clean:
	rm -rf subdir

You need to export variables to have them run in the shell as well.

one=this will only work locally
export two=we can run subcommands with this

all:
	@echo $(one)
	@echo $$one
	@echo $(two)
	@echo $$two

.EXPORT_ALL_VARIABLES exports all variables for you.

.EXPORT_ALL_VARIABLES:
new_contents = "hello:\n\techo \$$(cooly)"

cooly = "The subdirectory can see me!"
# This would nullify the line above: unexport cooly

all:
	mkdir -p subdir
	printf $(new_contents) | sed -e 's/^ //' > subdir/makefile
	@echo "---MAKEFILE CONTENTS---"
	@cd subdir && cat makefile
	@echo "---END MAKEFILE CONTENTS---"
	cd subdir && $(MAKE)

clean:
	rm -rf subdir

Arguments to make

There’s a nice list of options that can be run from make. Check out --dry-run, --touch, --old-file.

You can have multiple targets to make, i.e. make clean run test runs the clean goal, then run, and then test.

Variables Pt. 2

Flavors and modification

There are two flavors of variables:

• recursive (use =) - only looks for the variables when the command is used, not when it’s defined.
• simply expanded (use :=) - like normal imperative programming – only those defined so far get expanded

# Recursive variable. This will print "later" below
one = one ${later_variable}
# Simply expanded variable. This will not print "later" below
two := two ${later_variable}

later_variable = later

all:
	echo $(one)
	echo $(two)

Simply expanded (using :=) allows you to append to a variable. Recursive definitions will give an infinite loop error.

one = hello
# one gets defined as a simply expanded variable (:=) and thus can handle appending
one := ${one} there

all:
	echo $(one)

?= only sets variables if they have not yet been set

one = hello
one ?= will not be set
two ?= will be set

all:
	echo $(one)
	echo $(two)

Spaces at the end of a line are not stripped, but those at the start are. To make a variable with a single space, use $(nullstring)

with_spaces = hello   # with_spaces has many spaces after "hello"
after = $(with_spaces)there

nullstring =
space = $(nullstring) # Make a variable with a single space.

all:
	echo "$(after)"
	echo start"$(space)"end

An undefined variable is actually an empty string!

all:
	# Undefined variables are just empty strings!
	echo $(nowhere)

Use += to append

foo := start
foo += more

all:
	echo $(foo)

String Substitution is also a really common and useful way to modify variables. Also check out Text Functions and Filename Functions.

Command line arguments and override

You can override variables that come from the command line by using override. Here we ran make with make option_one=hi

# Overrides command line arguments
override option_one = did_override
# Does not override command line arguments
option_two = not_override
all:
	echo $(option_one)
	echo $(option_two)

List of commands and define

The define directive is not a function, though it may look that way. I’ve seen it used so infrequently that I won’t go into details, but it’s mainly used for defining canned recipes and also pairs well with the eval function.

define/endef simply creates a variable that is set to a list of commands. Note here that it’s a bit different than having a semi-colon between commands, because each is run in a separate shell, as expected.

one = export blah="I was set!"; echo $$blah

define two
export blah="I was set!"
echo $$blah
endef

all:
	@echo "This prints 'I was set'"
	@$(one)
	@echo "This does not print 'I was set' because each command runs in a separate shell"
	@$(two)

Target-specific variables

Variables can be set for specific targets

all: one = cool

all:
	echo one is defined: $(one)

other:
	echo one is nothing: $(one)

Pattern-specific variables

You can set variables for specific target patterns

%.c: one = cool

blah.c:
	echo one is defined: $(one)

other:
	echo one is nothing: $(one)

Conditional part of Makefiles

Conditional if/else

foo = ok

all:
ifeq ($(foo), ok)
	echo "foo equals ok"
else
	echo "nope"
endif

Check if a variable is empty

nullstring =
foo = $(nullstring) # end of line; there is a space here

all:
ifeq ($(strip $(foo)),)
	echo "foo is empty after being stripped"
endif
ifeq ($(nullstring),)
	echo "nullstring doesn't even have spaces"
endif

Check if a variable is defined

ifdef does not expand variable references; it just sees if something is defined at all

bar =
foo = $(bar)

all:
ifdef foo
	echo "foo is defined"
endif
ifndef bar
	echo "but bar is not"
endif

$(MAKEFLAGS)

This example shows you how to test make flags with findstring and MAKEFLAGS. Run this example with make -i to see it print out the echo statement.

all:
# Search for the "-i" flag. MAKEFLAGS is just a list of single characters, one per flag. So look for "i" in this case.
ifneq (,$(findstring i, $(MAKEFLAGS)))
	echo "i was passed to MAKEFLAGS"
endif

Functions

First Functions

Functions are mainly just for text processing. Call functions with $(fn, arguments) or ${fn, arguments}. Make has a decent amount of builtin functions.

bar := ${subst not,"totally", "I am not superman"}
all:
	@echo $(bar)

If you want to replace spaces or commas, use variables

comma := ,
empty:=
space := $(empty) $(empty)
foo := a b c
bar := $(subst $(space),$(comma),$(foo))

all:
	@echo $(bar)

Do NOT include spaces in the arguments after the first. That will be seen as part of the string.

comma := ,
empty:=
space := $(empty) $(empty)
foo := a b c
bar := $(subst $(space), $(comma) , $(foo)) # Watch out!

all:
	# Output is ", a , b , c". Notice the spaces introduced
	@echo $(bar)

String Substitution

$(patsubst pattern,replacement,text) does the following:

“Finds whitespace-separated words in text that match pattern and replaces them with replacement. Here pattern may contain a ‘%’ which acts as a wildcard, matching any number of any characters within a word. If replacement also contains a ‘%’, the ‘%’ is replaced by the text that matched the ‘%’ in pattern. Only the first ‘%’ in the pattern and replacement is treated this way; any subsequent ‘%’ is unchanged.” (GNU docs)

The substitution reference $(text:pattern=replacement) is a shorthand for this.

There’s another shorthand that replaces only suffixes: $(text:suffix=replacement). No % wildcard is used here.

Note: don’t add extra spaces for this shorthand. It will be seen as a search or replacement term.

foo := a.o b.o l.a c.o
one := $(patsubst %.o,%.c,$(foo))
# This is a shorthand for the above
two := $(foo:%.o=%.c)
# This is the suffix-only shorthand, and is also equivalent to the above.
three := $(foo:.o=.c)

all:
	echo $(one)
	echo $(two)
	echo $(three)

The foreach function

The foreach function looks like this: $(foreach var,list,text). It converts one list of words (separated by spaces) to another. var is set to each word in list, and text is expanded for each word. This appends an exclamation after each word:

foo := who are you
# For each "word" in foo, output that same word with an exclamation after
bar := $(foreach wrd,$(foo),$(wrd)!)

all:
	# Output is "who! are! you!"
	@echo $(bar)

The if function

if checks if the first argument is nonempty. If so, runs the second argument, otherwise runs the third.

foo := $(if this-is-not-empty,then!,else!)
empty :=
bar := $(if $(empty),then!,else!)

all:
	@echo $(foo)
	@echo $(bar)

The call function

Make supports creating basic functions. You “define” the function just by creating a variable, but use the parameters $(0), $(1), etc. You then call the function with the special call builtin function. The syntax is $(call variable,param,param). $(0) is the variable, while $(1), $(2), etc. are the params.

sweet_new_fn = Variable Name: $(0) First: $(1) Second: $(2) Empty Variable: $(3)

all:
	# Outputs "Variable Name: sweet_new_fn First: go Second: tigers Empty Variable:"
	@echo $(call sweet_new_fn, go, tigers)

The shell function

shell - This calls the shell, but it replaces newlines with spaces!

all:
	@echo $(shell ls -la) # Very ugly because the newlines are gone!

The filter function

The filter function is used to select certain elements from a list that match a specific pattern. For example, this will select all elements in obj_files that end with .o.

obj_files = foo.result bar.o lose.o
filtered_files = $(filter %.o,$(obj_files))

all:
	@echo $(filtered_files)

Filter can also be used in more complex ways:

1. Filtering multiple patterns: You can filter multiple patterns at once. For example, $(filter %.c %.h, $(files)) will select all .c and .h files from the files list.

2. Negation: If you want to select all elements that do not match a pattern, you can use filter-out. For example, $(filter-out %.h, $(files)) will select all files that are not .h files.

3. Nested filter: You can nest filter functions to apply multiple filters. For example, $(filter %.o, $(filter-out test%, $(objects))) will select all object files that end with .o but don’t start with test.

Other Features

Include Makefiles

The include directive tells make to read one or more other makefiles. It’s a line in the makefile that looks like this:

include filenames...

This is particularly useful when you use compiler flags like -M that create Makefiles based on the source. For example, if some c files includes a header, that header will be added to a Makefile that’s written by gcc. I talk about this more in the Makefile Cookbook

The vpath Directive

Use vpath to specify where some set of prerequisites exist. The format is vpath <pattern> <directories, space/colon separated> <pattern> can have a %, which matches any zero or more characters. You can also do this globallyish with the variable VPATH

vpath %.h ../headers ../other-directory

# Note: vpath allows blah.h to be found even though blah.h is never in the current directory
some_binary: ../headers blah.h
	touch some_binary

../headers:
	mkdir ../headers

# We call the target blah.h instead of ../headers/blah.h, because that's the prereq that some_binary is looking for
# Typically, blah.h would already exist and you wouldn't need this.
blah.h:
	touch ../headers/blah.h

clean:
	rm -rf ../headers
	rm -f some_binary

Multiline

The backslash (“\”) character gives us the ability to use multiple lines when the commands are too long

some_file:
	echo This line is too long, so \
		it is broken up into multiple lines

.phony

Adding .PHONY to a target will prevent Make from confusing the phony target with a file name. In this example, if the file clean is created, make clean will still be run. Technically, I should have used it in every example with all or clean, but I wanted to keep the examples clean. Additionally, “phony” targets typically have names that are rarely file names, and in practice many people skip this.

some_file:
	touch some_file
	touch clean

.PHONY: clean
clean:
	rm -f some_file
	rm -f clean

.delete_on_error

The make tool will stop running a rule (and will propagate back to prerequisites) if a command returns a nonzero exit status. DELETE_ON_ERROR will delete the target of a rule if the rule fails in this manner. This will happen for all targets, not just the one it is before like PHONY. It’s a good idea to always use this, even though make does not for historical reasons.

.DELETE_ON_ERROR:
all: one two

one:
	touch one
	false

two:
	touch two
	false

Makefile Cookbook

Let’s go through a really juicy Make example that works well for medium sized projects.

The neat thing about this makefile is it automatically determines dependencies for you. All you have to do is put your C/C++ files in the src/ folder.

# Thanks to Job Vranish (https://spin.atomicobject.com/2016/08/26/makefile-c-projects/)
TARGET_EXEC := final_program

BUILD_DIR := ./build
SRC_DIRS := ./src

# Find all the C and C++ files we want to compile
# Note the single quotes around the * expressions. The shell will incorrectly expand these otherwise, but we want to send the * directly to the find command.
SRCS := $(shell find $(SRC_DIRS) -name '*.cpp' -or -name '*.c' -or -name '*.s')

# Prepends BUILD_DIR and appends .o to every src file
# As an example, ./your_dir/hello.cpp turns into ./build/./your_dir/hello.cpp.o
OBJS := $(SRCS:%=$(BUILD_DIR)/%.o)

# String substitution (suffix version without %).
# As an example, ./build/hello.cpp.o turns into ./build/hello.cpp.d
DEPS := $(OBJS:.o=.d)

# Every folder in ./src will need to be passed to GCC so that it can find header files
INC_DIRS := $(shell find $(SRC_DIRS) -type d)
# Add a prefix to INC_DIRS. So moduleA would become -ImoduleA. GCC understands this -I flag
INC_FLAGS := $(addprefix -I,$(INC_DIRS))

# The -MMD and -MP flags together generate Makefiles for us!
# These files will have .d instead of .o as the output.
CPPFLAGS := $(INC_FLAGS) -MMD -MP

# The final build step.
$(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
	$(CXX) $(OBJS) -o $@ $(LDFLAGS)

# Build step for C source
$(BUILD_DIR)/%.c.o: %.c
	mkdir -p $(dir $@)
	$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

# Build step for C++ source
$(BUILD_DIR)/%.cpp.o: %.cpp
	mkdir -p $(dir $@)
	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@


.PHONY: clean
clean:
	rm -r $(BUILD_DIR)

# Include the .d makefiles. The - at the front suppresses the errors of missing
# Makefiles. Initially, all the .d files will be missing, and we don't want those
# errors to show up.
-include $(DEPS)

Большинство современных решений основаны на распределении статических видеочанков через HTTP-серверы (DASH, HLS), так как такие данные легко кэшируются, что позволяет масштабировать их распространение. При этом могут быть использованы уже существующие сети доставки контента (CDN).

Как работает доставка видео на основе традиционных CDN

Узкие горлышки частных сетей

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

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

Локальные кэш-сервера

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

Можно разместить локальные кэш-сервера в наиболее ответственных сетях.

P2P

Но очевидно, что невозможно разместить кэш-сервер во всех частных сетях мира. Однако, что если только один из участников будет получать трансляцию извне сети и передавать её остальным внутри? Такой подход называется Peer-to-Peer сетью или eCDN.

Решения на рынке

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

Microsoft eCDN (PEER5)

Kollective

Teleport Media

Hive Streaming

Streamroot

WebTorrent

Как устроены

Практически все решения представляют из себя набор плагинов для основных библиотек видеоплееров (video.js, hls.js, dash.js, shaka и т.д.).

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

Как работает webrtc

Чтобы подключить двух клиентов через интернет необходимо построить маршрут. Для этой задачи используется STUN-сервер, который помогает преодолеть NAT и установить маршрут от внешнего порта и IP-адреса до локального порта и IP-адреса. Такой маршрут называется набором ICE-кандидатов. Далее эти ICE-кандидаты должны быть переданы противоположному пиру для установки соединения, для этого, как правило, используется дополнительный сигнальный сервис.

Процесс подключения по webrtc

Серверная часть

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

Авторизатор

Авторизует пользователей в сети и предоставляет им первоначальные параметры.

Сворм сервер

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

STUN

Вспомогательный сервис для установления соединения по WebRTC, помогает пирам собрать свои ICE-кандидаты.

Сигналер

Необходим для обмена сообщениями между пирами при установке соединения по WebRTC.

Сервис сбора статистики

Используется для анализа работы сети и тарификации.

Топология сети - каждый к каждому

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

Сеть представляет из себя граф

Алгоритм

1. Регистрация

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

2. Получение списка пиров

После регистрации пир получает от сервера список пиров-кандидатов для подключения.

3. Подключение ко всем доступным пирам

Далее, пир пытается установить соединение с каждым кандидатом из списка с помощью STUN сервера и сигнализатора.

4. Распространение чанков в сети

Обмен сообщениями и передача чанков между пирами осуществляются через webrtc data channel.

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

Получив уведомление о наличии чанка, пиры по мере необходимости запрашивают его. Если никто из сети не сообщил о наличии чанка, пир загружает его с CDN. Таким образом, HTTP запросы чанков плеером, по возможности, заменяются webrtc запросами к другим пирам сети.

Недостатки

Данные решения, в первую очередь, направлены на снижение нагрузки и затрат на CDN.

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

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

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

Собственное решение

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

Сбор информации о пирах и создание карты сети для P2P осуществляется сервисом сбора статистики, поскольку он уже обладает всей необходимой информацией.

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

Топология сети - дерево

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

Алгоритм

1. Отправка статистики

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

2. Определение своей сети и необходимости участия в P2P

Сбор ICE candidates

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

Определение типа кэша

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

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

3. Подписка на список пиров внутри своей сети

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

Эти данные являются общими для всех участников сети и могут быть закешированы.

4. Определение необходимости поиска источника в P2P

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

Наличие в сети других пиров

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

Замер скорости

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

• При получении с CDN оценивается отклонение от целевой задержки.

• При получении из P2P оценивается время на прохождение пингов (меньше 10 мс - хорошо, больше 50 мс - плохо).

5. Выбор подходящего пира для подключения

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

Это другой пир

Необходимо исключить себя из кандидатов на подключение.

Есть свободные слоты

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

Мы используем ограничение дочерних пиров до трех.

Не отмечен ранее как плохой

Проверяем, чтобы кандидат не был ранее отмечен как неподходящий.

Быстрее

Убеждаемся, что скорость подключения не ниже, чем у текущего узла.

Не глубже в структуре дерева подключений

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

Нет в цепочке родительских и дочерних пиров

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

Не в кольце

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

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

6. Подключение

Как только пир получает отобранный список кандидатов для подключения, производятся попытки установить эти соединения.

Типы подключения

При P2P подключении есть две стороны: ретранслирующая стрим и получающая сторона.

Receiver

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

• Основное подключение - активное соединение, через которое пир получает стрим.

• Резервное подключение - в случае разрыва основного соединения пир начинает получать стрим через резервное подключение.

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

Relay

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

Сигналинг для подключения

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

Минимальный набор данных для подключения

При установке WebRTC соединения пиры обмениваются записями SDP (Session Description Protocol), содержащими описание сессии, включающее следующие данные:

• Описание сессии

• Открытый ключ шифрования

• ICE кандидаты

• Описание медиа секций

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

Предварительная генерация сертификата

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

Нужны только ICE кандидаты

К сожалению, нельзя использовать предварительно сгенерированные ICE кандидаты, так как порты для подключения уникальны для каждого подключения.

Сигналинг через dataChannel

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

Способы передачи данных

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

Передача стрима через dataChannel

Такой подход основан на подмене HTTP запросов плеера и их перенаправлении в P2P сеть. Содержимое чанков в виде ArrayBuffer передается через dataChannel и используется в качестве ответа на HTTP запросы плеера. Это позволяет плавно переключаться между источниками, получая чанки от любого из пиров или от CDN, в случае необходимости, незаметно для зрителя. Однако, у этого способа есть особенности и недостатки. Необходима проверка целостности и подмены чанка, необходимо иметь контрольную сумму чанка и сверять ее при получении из P2P. Есть некоторые осложнения, связанные с ABR: пиры могут просматривать трансляцию в разных качествах, технически это разные видео с разными файлами чанков. Эту проблему можно решить различными способами, например:

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

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

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

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

Передача стрима через аудио и видео медиа секции

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

Симулятор

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

Мониторинг и анализ

Сбор статистики

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

• Информация о локальной сети

• Наличие в сети локального кеша

• Глубина в дереве подключений

• К каким пирам подключен

• Откуда получает данные (P2P или CDN)

• Скорость получения

• Скорость отдачи данных другим пирам

Визуализация сети

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

Выводы

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

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

Потенциал

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

Появление и внедрение новых стандартов связи, таких как 5G и 6G, а также спутниковый интернет и рост производительности устройств, могут вывести актуальность P2P-сетей на новый уровень.

Эта статья - очень “начального” уровня. Устроим маленький эксперимент - создадим чистую виртуальную машину и попробуем запустить ядро Linux “без всего”. Или почти “без”, т.к. нам понадобится загрузчик ОС - и какая-нибудь “пользовательская программа” (её мы сотворим сами). Конечно, продвинутые пользователи Linux такой “эксперимент” могут провести просто отредактировав параметры запуска при включении - но наш рассказ всё же для тех кто почти (или совсем) не в теме :)

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

Что такое ядро - и как им воспользоваться

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

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

Поэтому наша цель - запустить ядро и передать управление небольшой демонстрационно программке которая сможет успешно “дёргать” эти системные вызовы. Попутно мы рассмотрим некоторые дополнительные вещи - хотя не актуальные для нашего эксперимента - но о которых полезно иметь представление.

Создайте виртуальную машину

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

Здесь и далее мы хотя говорим подробно о шагах которые следует выполнить, но всё же избегаем излишне детальных указаний “нажмите такую-то кнопку”. Пусть подобные мелочи останутся именно в качестве “упражнения” :) В частности интерфейс VirtualBox довольно интуитивный, да и нагуглить вопросы по ней легко.

пустая виртуалка - кнопка настроек (шестеренка) и запуска (стрелка) сверху

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

вообще эта штука может и в хозяйстве пригодиться

Сейчас мы запустим дефолтный пункт меню (просто нажмите Enter) - но на будущее обратите внимание на пункт “Boot existing OS” - он отменяет загрузку с LiveCD и грузит то что у вас установлено на основном диске - мы будем этим пользоваться чтобы удобнее проверять что получилось.

Подготовка жёсткого диска

Итак нажмите “Boot SystemRescueCD using default options”. Начнётся какая-то активность которая рано или поздно закончится надписью “automatic login” и ниже приглашением командной строки в духе [root@systemresccd ~]# - в принципе можно запустить графическую оболочку (startx) но нам это сейчас не нужно.

SystemRescueCD грузится в консольный режим но предлагает запустить оконный интерфейс

Наш жёсткий диск виден среди девайсов, попробуйте ввести ls /dev/sd* и вы должны обнаружить вероятно диск /dev/sda - он ещё не разбит на разделы (вроде /dev/sda1) - и этим мы сейчас займёмся.

Запустите утилиту fdisk указав ей в качестве параметра обнаруженный диск, то есть fdisk /dev/sda - у неё простой интерфейс, команды однобуквенные - и сразу напоминает что для списка команд можно нажать m (почему-то).

список команд появляющийся по команде “m”

Из всего этого многообразия нам нужно немного:

• создать новую таблицу разделов (сделайте DOS partition table) нажав “o”

• создать новый раздел (первичный) нажмите “n” и выделите под него весь диск

• сделайте этот раздел загружаемым (toggle bootable flag) нажав “a”

• можете проверить получившуюся таблицу нажав “p”

• и наконец запишите все изменения (и выйдите) нажав “w”

Теперь команда ls /dev/sd* будет сообщать что у вас появился ещё и раздел /dev/sda1 - им мы будем активно пользоваться в дальнейшем.

В частности нужно создать на нём файловую систему - это простая команда
mkfs.ext4 /dev/sda1

Теперь всё готово к записи загрузчика. Ну или почти всё (но об этом чуть позже).

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

Загрузчик “extlinux”

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

• также популярный systemd-boot - но он по-моему требует EFI что создаёт дополнительные ненужные шаги в нашем эксперименте

• syslinux / extlinux - а вот их мы и возьмём в дело, тем более что они использованы для самого SystemRescueCD

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

У нас есть пустая директория /mnt - давайте туда его и подключим:

mount /dev/sda1 /mnt

Это необязательно, но чтобы не нарушать популярной схемы размещения файлов, давайте создадим папку /boot в корне:

mkdir /mnt/boot

Теперь всё готово к записи загрузчика, используйте команду которую он и сам подсказывает:

extlinux --install /mnt/boot

Он поместит пару файлов в указанный каталог а кроме того (благодаря ключу –install) запишет загрузочный код в начало раздела. К сожалению этого ещё недостаточно для запуска, сейчас мы убедимся.

Можете для любопытства посмотреть что теперь в корневой папке нашего диска и в папке /boot - с помощью команд ls /mnt и ls /mnt/boot сооответственно - когда налюбуетесь, давайте отмонтируем диск (чтобы быть уверенными что всё записалось) командой umount /mnt после чего выполним следующее:

• в настройках виртуалки (меню Devices) извлеките виртуальный CD

• в меню Machine нажмите Reset

Машина перезагрузится и снова пожалуется что у вас нет загрузочного девайса!

Это потому что отсутствует загрузочный код в самом первом секторе таблицы разделов (MBR - master boot record). Вставьте виртуальный диск обратно, перезагрузите машину снова в SystemRescue и давайте исправим этот недочёт.

Запись MBR - мелкий штрих

Вообще-то это опционально. Можно обойти проблему стартуя с SystemRescueCD и выбирая пункт “Boot existing OS” - в этом случае “эстафетная палочка” загрузки переходит сразу к нужному разделу диска, минуя MBR. Но всё же потратим пару минут чтобы сделать сразу хорошо.

Где-то в недрах файловой системы лежит файл mbr.bin - в нём как раз код который нужно записать. Найдите его командой

find / -name mbr.bin

у меня он оказался в /usr/lib/syslinux/bios/mbr.bin - запишите его на диск командой cat:

cat /usr/lib/syslinux/bios/mbr.bin > /dev/sda

(просто sda а не sda1 - т.к. это MBR). Теперь если вы повторите эксперимент с перезагрузкой, вы должны увидеть что extlinux запустился - он скажет что не нашёл конфигурационного файла и покажет приглашение boot: - в принципе тут можно вручную указать ядро и параметры загрузки. Но ядра у нас пока нет.

Добавим ядро, а лучше два

Итак, вновь перезагрузите машину в SystemRescue - в дальнейшем не “извлекайте” виртуальный CD а когда требуется попробовать загрузку с жёсткого диска просто используйте пункт “Boot Existing OS” из загрузочного меню.

Примонтируйте жёсткий диск как и раньше и перейдите в директорию /mnt/boot - давайте затащим сюда ядро!

А где его взять? нетрудно догадаться что как минимум одно должно быть где-то в недрах самого SystemRescueCD - попробуем найти его (оно обычно имеет название начинающееся с vmlinuz:

find / -name vmlinuz*

У меня оно нашлось например где-то в недрах /usr/lib - файл размером около 5 мегабайт. Скопируем его (находясь в /mnt/boot):

cp /usr/lib/.../vmlinuz vmlinuz1

Как видите, мы задали ему имя с суффиксом 1 - загрузке это не помешает, а мы сможем различать ядра. Так как мы собираемся попробовать разные.

Дело в том что Linux (и другие *nix системы) позволяют легко подменять ядра, выбирая нужное при загрузке. Второе ядро я взял из основной ОС на моём ноутбуке (Ubuntu 18.04 кажется). У вас под рукой такой возможности может не быть, но наверняка вы можете найти разные ядра в интернете. Свои я загрузил на гитхаб - так что вы можете воспользоваться прямой ссылкой:

wget https://github.com/RodionGork/bare-linux-experiment/raw/refs/heads/main/vmlinuz64

Естественно, сделайте это в той же папке /mnt/boot чтобы ядра лежали рядом с загрузочными файлами (это необязательно но удобно). Если вы обнаружите что виртуалка не может достучаться в сеть, проверьте настройки сети (в ней) - для запросов в интернет проще всего выбрать NAT.

Внимание: использовать “готовые” ядра затащенные непонятно откуда - плохая идея! По-хорошему нужно взять исходники и вдумчиво скомпилировать ядро нужной версии и с требуемыми настройками. Мы пропускаем этот шаг только для упрощения эксперимента!

Так или иначе, надеюсь запастись ядрами вам удалось и команда ls /mnt/boot показывает наличие файлов vmlinuz1 и vmlinuz64 - попробуем их загрузить!

Не забудьте umount, а теперь перезапускайте машину и выбирайте “Boot existing OS”.

В приглашении загрузчика, которое выглядит как boot: пишите /boot/vmlinuz1 например - полный путь до скачанного нами ядра. Жмите Enter.

Через пару секунд активной деятельности на экране появится сообщение c “kernel panic” и “Unable to mount root fs…”

Прекрасно, ядро грузится но зачем-то хочет какую-то “VFS”?

Готовим initrd - виртуальную файловую систему

Дело обстоит так что современные *nix-овые ядра предполагают такой порядок загрузки, что сразу после запуска оно ищет небольшой образ с файловой системой которую можно развернуть прямо в оперативке. А уж остальные файловые системы (на диске и т.п.) подключить потом, проведя разные дополнительные инициализации.

Образ с этой файловой системой передаётся параметром ядра initrd=... (от слов “init root directory” что ли)

Мы подготовим ему такой образ, состоящий из всего одного файла - нашей пользовательской программы! Здесь мы пойдём на ещё один трюк - первая программа которую ядро пытается запустить - это init - некий самый главный процесс ОС. Вот мы и назовём исполнимый файл нашей приложеньки именно так - и разместим в корне.

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

Напишем незамысловатую программу на С - она просто вводит строчки от пользователя и печатает их длину:

#include <stdio.h>#include <string.h>int main() {  printf("I'm mini-shell, type in your commands:\n");  while (1) {    char ur[1024];    fgets(ur, sizeof(ur), stdin);    if (ur[0] < ' ') break;    printf("%ld - not supported\n", strlen(ur));  }  return 0;}

Программа представляется как “mini-shell” хотя на самом деле конечно никакой это не shell - если вы захотите добавить здесь какие-то полезные команды, придётся их заимплементить. Пока что простим себе этот маленький обман и соберем программу, указав ключ статической компиляции (т.к. никаких динамических библиотек у нас под рукой не будет). Эта программа использует только функции стандартной библиотеки C (которые будут добавлены в исполнимый код) и системные вызовы ядра для ввода и вывода - так что все должно быть в порядке. Назовите файл init.c

gcc --static -o init init.c

Теперь нужно закинуть скомпилированный файл init в виртуалку. В ней во-первых перезагрузитесь снова в SystemRescueCD, примонтируйте диск и перейдите в /mnt/boot - а во-вторых переключите настройки сети на “host network only” (перед этим нужно в настройках самого VirtualBox создать новый host-only адаптер). После этого вы сможете либо приконнектиться из виртуалки к родительской машине по sftp и стянуть файл, либо запустите на родительской машине какой-нибудь веб-сервер (хотя бы python3 -m http.server) и из виртуалки вытяните файл wget-ом. В обоих случаях адрес родительской машины будет что-то в духе 192.168.56.1 (проверьте ifconfig-ом).

Когда вам удалось заполучить скомпилированный файл init в виртуалке, убедитесь что у него присутствует исполнимый флаг (или просто проставьте его для уверенности chmod u+x init) - теперь нам нужна уличная магия собирающая образ с помощью команды cpio:

echo init | cpio -o --format=newc > initrd-c

в результате появится файл initrd-c который мы и собираемся использовать при запуске. Отмонтируем диск, перезагружаемся в “existing OS” и пробуем загрузить ядро указав нужный initrd файл:

boot: /boot/vmlinuz1 initrd=/boot/initrd-c

С большой долей вероятности эта попытка обломится - вы увидите похожий экран с логом загрузки, однако утверждающий что не удалось запустить init. Немного выше по логу возможно будет отыскать конкретную ошибку, например (error -8), как-то так:

Если вы увидите error -13 - это означает “permission denied” - вы забыли сделать файл исполнимым. А вот error -8 про другое “wrong executable file format” - файл собран под 64-битную систему а ядро запускает 32-битную.

Естественно это зависит от того на какой системе и как компилировали файл.

Исправить ситуацию можно двумя способами - либо попробуйте указать другое ядро при запуске (то которое vmlinuz64) - либо возьмите другой initrd-файл - например в репозитории упомянутом выше есть initrd-asm - в нём init собранный маленькой программой на ассемблере (её код там тоже где-то есть для любопытных - своего рода “hello-world”). Если захотите собрать сами (исходник там рядом лежит), используйте команды

as --32 init.c && ld -m elf_i386 -o init a.out

После чего затащите его в виртуалку и запакуйте как и раньше (для удобства предлагаю файл назвать иначе - например initrd32 или initrd-asm).

Что касается этой ассемблерной программы - она лишь развитие примерчика из прошлой статьи про 5 ассемблеров - если вам любопытно углубиться, я обязательно напишу отдельную статейку с разбором этой программульки после которой вы сами сможете писать подобные - для развлечения или в образовательных целях!

Думаю, с нескольких попыток вам повезет :) Вы либо увидите сообщение что “mini-shell” готов к вашим экспериментам - попробуйте вводить строки а когда надоест нажмите Ctrl-C - чтобы узнать что случается если init-процесс в линуксе завершается. Либо увидите сообщение про “nedo-bash”.

С vmlinuz64 наш “недо-баш” умеет читать с клавиатуры строчки и сообщает их длину

Конфигурация для загрузчика extlinux

Можно добавить рядом с файлами загрузчика файл конфигурации, чтобы по умолчанию загружалось некоторое выбранное ядро с некоторым выбранным initrd (и прочими опциями если нужно). Для этого в SystemRescueCD примонтируйте диск (в очередной раз) и используя vi или nano создайте файл /mnt/boot/extlinux.conf с примерно таким содержимым:

prompt 1
timeout 100
default testlinux

label testlinux
kernel vmlinuz64
append initrd=initrd-c

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

Заключение

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

Надеюсь вам удалось справиться с этим “упражнением” до конца. Как вы понимаете - оно лишь отправная точка для дальнейших экспериментов. Остались разнообразные интересные вопросы которые можно поисследовать.

Например можно утащить initrd файл с Убунты (он весит около 50мб) - и попробовать подключить его. Вы получите уже более менее рабочую систему - однако убедитесь что надо создать на диске кое-какие папки (вроде /dev) да и подмонтировать его как рутовую систему.

А можно поинтересоваться, почему наш “nedo-bash” хотя выводит сообщение на экран, но ввод осуществляет только будучи запущенным с одним из двух ядер - как будто у другого ядра не включена клавиатура. Впрочем тут лучше вернуться к совету упомянутому выше - не стоит использовать непонятные-незнакомые ядра. Попробуйте собрать своё.

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

Вообще это отдельная интересная тема - номера системных функций у *nix-овых систем совпадают, у Линукса в том числе - но во-первых в 64-битном линуксе их внезапно перетасовали, во-вторых Линукс делает вызовы передавая параметры в регистрах (а-ля ДОС) - в то время как остальные пушают их “по-сишному” через стек. В общем, тоже нужна отдельная статья!

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

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

Этапы

Работа пойдёт в 2 основных этапа:

1. Собираем и запускаем Linux на qemu

2. Собираем и запускаем Linux на qemu с поддержкой пользовательского пространства Busybox

Кроме того, через qemu можно подключить отладчик прямо к действующему ядру Linux. Сначала я планировал изучить этот процесс и именно о нём написать статью, но передумал, увидев, что статья получается слишком длинной. Здесь можно почитать о kgdb. Можете сами убедиться – раньше я с ней не работал.

Установка qemu

Будем работать с эмулятором Qemu, который имитирует железо. Именно на нём будет работать тот Linux, который bs собираем. Для установки выполните:

~ sudo apt install qemu qemu-system

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

Клонируем Linux,настраиваем ветку на локальной машине

Сначала клонируем репозиторий с Linux.

~ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

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

~ du --max-depth=1 --block-size=GB | grep linux6GB     ./linux

Затем отметим галочкой ту версию, которая нас интересует. Я остановился на 5.19.

~ cd linux
# alias gco="git checkout"
~ gco v5.19
~ git branch -M 5.19

Собираем Linux

Как вы можете убедиться, весь процесс сборки документирован прямо в дереве исходников Linux, см. readme. Также можно ввести команду make help, и она выведет доступные опции. Ниже я пошагово опишу работу, которую проделал.

Очистка (на первый раз не нужна)

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

~ make mrproper

исходник

Собираем образ ядра

У ядра множество возможностей — выбирайте те, что вам нравятся. Например, в ядре есть множество драйверов, вам же, вероятно, нужны лишь некоторые из них. Если скомпилировать ядро сразу со всеми драйверами, это даже может привести к отказу некоторых функций. Драйверы – это лишь один пример. Есть подобные возможности, связанные с виртуализацией, файловыми системами и т.д. Много чего конфигурировать! Следовательно, при сборке ядра делается отдельный шаг, на котором вы явно указываете все возможности, которые вам понадобятся, а лишь затем приступаете собственно к сборке.

Если вы выбрали для сборки ядра путь /home/$USER/linux-build, то укажите флаг O (каталог вывода) как показано ниже.

~ OUTPUT_DIR=/home/$USER/linux/build
# создать файл конфигурации сборки ядра. При этом максимально возможное количество значений
# устанавливается в no. В сущности, нужно отключить как можно больше фич, 
# так у вас получится компактное ядро.
# Если хотите сделать минимальное ядро, воспользуйтесь tinyconfig вместо allnoconfig.
# Не представляю, чем они отличаются.
~ make O=$OUTPUT_DIR allnoconfig
# Здесь можно просматривать конфигурацию ядра через визуально приятный пользовательский интерфейс.
# Тут пока нечего включать.
~ make O=$OUTPUT_DIR menuconfig
# Собираем само ядро
# Заменяем 8 на столько процессов, сколько поддерживает ваш компьютер.
# cat /proc/cpuinfo | grep processor | wc -l.
~ make O=$OUTPUT_DIR -j8

На выходе получаем образ ядра –файл bzImage—и убеждаемся, что его размер составляет всего 1,5 МБ.

Этап второй: Запускаем Linux на qemu

Теперь давайте попробуем запустить при помощи qemu то ядро, которое у нас получилось.

В man-подобной справке по qemu достаточно хорошо объяснено, как работают разные флаги.

~ OUTPUT_DIR=/home/$USER/linux/build
# -nographic в сущности, означает, что мы обходимся одной лишь консолью для последовательного ввода и не нуждаемся в gui/устройстве с дисплеем.
# -append позволяет qemu передать следующую строку в качестве командной строки ядра.
#     Так можно сконфигурировать ядро в процессе загрузки:
#     - console=ttyS0 сообщает ядру, что нужно использовать последовательный порт.
#     - earlyprintk=serial,ttyS0 сообщает ядру, что нужно отправлять через последовательный порт информацию логов, чтобы мы могли, опираясь на неё,  
#        отлаживать систему после отказов ещё до того, как инициализируется код консоли. Попробуйте от этого избавиться – и увидите, что получится! 
# -kernel указывает, какой образ ядра использовать.
# 
~ qemu-system-x86_64 -kernel $OUTPUT_DIR/arch/x86/boot/bzImage -nographic -append "earlyprintk=serial,ttyS0 console=ttyS0"

Если нажать ctrl + a, а затем x, то мы покинем экран консоли. Если нажать  ctrl + a, а затем h, то будет выведено меню справки и другие опции.

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

Warning: unable to open an initial console.
List of all partitions:
No filesystem could mount root, tried:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

На следующем этапе мы от этой паники избавимся.

Обзаводимся Busybox

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

Именно здесь нам пригодится Busybox. В нём предоставляются такие команды как ls, cd, cp, mv, vim, tar, grep, dhcp, mdev (события горячего подключения устройств к Linux), ifplugd (мониторинг сетевого канала/интерфейса) – всё через маленький двоичный файл. Пожалуй, эти команды не будут такими многофункциональными и разнообразно конфигурируемыми, как их альтернативы, применяемые вне Busybox, но их нам хватит.

Посмотрите файл README к исходному коду busybox после того, как скачаете его по ссылке ниже – там всё подробно написано.

Переходите по ссылке https://busybox.net/ и забирайте новейшую стабильную версию busybox.

Конфигурируем и собираем Busybox

Процесс такой же, как и при работе с ядром Linux.

Посмотрите файл INSTALL file в исходниках к busybox, как только они скачаются.

Сначала выбираем желаемую конфигурацию Busybox, а затем приступаем к сборке.

~ cd busybox-1.33.2~ mkdir -pv build~ OUTPUT_DIR=/home/$USER/busybox-1.33.2/build# создаём файл .config, в котором выставлено множество «yes». Получаем# массу возможностей Busybox, может быть, даже больше, чем нам требуется. # Я недостаточно разбираюсь в теме, чтобы начинать с allnoconfig# поэтому включаю только абсолютный минимум функций – собственно, вот он. # Возможно, сборка получится и крупнее, чем ядро на 1,5 МБ. Давайте посмотрим ~ make O=$OUTPUT_DIR defconfig# Открываем конфигурационный UI~ make O=$OUTPUT_DIR menuconfig

Когда конфигурационный пользовательский интерфейс открыт, выбираем в нём “Settings” (Настройки) (клавишей ввода), а затем “Build Busybox as a static binary” (Собрать Busybox как статический двоичный файл) (клавишей пробела). Дело в том, что в файловой системе пользовательского пространства нашего пустого ядра не будет никаких разделяемых библиотек, поэтому мы можем сразу приступить к работе.

Теперь выходим из конфигурационного меню и сохраняем внесённые изменения.

Мы готовы приступать к сборке!

# введите make help, чтобы просмотреть доступные опции,# но, в сущности, можно включить make all или make busybox.# При первой опции также собирается документация, при второй - только busybox.~ make O=$OUTPUT_DIR -j8 busybox

И вот,

~ ls -la $OUTPUT_DIR --block-size=KB | grep busybox-rw-r--r--  1 yangwenli yangwenli    2kB Aug 23 15:33 .busybox_unstripped.cmd-rwxr-xr-x  1 yangwenli yangwenli 2694kB Aug 23 15:33 busybox-rwxr-xr-x  1 yangwenli yangwenli 2987kB Aug 23 15:33 busybox_unstripped-rw-r--r--  1 yangwenli yangwenli 2340kB Aug 23 15:33 busybox_unstripped.map-rw-r--r--  1 yangwenli yangwenli  105kB Aug 23 15:33 busybox_unstripped.out

Двоичный файл busybox, который мы хотели получить, действительно оказался размером около  2,7 МБ, больше, чем собранное нами ядро. Вариант busybox_unstripped нас не интересует. Он немного крупнее и, очевидно, предназначен для изучения при помощи аналитических инструментов, так, как об этом рассказано в Busybox FAQ.

Создаём исходную структуру каталогов

Следующие два раздела сильно вдохновлены вики-справкой по Gentoo, которая приводится в Custom Initramfs здесь.

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

Нам потребуется убедиться наверняка, что двоичный файл busybox на своём месте. А также предусмотреть init-процесс/скрипт, чтобы настроить наше пользовательское пространство.

~ mkdir /home/$USER/initramfs && cd initramfs
# создаём ряд базовых каталогов, которые понадобятся нам в нашем пользовательском пространстве Linux 
# dev, proc и sys нужны для хранения всякого материала, относящегося к работе ядра – в частности, procfs, sysfs и устройств.
# В etc будем хранить заготовки для конфигурации того материала, которым собираемся заняться в будущем.
# Из root мы будем действовать.
# В bin будут храниться исполняемые файлы.
~ mkdir {bin,dev,etc,proc,root,sys}
# busybox также рассчитывает, что в нём будут эти дополнительные каталоги, 
# так что давайте создадим их для него
~ mkdir {usr/bin,usr/sbin,sbin}
# Мы хотим, чтобы busybox был включён в наш initramfs
~ cp /home/$USER/busybox-1.33.2/build/busybox bin/busybox

Создаём init-процесс

Теперь давайте создадим init-процесс. В каталоге initramfs создаём файл под названием init

~ touch init && chmod +x init

И заполняем его следующим материалом:

#!/bin/busybox sh
# Получаем busybox, чтобы создать нежёсткие ссылки на команды 
/bin/busybox --install -s
# Монтируем файловые системы /proc и /sys.
# Можете пропустить этот шаг, если хотите. Просто мне показалось, что хорошо бы их иметь.
mount -t proc none /proc
mount -t sysfs none /sys
# Загружаем командную оболочку, которая теперь должна быть мягко связана с busybox
exec /bin/sh

Создаём initramfs cpio

Cpio – это инструмент-архиватор. В сущности, это означает, что он берёт набор файлов и каталогов и обратимо преобразует их в единственный файл. Примерно как tar. Не понимаю, почему, но initramfs указывается через cpio, поэтому и его мы должны обязательно использовать, чтобы всё упаковать. Для сжатия воспользуемся gzip.

~ find . -print0 | cpio --null --create --verbose --format=newc | gzip --best > ./custom-initramfs.cpio.gz
.
./etc
./root
./sys
./dev
./bin
./bin/busybox
./init
./proc
cpio: File ./custom-initramfs.cpio.gz grew, 1310720 new bytes not copied
./custom-initramfs.cpio.gz
7824 blocks

Вот мы и подготовили initramfs, которым собираемся пользоваться!

Этап: выполняем Linux на qemu при помощи Busybox (с применением initramfs)

Теперь давайте запустим ядро Linux с включённым initramfs!

Возьмём команду qemu, приведённую выше, и добавим флаг command from above and add an initrd, указывая таким образом initramfs.

~ LINUX_BUILD_DIR=/home/$USER/linux/build
~ INITRAMFS_DIR=/home/$USER/initramfs/custom-initramfs.cpio.gz
# В прпинципе, флаг --initrd разрешает Linux использовать тот ram-диск, который мы собрали 
~ qemu-system-x86_64 -kernel $LINUX_BUILD_DIR/arch/x86/boot/bzImage -nographic -append "earlyprintk=serial,ttyS0 console=ttyS0" --initrd $INITRAMFS_DIR

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

Слегка затронем вопрос о том, как ядро запускает пользовательское пространство, и как оно узнаёт, где найти процесс init. Чтобы запустить работу пользовательского пространства, ядро ищет /init, а затем /sbin/init, /etc/init, /bin/init и, наконец, finally /bin/sh — именно в таком порядке. Я оставил ссылку на исходник. Кроме того, в командной строке здесь. Я разместил файл init по адресу /bin/init.

Теперь, наладив поддержку initramfs, давайте соберём ещё одно ядро. Повторите шаги, проделанные выше (когда мы его конфигурировали) и соберите ядро:

~ cd /home/$USER/linux
~ make O=$LINUX_BUILD_DIR menuconfig

Перейдите в General Setup и найдите там файловую систему Initial RAM, а также диск с оперативной памятью (RAM), затем нажмите «пробел».

В самом верху конфигурационного файла также активируйте 64-битное ядро. Если при работе с двоичным файлом Busybox вы воспользуетесь командой file, то увидите, что он собран для архитектуры x86_64. Вы также убедитесь, что это файл в формате elf, поэтому мы должны будем предусмотреть в ядре поддержку и для этого формата. Поскольку мы используем в нашем init-файле нотацию !#, нам и для неё нужно будет обеспечить поддержку.

Наконец спуститесь из начала файла к Device Drivers > Character devices > Serial drivers и 8250/16550 и compatible serial support и Console on 8250/16550 и compatible serial port. Эти конфигурационные настройки нужны для того, чтобы использовать последовательный порт в качестве консоли. Подробнее об этом в документации. Если не внести эти изменения, init работать не сможет. Думаю, именно поэтому и нужна последняя строка exec /bin/sh.

Теперь соберём ядро:

~ make O=$LINUX_BUILD_DIR -j8

А потом снова запустим qemu:

~ qemu-system-x86_64 -kernel $LINUX_BUILD_DIR/arch/x86/boot/bzImage -nographic -append "earlyprintk=serial,ttyS0 console=ttyS0 debug" --initrd $INITRAMFS_DIR

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

Источники

• Build the Linux kernel and busybox and run them on qemu
• Prepare the environment for developing linux kernel with qemu
• Kernel parameter guide
• Stack Overflow answer about kernel serial console command line
• Linux source tree > Documentation > admin-guide > README
• qemu man page
• Display devices in qemu
• Gentoo wiki > Custom Initramfs
• Linux source tree > Documentation > admin-guide > init.rst
• Kernel.org > Linux Serial Consol

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

/ Flickr / Giuseppe Milo / CC

Актуальный контекст

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

И всё же, с чего начать?

Neural Networks and Deep Learning
Это бесплатная онлайн-книга ученого и программиста Майкла Нильсена (Michael Nielsen). Автор раскрывает тему глубокого обучения нейронных сетей и отвечает на такие вопросы, как: «Почему нейросети сложно тренировать?», «Как работает алгоритм обратного распространения ошибки?».

Автор книги: Tariq Rashid

Make Your Own Neural Network
Книга раскрывает математические принципы, лежащие в основе нейронных сетей, и предлагает написать собственную нейросеть на Python. Сеть будет распознавать написанные от руки цифры. Цель книги — дать читателю четкое понимание того, как работают нейросистемы, сделать информацию доступнее.

A Brief Introduction to Neural Networks
Автор книги, специалист по анализу данных и машинному обучению, простым языком объясняет принципы работы нейронных сетей. После прочтения можно самому начать работать с нейросистемами и разбираться в чужом коде. Книга постоянно улучшается, в обновленных версиях, на основании фидбека от читателей.

An Introduction to Statistical Learning
Книга-введение в методы статистического обучения. Целевая аудитория — студенты и выпускники вузов, в том числе нематематических специальностей. Всё очень доступно и с туториалами на R.

Programming Collective Intelligence
Книга рассказывает, как анализировать пользовательский опыт и человеческое поведение на основании информации, получаемой нами ежедневно. Предложенные алгоритмы сопровождаются кодом, который можно сразу использовать на веб-сайте или в приложении. Каждая глава включает практические упражнения, задача которых — усилить, отшлифовать алгоритмы.

Neural Networks: A Systematic Introduction
Общая теория о создании искусственных нейронных сетей. Каждая глава содержит примеры, иллюстрации и библиографию. Книга подойдет для тех, кто хочет углубить свои знания в этой сфере, но также может служить неплохой базой для курсов по нейровычислениям.

Deep Learning: Methods and Applications
Книга от Microsoft Research с основными методологиями глубокого обучения. Авторы рассказывают о том, как нейросети используются в задачах обработки сигналов и информации. Рассматриваются области, в которых глубокое обучение уже нашло активное применение, а также сферы, где оно может оказать значительное влияние в долгосрочной перспективе.

Deep Learning Tutorial
Издание Монреальского университета (Канада). Здесь собраны руководства по наиболее важным алгоритмам глубокого обучения. В книге показано, как реализовать их с помощью библиотеки Theano. Как отмечают авторы, читатель должен иметь представление о Python и NumPy, а также пройти курс по обращению с Theano.

Pattern Recognition and Machine Learning
Это первый учебник по распознаванию образов, представляющий Байесовский метод. В книге собраны алгоритмы приближенного вывода для ситуаций, в которых точные ответы получить невозможно. Информация подкрепляется графическими моделями для описания распределения вероятностей. Книга подходит каждому, поскольку для её свободного чтения не требуется доскональное знание концепций машинного обучения и распознавания паттернов.

Автор книги: Simon S Haykin

Neural Networks and Learning Machines
В книге разбираются концепции и принципы работы нейронных сетей и самообучающихся машин. На сегодняшний день выпущено уже третье издание.

Hands-On Machine Learning
С помощью наглядных примеров, минимума теории и двух production-ready фреймворков для Python автор помогает понять, как строятся интеллектуальные системы. Вы узнаете о различных техниках: начиная с простой линейной регрессии и заканчивая глубоким обучением. В каждой главе предусмотрены упражнения для закрепления приобретенных знаний.

Руководство хакера по нейронным сетям
Андрей Карпаты (Andrej Karpathy), заведующий разработкой ИИ в Tesla, предлагает заглянуть в прошлое нейронных сетей и начать знакомство с технологией real-valued circuits. Автор также является преподавателем курса CS231 в Стэнфорде, материалы которого тесно связаны с этой статьей. Слайды можно найти по ссылке. А заметки – тут.

Глубокое обучение, обработка естественного языка и представление данных
Как использовать глубокие нейронные сети для обработки естественного языка (NLP). Автор также старается дать ответ на вопрос, почему работают нейронные сети.

Глубокое обучение: Руководство
Java-разработчик Иван Васильев представляет ключевые концепции и алгоритмы, стоящие за глубоким обучением, используя для этого язык программирования Java. Библиотека Java для глубокого обучения находится здесь.

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

Глубокое обучение с подкреплением: Обзор
Материал посвящен последним достижениям в отрасли глубокого обучения с подкреплением (RL). Сперва авторы обращаются к принципам глубокого обучения и обучения с подкреплением, а затем переходят к проблемам их реальной применимости: играм (AlphaGo), робототехнике, чат-ботам и др.

/ Flickr / Brandur Øssursson / PD

Продвинутое чтение

Neural Networks for Applied Sciences and Engineering
Обзор архитектур нейронных сетей для непосредственного анализа данных. В отдельных главах авторы рассуждают о применимости самоорганизующихся карт для кластеризации нелинейных данных, а также об использовании рекуррентных сетей в науке.

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

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

Автор книги: Ian Goodfellow

Deep Learning (Adaptive Computation and Machine Learning series)
«Deep Learning» является единственной исчерпывающей книгой в этой области», — это слова Илона Маска, соучредителя Tesla и SpaceX. В тексте аккумулирован математический бэкграунд, рассматриваются важные концепции линейной алгебры, теории вероятностей, теории информации и машинного обучения.

Neural Networks for Pattern Recognition
В книге приведены техники для моделирования функций плотности вероятности. Рассматриваются алгоритмы минимизации функции ошибок, а также Байесовский метод и его применение. Кроме того, авторы собрали под этой обложкой более ста полезных упражнений.

Быстрый обучающий алгоритм для глубоких сетей доверия
Авторы статьи предлагают алгоритм, способный обучать глубокие сети доверия (DBM) по одному слою за раз. Также стоит обратить внимание на видеоруководство по глубоким сетям доверия от одного из авторов — Джеффри Хинтона (G. E. Hinton).

Обучение представлений методом обратного распространения ошибки
Считается основой концепции обучения нейронных сетей. Исторический экскурс и реализация. Рекомендуется к прочтению.

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

Завершение изображений с глубоким обучением в TensorFlow
Статья рассказывает, как использовать глубокое обучение для завершения изображений, используя DCGAN. Пост рассчитан на техническую аудиторию с бэкграундом в машинном обучении. Весь исходный код автор выложил на GitHub.

Генератор лиц в Torch
Автор реализует генеративную модель, которая превращает случайный «шум» в изображения лиц. Делается это с помощью генеративной состязательной сети (GAN).

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

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

YOLO: обнаружение объектов в реальном времени
Авторы демонстрируют подход к распознаванию объектов — YOLO (You Only Look Once). По их задумке, с изображением работает одна нейронная сеть, которая делит его на регионы. Регионы очерчиваются граничными рамками и «взвешиваются» на основании предсказанных вероятностей. Как реализовать «миниверсию» YOLO для работы на мобильных устройствах под iOS вы можете узнать из этой статьи.

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

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

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

Генеративные модели от OpenAI
Этот пост описывает четыре проекта, которые адаптируют генеративные модели. Авторы рассказывают, что это такое, где они используются и почему важны.

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

Генеративно-состязательная сеть в 50 строках кода
Как натренировать генеративную состязательную сеть (GAN)? Нужно лишь взять PyTorch и написать 50 строчек кода. Попробуем на досуге.

And last but not least

Какая книга лежит на столах у многих сотрудников Neurodata Lab и может считаться одной из любимых?

Авторы книги: Amit Konar, Aruna Chakraborty

Emotion Recognition. A Pattern Analysis Approach
Прекрасный материал, грамотно структурированный и опирающийся на большой объем источников и данных. Книга подходит для всех, кто увлечен проблематикой детекции и распознавания эмоций с технической точки зрения, и тем кто просто ищет захватывающее чтение.

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

• neural-network-papers
• 100 Best GitHub: Deep Learning
• awesome-deep-learning-papers

Московский зоопарк

Кремлевская ёлка

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

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

Зачем вообще нужно создавать такие сборки Linux?

Установил готовый дистрибутив или загрузился в Live — работай и изучай. Но такой подход не даёт настоящей уверенности в знаниях. Представьте: водитель и шофёр. Водитель просто ездит. Шофёр знает устройство автомобиля и может его починить.

Современные автомобили сложны — починить всё самому уже нельзя. Но вы можете открыть капот, измерить уровень масла, заменить колесо в случае прокола, установить винт для буксировочного троса и т. д. Так же и с Linux: коммерческий дистрибутив вы вряд ли соберёте, но на одну ступеньку вверх по лестнице профессионализма подниметесь.

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

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

В комментариях к моей предыдущей статье я видел замечания, что можно использовать buildroot или книгу Linux From Scratch. Скажу только, что я преследую другие цели: собрать минимальный Linux без использования специализированных программ и сделать это как можно проще.

Всем, кого заинтересовало, добро пожаловать под кат.

Действия, описанные в статье, также приведены в виде небольшого bash-скрипта в моём репозитории на GitHub.

Архитектура

Начнём с того, что необходимо для минимального Linux.

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

Нам нужно:

• ядро, которое содержит только самое необходимое;

• корневая файловая система;

• минимальный набор пользовательских программ и библиотек в корневой файловой системе;

• нечто, что может запустить само ядро на платформе (загрузчик).

Платформа

Существует множество платформ, на которых можно запустить Linux. Мы выбираем ту, которая сейчас есть практически у всех — UEFI x86_64. Это ноутбук или стационарный компьютер, где в качестве Firmware установлен UEFI. Скорее это не платформа, а семейство платформ, так как компьютеры и ноутбуки отличаются аппаратной начинкой. В нашем случае это не имеет значения, так как мы будем использовать минимальные возможности. Для тестирования Linux удобно использовать QEMU. QEMU — это система виртуализации, поддерживающая эмуляцию множества платформ, которая и сама может также рассматриваться как платформа.

Ядро

Ядро — это файл в простейшем случае или набор файлов в более сложных случаях. Мы создаём минимальный Linux, поэтому я рассматриваю только первый случай. Как я говорил ранее, бо́льшая часть исходного кода ядра Linux одинаковая для всех платформ, но бинарный код ядра будет отличаться из-за архитектуры системы команд (ISA) выбранной платформы, аппаратных средств выбранной платформы и специфики загрузки ядра на выбранной платформе.

Корневая файловая система

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

Набор пользовательских программ и библиотек

Другим звеном являются системные вызовы — особые функции, исполняемые в пространстве ядра, которые можно вызывать из пространства пользователя.

Обычно программисты вызывают не их, а обёртки для них, которые находятся в стандартной библиотеке (libc). В настоящее время наибольшее распространение получили две: glibc и musl. Первая, как правило, используется для десктопных и серверных систем, вторая — для встраиваемых и минималистичных (например, Alpine Linux — минималистичная Linux, предназначенная для запуска в Docker-контейнерах). Кроме стандартной библиотеки, существуют и другие библиотеки, предназначенные для решения специфичных задач.

Приложения могут:

• включать объектный код используемых функций (статическая линковка) в себя;

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

С целью упрощения мы будем использовать статическую линковку.

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

Это пакеты программ: coreutils, net-tools, util-linux, procps, и др. Но для минималистичных Linux существует проект BusyBox, который содержит большинство аналогов программ из ранее перечисленных пакетов.

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

Система инициализации

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

Имя файла, с которого запускается этот процесс, имеет имя (init), а процесс — особый идентификатор (PID равный 1). Файл init должен располагаться по определённому пути, где его сможет найти ядро.

Теоретически init может делать что угодно, но основная его задача — запустить фоновые процессы в пространстве пользователя и проинициализировать другие компоненты Linux. Такой init-процесс называется системой инициализации. Для Linux разработаны несколько таких систем:

• System V init — классическая UNIX-подобная система инициализации;

• systemd — современная, широко используемая система инициализации;

• OpenRC — альтернативная система инициализации, основанная на скриптах;

• BusyBox init — минималистичная система инициализации для встраиваемых систем.

Но мы создадим свою и уместим её в bash-скрипт.

Корневая файловая система и initramfs

Загрузка Linux возможна как с использованием промежуточной корневой файловой системы, служащей для первоначальной инициализации пространства пользователя так и без неё. Промежуточная корневая файловая система называется initramfs. В этом случае необходимо при загрузке Linux указать как имя файла образа ядра, так и имя файла образа initramfs. Физически файл образа initramfs — это сжатый или несжатый архив формата cpio.

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

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

• разметить диск;

• записать в один из разделов образ корневой файловой системы;

• добавить загрузчик операционной системы, в случае традиционной загрузки при помощи GRUB;

• добавить и отформатировать ESP-раздел в случае непосредственной загрузки при помощи UEFI.

Поэтому мы разместим корневую файловую систему в файле образа initramfs, а файл образа initramfs включим файл образа ядра Linux.

Чтобы использовать fallback-загрузку UEFI и загрузить Linux с флеш-диска:

• отформатируем флеш-диск файловой системой FAT32,

• переименуем файл образа ядра Linux в BOOTX64.EFI,

• BOOTX64.EFI поместим в директорию /EFI/BOOT.

Загрузчик

Загрузчик играет важную роль в процессе запуска Linux. Его можно представить как некоторую программу, которая способна запустить ядро Linux. Ядру, как и обычной программе, запущенной из командной строки, можно передавать параметры командной строки. Требования к тому, как загрузчик передаёт параметры и управление ядру называются протокол загрузки (Boot Protocol). Протоколы загрузки отличаются для разных платформ, некоторые платформы поддерживают несколько протоколов загрузки.

Мы будем использовать протокол загрузки EFI. Суть его заключается в следующем:

Для загрузки используются возможности UEFI. В этом случае файл ядра является валидным UEFI-приложением. В самом файле ядра есть небольшой код, который подготавливает ядро к вызову функции start_kernel. Этот код называется EFIStub.

UEFI поддерживает так называемые Boot Entries — записи в NVRAM о том, какие ядра доступны, на каких разделах они располагаются, какую командную строку им нужно передавать. Но эту возможность при использовании сменных носителей не используют.

Также существует возможность поместить Linux Command Line в файл образа ядра. В целях упрощения мы также использовать не будем eё использовать.

Командная строка ядра Linux

Хотя в полученном Linux мы не будем использовать командную строку ядра Linux, я приведу о ней краткую информацию. В командной строке передаются такие значения как:

• кастомный путь и имя файла для процесса init;

• блочное устройство (раздел на диске), которое содержит корневую файловую систему;

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

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

Какая командная строка была передана ядру, можно посмотреть следующим образом:

$ cat /proc/cmdline

Сборка

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

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

Для сборки нам понадобятся:

• Docker;

• Docker-образ Linux-дистрибутива;

• пакеты, которые содержат программы, позволяющие собрать ядро и пользовательские программы;

• исходники ванильного ядра Linux c сайта kernel.org;

• исходники BusyBox;

• немного терпения и умение работать с командной строкой Linux.

Кросс-компиляцию, а также создание Linux-системы с initramfs и постоянной корневой файловой системой я рассматривать не буду.

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

Создание окружения для сборки

1. Скачать и установить Docker, если он у вас не установлен.

2. Запустить Docker-контейнер в окне терминала:

   docker run -it --rm -v "%cd%":/result debian:bookworm bash
   

3. Установить пакеты:

   # apt update && apt install -y apt-file && apt-file update
   # apt install -y build-essential wget xz-utils cpio flex bison bc \
   file tree qemu-system  ncurses-dev libelf-dev libssl-dev
   

4. Создать директорию для сборки

   # mkdir build && cd build
   

Сборка пользовательских программ

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

1. Скачиваем исходный код BusyBox:

   # wget https://busybox.net/downloads/busybox-1.37.0.tar.bz2
   # tar xvf busybox-1.37.0.tar.bz2
   # cd busybox-1.37.0
   

2. Создаём конфигурацию по умолчанию:

   # make defconfig
   

3. Выполняем сборку:

   # make CONFIG_STATIC=y
   

4. Убеждаемся, что BusyBox был собран со статической линковкой:

   # file busybox
   busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=6540c48477b6eae56a14377ae0de4d0229ea75dc, for GNU/Linux 3.2.0, stripped
   

Создание корневой файловой системы

Наша Linux-система не будет иметь полноценную корневую файловую систему. Вместо этого мы будем использовать только initramfs-образ.

Initramfs — это архив в формате cpio, который содержит каталоги, файлы пользовательских программ, файлы устройств и конфигурационные файлы.

Чтобы сэкономить место, его можно сжать с помощью стандартного архиватора.

1. Создаём структуру корневой файловой системы:

   # mkdir -p ../rootfs/{bin,sbin,etc,proc,sys,usr/{bin,sbin},dev,run,tmp,var}
   

2. Выполняем установку BusyBox в директорию с корневой файловой системой:

   # make CONFIG_STATIC=y CONFIG_PREFIX=../rootfs install
   

3. Добавляем скрипт для системы инициализации:

   cat << EOF > ../rootfs/init
   #!/bin/sh
   mount -t proc none /proc
   mount -t sysfs none /sys
   mount -t tmpfs tmpfs /run
   mount -t tmpfs tmpfs /tmp
   mdev -s
   if [ -c /dev/fb0 ]; then
     TTY=/dev/tty1
   else
     TTY=/dev/ttyS0
   fi
   echo 0 > /proc/sys/kernel/printk
   printf "\033c" > \$TTY
   cat << INNER > \$TTY
                              /)
                     /\___/\ ((
                     \ @_@'/  ))
                     {_:Y:.}_//
   ================{_}^-'{_}====================
   ~                                           ~
   ~    Welcome to ArtyomSoft Minimal Linux    ~
   ~                                           ~
   =============================================
   
   TTY: \$(basename \$TTY)
   Time: \$(date)
   Kernel version: \$(uname -r)
   =============================================
   INNER
   
   exec setsid sh -c "exec sh <'\$TTY' >'\$TTY' 2>'\$TTY'"
   
   EOF
   

   # chmod +x ../rootfs/init
   

4. Создаём initramfs-образ с корневой файловой системой:

# cd ../rootfs
# find . | cpio -o -H newc | gzip > ../initramfs.cpio.gz

Сборка ядра

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

Несмотря на то, что определение опций — достаточно сложное занятие, я нахожу его увлекательным. Сильно упрощает работу по определению нужных опций использование make menuconfig или make nconfig. В первом приложении после запуска необходимо нажать /, во втором — F8 и в появившееся окно ввести часть названия опции, которую вы хотите добавить. После ввода появится окно найденных параметров с описанием назначения, зависимостями и указанием того, где они располагаются в меню.

Окно поиска опций ядра menuconfig

Окно с описанием опций ядра menuconfig

Опции можно выбирать непосредственно в интерфейсе приложения, а можно, используя скрипт ‘./scripts/config’. Помните, что если вы выбрали опцию, зависящую от опции, которая не включена у вас в конфигурации, то опция будет молчаливо проигнорирована при сборке.

Если вы добавили какую-то опцию и попытаетесь собрать ядро, часто сборщик ядра у вас запросит дополнительные опции для конфигурирования. Можно просто множество раз нажимать клавишу Enter, а можно просто перед запуском сборки ввести команду:

$ make olddefconfig

и недоконфигурированные опции примут значения по умолчанию.

Ниже я привожу, какие параметры я добавил и зачем.

1. Скачиваем исходный код ядра Linux:

   # cd ..
   # wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.12.56.tar.xz
   # tar xvf linux-6.12.56.tar.xz
   # cd linux-6.12.56
   

2. Создаём минимально возможную конфигурацию tinyconfig:

   # make tinyconfig
   

3. Устанавливаем нужные опции для компиляции ядра:

   # ./scripts/config \
   -e 64BIT \
   -e PCI \
   -e PCI_HOST_GENERIC \
   -e TTY \
   -e BLK_DEV_INITRD \
   -e SERIAL_8250 \
   -e SERIAL_8250_CONSOLE \
   -e BINFMT_ELF \
   -e BINFMT_MISC \
   -e BINFMT_SCRIPT \
   -e DEVTMPFS \
   -e DEVTMPFS_MOUNT \
   -e TMPFS \
   -e PRINTK \
   -e EARLY_PRINTK \
   -e PRINTK_TIME\
   -e PROC_FS \
   -e SYSFS \
   --set-str INITRAMFS_SOURCE "../initramfs.cpio.gz" \
   -e RD_GZIP \
   -e INITRAMFS_COMPRESSION_GZIP \
   -e ACPI \
   -e EFI \
   -e EFI_STUB \
   -e FB \
   -e FB_EFI \
   -e FRAMEBUFFER_CONSOLE
   

4. Собираем ядро:

   # make olddefconfig
   # make -j$(nproc)
   

5. Копируем файл ядра в директорию:

   # mkdir -p /result/ESP/EFI/BOOT
   # cp arch/x86/boot/bzImage /result/ESP/EFI/BOOT/BOOTX64.EFI
   

6. Добавляем EFI Firmware для QEMU

   # cp /usr/share/OVMF/OVMF_VARS.fd /result/
   # cp /usr/share/OVMF/OVMF_CODE.fd /result/
   

7. Запускаем наш Linux в QEMU:

   В Docker:

   # qemu-system-x86_64 -m 4096m -kernel /result/ESP/EFI/BOOT/BOOTX64.EFI -append "console=ttyS0" -nographic
   

   В Windows, чтобы проверить, как всё будет выглядеть при запуске на реальном железе:

   qemu-system-x86_64 -m 4096m -drive if=pflash,format=raw,readonly=on,file=./OVMF_CODE.fd -drive if=pflash,format=raw,readonly=on,file=./OVMF_VARS.fd -drive format=raw,file=fat:rw:./esp
   

8. Для выхода из QEMU нажимае Ctlr+A X

Запуск на компьютере

Проверить работу собранного Linux вы можете не только в QEMU, но и на компьютере.

1. Записать файл с ядром на флеш-диск.

2. Инициировать перезагрузку и зайти в UEFI/BIOS Setup Utility.

3. Убедиться, что у вас в UEFI отключён Secure Boot.

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

5. Выполнить загрузку с флеш-диска.

6. Поэкспериметировать с командами Linux.

7. Выключить компьютер.

Как выглядит работа с собранным Linux на реально железе, показано на видео ниже:

Выводы

Мы создали почти минимально возможный Linux для UEFI-систем x86_64.

Размер можно уменьшить ещё немного, если использовать musl в BusyBox и отключить некоторые опции при сборке. Но чтобы не усложнять материал, я этого не делал. Думаю, Linux размером около 2,5 МБ, в котором можно работать, когда современные системы занимают гигабайты, сам по себе впечатляет.

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

В системе нет:

• поддержки дисковых файловых систем;

• полноценной поддержки USB;

• Ethernet;

• Wi-Fi;

• TCP/IP и сетевых интерфейсов;

• аппаратного ускорения графики;

• пользовательских программ, кроме одного статически слинкованного BusyBox;

• разделяемых библиотек;

• полноценной системы инициализации;

• полноценной корневой файловой системы;

• модулей ядра;

• подсистемы логирования;

• подсистемы udev;

• многопользовательского режима;

• графического интерфейса.

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

Статья должна быть полезной, если вы только начинаете изучать Embedded-разработку: вы лучше поймёте, зачем создавали buildroot и Yocto.

После прочтения статьи принципы построения Unified Kernel Image (UKI) и основы systemd становятся понятнее, так же как и инструменты, создающие initramfs, — такие как Dracut или mkinitramfs.

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