Многие владельцы Android устройств на различных форумах и сайтах часто встречают упоминание о чем-то непонятном, что называют ядром, или по-английски kernel. Его можно поменять и упоминание о нем встречается в меню настроек устройства, в разделе «О планшете (телефоне)».

Если копнуть поглубже, то окажется, что ядро – это часть операционной системы, и оно есть не только у Android, но и у других операционных систем: Windows, iOS, MacOS и прочих. Но нас будет интересовать ядро Android, и что это такое я попытаюсь объяснить на уровне начинающих пользователей.
Вы, наверное, знаете, что любая операционная система, и Android в том числе – это, по большому счету, набор программ, которые управляют работой всего устройства, и отвечают за запуск пользовательских приложений, таких как игры, менеджеры файлов, веб-браузеры и прочие.
А ядро Android является, практически, самой главной частью операционной системы, которая отвечает за взаимодействие между всем «железом» и программной частью системы. Ядро состоит из набора драйверов всего имеющегося в устройстве оборудования и подсистемы управления памятью, сетью, безопасностью, и прочих основных функций операционной системы.
Например, когда вы касаетесь экрана, чтобы запустить какое-либо приложение, драйвер сенсорной панели экрана определяет место, в котором произошло нажатие и сообщает координаты другим программам, которые опять же с помощью ядра найдут в памяти устройства нужное приложение и запустят его. Это конечно, очень упрощенная модель, но суть работы операционной системы она отражает.
Таким образом, мы выяснили, что когда любое программное обеспечение нуждается в том, чтобы оборудование планшета или телефона что-нибудь сделало, оно обращается за этим к ядру операционной системы.
Ядро управляет абсолютно всем оборудованием: Wi-Fi, Bluetooth, GPS, памятью и прочими устройствами. Не является исключением и «сердце» устройства – его процессор. Ядро может управлять его частотой и энергоснабжением.
Ядро операционной системы Android, позаимствовано ее разработчиками, компанией Google, у операционной системы Linux.

Так как ядро управляет всем оборудованием, а оборудование у всех планшетов и телефонов разное, базовое ядро Android дорабатывается производителем для каждого устройства отдельно.
Как и прошивки, ядра бывают стоковыми (заводскими) и кастомными – альтернативными, созданные независимыми разработчиками.
Зачем нужны кастомные ядра? Стоковое ядро максимально оптимизируется производителем для конкретного устройства, но в нем обычно заблокированы такие важные функции ядра, как, например, управление частотой процессора. И если вам понадобится разогнать процессор своего планшета, вам нужно будет сменить ядро на кастомное, в котором функция управления частотой процессора разблокирована.
Кроме того, кастомные ядра, обычно основаны на более свежих версиях Linux ядер. Вот примерный перечень возможностей, которые нам дают кастомные ядра:
- Изменение частоты процессора в широких пределах;
- Разгон графической подсистемы (GPU);
- Снижение частоты и напряжения питания процессора, что позволяет достичь более длительного времени работы от батареи;
- Более свежие и качественные драйверы, например, ускоряющие работу GPS или добавляющие новые функции;
- Широкие возможности по настройки и конфигурации звука и цветовой гаммы экрана;
- Поддержка альтернативных файловых систем (XFS, ReiserFS и прочих).
Так как альтернативные ядра создаются независимыми разработчиками, нет никакой гарантии, что после установки кастомного ядра ваш планшет или телефон будут работать без сбоев. Поэтому перед прошивкой нового ядра желательно сделать полную резервную копию системы.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.
Её нужно существенно доработать или удалить
Использование своего ядра с дистрибутивами ALT Linux не поддерживается как техподдержкой ООО «Альт Линукс», так и силами сообщества. Созданные в багтрекере ошибки, относящиеся к самосборным ядрам, вероятнее всего, будут закрыты как NOTABUG.
Эта страница не описывает, как собирать ядра с kernel.org, но как собирать ядра из репозиториев ALT Linux.
Содержание
Последняя информация о том, как правильно собирать ядро [ править ]
Последняя информация о том, как правильно собирать ядро, находится в пакете kernel-build-tools в файле README.ru.koi8; его посмотреть можно в git-репозитории пакета, например, тут (ссылка со временем устареет): README.ru.koi8
Зачем может быть нужно собирать своё ядро? [ править ]
- Вы разработчик ядра.
- Вам нужно ядро, собранное каким-то особым способом (например, со включенной экспериментальной опцией), и ядра в ALT Linux не собраны таким образом.
- Вы пытаетесь отладить проблему в ядре ALT Linux и в багтракере, списке рассылки или техподдержке вам подсказали, что для этого нужно собрать ядро специальным способом
- У вас есть устройство, не поддерживаемое ядрами ALT Linux (только изредка! Очень часто достаточно просто собрать свой модуль к ядру, см. ниже).
Почему обычно не нужно собирать своё ядро? [ править ]
- Это скучное занятие.
- Если вам нужен специальный драйвер, то достаточно собрать модуль к уже имеющемуся ядру.
- Распространённые мифы про сборку ядра ложны:
- Сборка ядра — простое дело Современный PC — достаточно сложное устройство, и правильный выбор опций компиляции — нетривиальное занятие. Дистрибутивные ядра оптимизированы под «средний» компьютер, пересборка увеличивает производительность Не подтверждается тестами. Чаще наоборот: неправильно собранное ядро замедляет систему. Сборка ядра — обязательное дело любого линуксоида Нет© Ненужные драйвера тормозят и занимают память Ненужные драйвера лежат на диске в виде модулей и не загружаются в память. Ядро с драйверами, вкомпилированными внутрь, работает быстрее Не подтверждается тестами. Загрузка модулей занимает несколько секунд при старте компьютера, дальнейшее использование идентично по скорости вкомпилированным драйверам. (а для тех применений, где отсутствие лишнего просмотра таблицы действительно существенно — всяко требуется специалист, не судящий по глупым сказкам)
Предупреждение [ править ]
Статья частично протухла. vsu@ советует читать доки в kernel-build-tools .
Собираем новое ядро [ править ]
Будем для примера собирать ядро версии 2.6.23. Вам понадобится хорошая быстрая машина, с быстрым процессором, и большим объемом ОЗУ [1] . Для ускорения сборки можно использовать ccache, установив для этого переменные:
Подготовительный этап [ править ]
I [ править ]
У ALT Linux разработана своя среда (kernel-build-tools) для сборки ядер. Основным мантейнером этой среды является vsu; по состоянию на декабрь 2009 последние правки публиковал aspsk:
Как видно, среда состоит из набора скриптов.
II [ править ]
Репозиторий c ядром должен находиться в директории kernel.
Забираем ядро, например, у vsu или lakostis:
Добавляем репозиторий, содержащий новую версию ядра (для git-remote может потребоваться поставить пакет perl-GIT):
В master ветку этого репозитория Линус помещает обновления для ядер серии 2.6.23 (например 2.6.23.1, 2.6.23.2…). В нашем репозитории будет создана ветка linux-2.6.23/master, которая будет отслеживать обновления для ванильного ядра 2.6.23.
Загрузим с репозитория linux-2.6.23 исходный код ядра.
Теперь в нашем репозитории ветка linux-2.6.23/master содержит ядро 2.6.23 с обновлениями. Убедимся:
Собрираем пакет kernel-source-2.6.23-1.0.0-alt1.noarch.rpm [ править ]
Как видно, данный пакет не зависит от архитектуры. Внутри пакета содержиться только файл с иходными кодами ванильного ядра: /usr/src/kernel/sources/kernel-source-2.6.23.tar.bz2
Заметьте, что данный пакет содержит исходный код ядра версии 2.6.23, а не 2.6.23.1. Собрать этот пакет не составит труда. Достаточно:
В ответ на ругань add_changelog что версия пакета не изменилась, можно добавить к alt1 точку: ‘alt1.’, потом удалить. Версия пакета не изменяется, а изменяется имя пакета.
Осталось собрать сам пакет с помощью gear в hasher:
на результат не влияют, там BuildRequires(pre) не хватает. После сборки этот пакет будет находится в репозитории hasher-a.
Собираем пакет kernel-image-std-smp-2.6.23-alt1.i586.rpm [ править ]
Собственно этот пакет содержит само ядро + стандартные модули поставляемые с ядром.
Несколько слов о структуре репозитория. На мой взгляд следует различать ветки:
- kernel-source — цель этой ветки создать пакет с исходниками ванильного ядра 2.6.23 (мы использовали эту ветку на предыдущем шаге).
- начинающиеся с feat-*-* fix-*-* . Каждая такая ветка содержит ванильное ядро + какое-то одно исправление, дополнение, патч.
Имя ветки сообщает, какое конкретное дополнение она несет.
- fix-stable — содержит ванильное ядро с последними исправлениями 2.6.23.1.
- kernel-image-std-smp — содержит пропатчиное ядро. эту ветку мержутся ветки fix-stable, feat-*-*, fix-*-*, fix-stable
Цель ветки kernel-image-std-smp создать мега патч-бомбу который накладывается на ванильное ядро 2.6.23, скомпилировать бинарное ядро, собрать пакет.
Файл branches-to-merge используется скриптом merge-all-branches. Может возникнуть вопрос: «Зачем мержить ветки которые указаны в branches-to-merge, если они уже в замерженыы в ветку kernel-image-std-smp ?» Ответ: Периодически в этих ветках появляется что-то новое, вот скрипт и проверяет, что появилось. Ещё возможен вариант вида branch-* скрипт merge-all-branches проверяет, есть ли что-то новое, если нет — ничего не делает, если есть — спрашивает, надо ли это мержить.
В моем случае, накатывать 2.6.23 поверх пропатченого 2.6.18, бесмысленно, иначе там всё развалится. Придётся делать по сути rebase всех веток с патчами, и подцеплять к старой истории в самом конце. При сборке 2.6.23 лучше создать новые ветки fix-stable, kernel-image-std-smp, …
A [ править ]
Cоздадим ветку fix-stable. Задача этой ветки содержать последние официальные исправления для ядра от Linus Torvalds:
При будущих обновлениях можно поступать одним из следующим способов: 1. Из tracking branch:
2. Загрузить обновления непосредственно из репозитория Linus-а:
B [ править ]
Создадим ветку kernel-image-std-smp на основе тега v2.6.23. Задача этой ветки содержать код ядра со всеми приложеными патчами. То есть в эту ветку мержатся остальные ветки feat-*-* fix-*-*.
Заберем из старой ветки vsu/kernel-image-std-smp файлы: kernel-image.spec config-i586 config-x86_64 branches-to-merge .gear/rules modules.build
Для каждого вышеперечисленного файла выполним:
флаг -f указывает добавить .gear/rules, даже если он занесен в .gitignore
C [ править ]
Создадим ветки feat-*-* и fix-*-*. Например создадим ветку добавляющую поддержку файловой системы unioinfs.
Патч можно наложить в ручную (patch -p1 feat-core- -rt feat-core-bootsplash feat-evms feat-evms-nodm feat-fs-squashfs feat-fs-unionfs fix-core- -init fix-core- -syslog fix-stable kernel-image-std-smp kernel-source master
D [ править ]
Мержим все исправления в ветку kernel-image-std-smp, исправляем конфликты.
E [ править ]
В ветке kernel-image-std-smp, создадим новый конфиг на базе старого:
При обработке make oldconfig, следует учитывать тот факт, что при наличии возможности скомпилировать некую часть ядра в виде модуля, следует ее выбрать. Чаще всего модули не компилируются непосредственно в ядро, но бывают исключения.
Проверяем все ли впорядке:
Опцию CONFIG_LOCALVERSION_AUTO следует отключить.
F [ править ]
Сборка дополнительных модулей [ править ]
A [ править ]
Каждый пакет, несущий дополнительный модуль собирается на основе шаблона. Шаблоны для всех дополнительных модулей раньше можно было загрузить с CVS:
Теперь шаблоны для модулей находятся в репозиториях kernel-modules у мантейнеров.
B [ править ]
Например, при сборке пакета kernel-modules-nvidia-std-smp-100.14.19-alt3.132631.1.i586.rpm будет использован шаблон modules/nvidia/kernel-modules-nvidia.spec и пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm.
Пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm берем из Sisyphus.
Пакеты kernel-source-* собираются как обычно. У кого-то лежит в гите, у кого-то старым дедовским способом. Получается что мантейниры модулей предлагают только kernel-source-%modulename, а сам бинарный модуль собирает vsu. Пакеты с бинарными модулями нужно собирать с каждым обновлением ядра. Если kernel-source-modulename плохо собран, тогда vsu выполняет двойную работу, либо забивает на этот модуль.
Undeground [ править ]
то есть, rpm-build-kernel — для BuildRequires, kernel-build-tools — скрипты для использования мантейнерами
pull . сейчас можно менять на merge что лучше cherry-pick или pull ? это в древних версиях git merge не предназначался для вызова руками зависит от ситуации… если в ветке куча коммитов, которые в свежей версии уже есть, merge с большой вероятностью не пройдёт автоматически если это патчи, которые не вошли в новую версию, вероятно, лучше сделать merge а я сделал cherry 🙁 кстати, в подобном случае может иметь смысл сначала сделать merge новой версии в эту ветку хотя это зависит от того, что в дальнейшем предполагается делать с этими изменениями если нужно получить патчи для свежего апстрима, придётся делать rebase если это какие-то изменения, которые апстриму нафиг не нужны, может быть проще смержить свежую версию апстрима туда и разгрести конфликты кстати, в самом свежем git сделали поддержку revert и cherry-pick для merge… указывается, с каким родителем делать дифф, который потом откатывается или применяется A->B ы :(то есть cherry-pick может забирвать все коммиты, между A и B ? нет… это git rebase умеет только он портит исходный бранч а в чем тогда новая фишка ? cherry-pick и revert — это почти одно и то же, различаются тем, в какую сторону применяется патч патч генерируется между указанным коммитом и его родителем если это merge, нужно указать, какой из родительских коммитов нужно брать вот эту опцию и добавили то есть, если сделать cherry-pick для merge, получится один мегапатч со всеми изменениями вообще это полезно для revert
Расскажем об обновлениях и посмотрим, какие изменения уже готовят для следующей версии.
Фото — Ian Parker — Unsplash
Обновление графических драйверов
В Linux kernel 5.3 добавили поддержку GPU AMD Navi (RX5700) в драйвере amdgpu. Все бинарные микрокоды, необходимые для инициализации видеокарт, разместили (спустя какое-то время после релиза обновления) в репозитории linux-firmware.git. Ранее «бинарники» приходилось скачивать отдельно — с личного сайта Алекса Дойхера (Alex Deucher), ведущего мейнтейнера amdgpu.
Также разработчики ядра улучшили работу видеокарт GPU Vega12 и Vega20, для которых добавили дополнительные возможности управления памятью и энергопотреблением.
Есть и ряд обновлений от разработчиков проекта Nouveau, отвечающих за свободные драйверы Nvidia. Они добавили поддержку Turing TU116. Это — графический процессор, устанавливаемый на карты GeForce GTX 1660 Ti. Мейнтейнер проекта отметил, что вместе с новыми определениями чипсета в драйвере Nouveau исправили ошибки, связанные с утечками памяти и работой KMS.
Пока ничего не известно о реализации реклокинга для графических карт серии GTX 900 Maxwell. Хотя в скором времени ситуация может измениться. В середине августа Nvidia передали свежую документацию для своих продуктов в open source. И информацию, необходимую для настройки автоматического управления частотой, должны предоставить позже.
Сетевая подсистема
Linux теперь поддерживает обработку IPv4 в диапазоне 0.0.0.0/8. Введение этой подсети дало возможность распределить ещё 16 млн IP-адресов. Также для IPv4 и IPv6 добавили механизм nexthop. Он повышает масштабируемость таблиц маршрутизации. По данным разработчиков ядра, новое решение загружает 740 тыс. маршрутов за 4,3 секунды.
Также межсетевой экран netfilter с nftables получил механизм ускорения фильтрации пакетов — в драйверы добавили Flow Block API. Теперь на сторону сетевых адаптеров разрешено выносить целые таблицы правил — есть поддержка простых метаданных протоколов L3 и L4, а также сопоставление по адресам и сетевым портам отправителя/получателя и типу протокола.
Виртуализация
В состав ядра включён гипервизор ACRN, который используют в IoT-устройствах и встраиваемой технике. Его развивают на основе легковесного гипервизора Intel.
Фото — Casey Horner —Unsplash
Еще Linux получил режим time travel. Он дает возможность ускорить или, наоборот, замедлить время в виртуальном окружении UML. Эта функция упрощает отладку кода, работа которого связана со временем. Дополнительно разработчики добавили параметр time-travel-start — он запускает системные часы ВМ с требуемого момента.
Новая периферия
В Linux-ядро добавили SPI-драйвер для клавиатур и трекпадов MacBook и MacBook Pro, выпускаемых с 2015 года. Apple не раскрывали документацию для SPI-стандарта, но команде разработчиков ядра удалось провести его реверс-инжиниринг и написать драйвер. Хотя работа над проектом пока не завершена — остались еще несколько команд, информация о которых зашифрована.
Также в Linux kernel 5.3 добавили поддержку: руля Saitek R440 Force Feedback, графических планшетов Ugee Rainbow CV720, Wacom MobileStudio Pro и Wacom Intuos Pro Small (2-е поколение), а также ресивера Logitech MX3000 (27 МГц).
Что убрали
Перед релизом новой версии ядра Линус Торвальдс в рассылке LKML напомнил ИТ-сообществу главное правило разработки ядра Linux: изменения не должны нарушать работу существующих приложений. После он сообщил, что решил отказаться от патча, оптимизирующего работу ext4.
Тот сокращал число обращений к накопителю, отключая упреждающее чтение таблицы inode при мелких I/O-запросах. Но оптимизация привела к неожиданной ошибке — система начала «подвисать» при запуске генератора getrandom(), который использует дисковую активность для формирования случайных чисел. Поэтому оптимизацию ext4 отложили до тех пор, пока баг не исправят.
Также после дискуссий в LKML, разработчики объявили, что сворачивают поддержку шины FMC — за неё отвечали инженеры из CERN на протяжении семи лет. FMC использовали для связывания FPGA и других устройств с интерфейсом ввода/вывода.
Систему решили переписать с нуля, так как в ней обнаружили серьезные архитектурные недостатки. Она появится в последующих релизах ядра Linux.
Что ждать в kernel 5.4
В ней обновят систему мониторинга для процессоров AMD — hwmon. Пока что, из-за ошибки разработчика аппаратного обеспечения, решение показывает неверные данные температуры для Ryzen 3000. Также в kernel 5.4 добавят поддержку системы на кристалле Qualcomm Snapdragon 855 и Intel Icelake Thunderbolt.
Фото — Marvin Heilemann — Unsplash
В грядущей версии ядра введут патч, который оптимизирует работу ряда 64-битных игр Windows под Wine, CrossOver и Valve Proton. UMIP-инструкции выполняются в пространстве пользователя, что вызывает ошибки в работе под Wine. Новую версию Linux избавят от этого недостатка.
Разумеется, появятся свежие обновления, решающие проблему 2038 года. Разработчики регулярно вносят изменения в системные вызовы, и грядущая версия ядра не должна стать исключением.
О чем мы пишем в наших блогах и социальных сетях:
Зачем Mozilla, Coil и Creative Commons выделяют для open source проектов 100 млн долларов
«Смеха ради»: для чего могут понадобиться программные инструменты, у которых нет «боевого» применения
Как обезопасить Linux-систему: 10 советов
Как IaaS помогает франчайзи «1С»: опыт 1cloud
Как выбрать ОС для виртуального сервера
7 полезных ссылок для изучения и использования Git





