Сколько собирается ядро линукс

Насколько маленьким может быть ядро linux?

Некоторое время назад я научился конвертировать виртуальные машины в oracle cloud из ubuntu 20.04 в gentoo. Машины предоставляемые в рамках always free tier весьма маломощны. Это в частности приводит к тому, что перекомпиляция ядра превращается в достаточно длительный процесс. У исходного ядра ubuntu 20.04 в конфиге было 7904 параметра. После того, как я сделал:

число параметров уменьшилось до 1285. Мне стало интересно попробовать выбросить из ядра все лишнее и посмотреть, что получится.

Я буду компилировать ванильное ядро 5.4.0, потому что именно эта версия используется на моей установке gentoo. Для ускорения процесса я компилирую ядро на своей рабочей машине (i7, 8 cores, 64Gb RAM, tmpfs). Готовое ядро я копирую на машину в oracle cloud. Начинать процесс надо с команды:

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

Давайте скомпилируем его и посмотрим на размер ядра:

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

Итак, наше ядро будет 64-битным, мы активируем вывод диагностики ядра, включаем поддержку терминала, конфигурируем последовательный порт и консоль на нем:

Машина в oracle cloud загрузиться с этим ядром не сможет, вывода на консоль не будет. Как оказалось, надо добавить поддержку EFI и ACPI, являющуюся ее зависимостью. Скрипт ./scripts/config не реализует логику добавления обратных зависимостей т.е. если добавить только CONFIG_EFI, то make выкинет этот параметр из конфига. Также стоит отметить, что включение опций часто включает нижележащие опции. Так в случае с включением CONFIG_ACPI автоматически включается, к примеру, поддержка кнопки включения/выключения.

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

Давайте добавим необходимые параметры:

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

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

На этот раз нам удается залогиниться:

Ура! Ssh тоже работает. Тем не менее в консоли опять есть ошибки:

А в dmesg находим еще:

Добавляем поддержку часов реального времени, файловой системы vfat и inotify:

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

А вот и ответ почему в dmesg заодно с еще одной ошибкой:

Загружаемся, в консоли ошибок нет, но появилась новая ошибка в dmesg:

Перезагружаемся и на этот раз не видим новых ошибок!

На моей рабочей машине (i7, 8 cores, 64gb RAM, tmpfs) финальная конфигурация собирается за 1m 16s. В oracle cloud с двумя ядрами и на обычном диске этот же процесс занимает 19m 51s.

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

Источник

Рекорд сборки ядра Linux

Martin Bligh опубликовал тесты скорости сборки ядра Linux, использованные им при оптимизации системы. На NUMA системе из 16-ти узлов P3 700 ядро компилировалось 47 секунд. После использования различных NUMA-ориентированных патчей и оптимизации ядра время сборки сократилось до 23 секунд.

Re: Рекорд сборки ядра Linux

Wow! А что такое NUMA? Я, Вань, такую же хочу! (c) В. Высоцкий

Re: Re: Рекорд сборки ядра Linux

Re: Рекорд сборки ядра Linux

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

Re: Рекорд сборки ядра Linux

А ты возьми КДЕ с КУТ —

пол часа на такой тачке , а так — 15 минут . Так чё — давайте раздувать флейм — что это , и что у кого получилось — вот сча на ссылку гляну.

Re: Рекорд сборки ядра Linux

Еще бы сравнили, кто быстрее хот-доги в виде пингвинов пожрет.

Re: Рекорд сборки ядра Linux

А мне вспоминается чей-то пост на этом сайте.
Типа по выделенке патчи ядра выкачивать еше быстрее, чем по модему.
А у меня соберется медленнее, ну и что?
Кто-то весь день сидит ядра компилит? Очень полезное для общего развития занятие.
Типа а сколько раз ядро на этой системе в день можно собрать, а в год?
А в пятилетку? Это ж с ума можно сойти.

наверно это круто собирать ядра.

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

p.s. седня запустил XP под линухом с помощью http://www.rdesktop.org

Re: наверно это круто собирать ядра.

Я вот запустил W2K на бездисковой тачке 486, 12Мб RAM
причем рабочая ОС на этом терминале Linux а винда грузиться через, тот самый, RDesktop.
А вообще, стоит обратить внимание на http://www.ltsp.ru

Re: Рекорд сборки ядра Linux

объясните мне, неразумному, зачем оно надо то? ИМО, что 15 сек что 15 мин — один хрен

Re: Рекорд сборки ядра Linux

объясните мне, неразумному, зачем оно надо то? ИМО, что 15 сек что 15 мин — один хрен

2 BanZaj

Спасибо за клевую ссылку!! :))))

Re: Рекорд сборки ядра Linux

Очень просто — кто компилит что-то (не только ядра) — тому есть разница 15сек или 15 мин. Единственное — на таких тачках народ другим занимается.

Re: Рекорд сборки ядра Linux

NUMA-системы — такая ж. что специально ее разворачивать ради компилляции продуктов не стоит. ИМХО лучше SMP. Вот например сановский сервер о 48 камнях за 1/2 лимона $ &-E)

Re: Рекорд сборки ядра Linux

>объясните мне, неразумному, зачем оно надо то? ИМО, что 15 сек что 15 мин — один хрен разница такая, что в виндах новое оборудование вставляется за минуту, если драйвер есть, и усе. а в линухах еще иногда ядро пересобирать приходится, вот когда этот процесс будет работать быстро, можно говорить о прозрачности для юзера добавления новых устройств и т.п.

Re: Рекорд сборки ядра Linux

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

Значит подобное увеличение производительности можно получить на любой распараллеливаемой задаче!

Вот и вся мораль.

Эх, жалко не заюзать ;(
Нечем память синхронизировать. Они почитай FireWire использовали.

Re: Re: Рекорд сборки ядра Linux

Можно использовать модули без перекомпиляции ядра
Slackware 8.0 или просто свой Linux). RedHat не рекомендует заниматься
перекомпиляцией ядра .

Re: Рекорд побит: 10.31 second kernel compile

Последний рекорд: 10.31 секунды. Правда это ppc64.

Re: Рекорд сборки ядра Linux

А время конфигурации учитывалось? 🙂

Re: Рекорд сборки ядра Linux

Во всем виноват ужасный C.

Re: Рекорд сборки ядра Linux

2FoodTechnologist
ага и велосипедисты:)

Re: Рекорд сборки ядра Linux

2FoodTechnologist
ага и велосипедисты:)

Re: наверно это круто собирать ядра.

vilfred (*) (2002-03-18 03:36:39.0)

www.citrix.com посмотри. на несколько порядков получше решение

Re: Re: Рекорд сборки ядра Linux

Для онанимусов объясняю: как линьюх не патчуй, а всё равно на NUMA тормозить будет. Что они и доказали.

Re: Рекорд сборки ядра Linux

ядро NetBSD на NUMA компилируется 4.56 секунды.

Re: Рекорд сборки ядра Linux

а мой hello world даже без нума за полсекунды компилиться, так чтаа в саб вашу бздю 🙂

Re: Рекорд сборки ядра Linux

Мдя. А, что хотел своим тестом сказать/показать г-н Blight?

Re: Re: Рекорд побит: 10.31 second kernel compile

Разве сразу не видно что это тупой гон, с чего бы этот на PowerPC компилируется ядро для i386.

Вас тупо развели, а вы сразу ссылку постить.

Новый рекорд сборки ядра Linux: 7.52 секунды

Опять побит рекорд. На этот раз результат 7.52 сек.
Машина 32 х 1.1GHz POWER4, 60G RAM. Компилялось ядро 2.5.7-pre1 + ppc64 pagetable rework.
Антихрену и прочим скептикам вместо многочлена предлагается пожевать линк на источник:
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-10/1446.html

Re: Рекорд сборки ядра Linux

4 Horez:
Ядро надо собирать, если стоит не взятое из дистриба собранное ядро, в котором есть все, включая поддержку запуска ядерных ракет 🙂 а лично твое с твоими настроечками. У кого стоит ядрышко со своими настроечками, не заморачивается сборкой, а кто не может, у того все само встает при помощи той же корявой kudzu.
Так что вряд ли что-то можно сказать о нелегкости установки
оборудования на linux.

Re: Рекорд сборки ядра Linux

А если все галочки в menuconfig выключить — еще быстрее будет. Рекомендую. 🙂 dj

Re: Рекорд сборки ядра Linux

Вот если бы Линукс так умела бы бутиться!

Re: Re: наверно это круто собирать ядра.

Угу, цитикс это здорово! Только для него, как я понял, нужен WinNT TSE.

Источник

Linux kernel development для самых маленьких

Любой программист знает, что теоретически он может внести свой посильный вклад в развитие Linux ядра. С другой стороны, подавляющее большинство уверено, что занимаются этим исключительно небожители, а процесс контрибьюта в ядро настолько сложен и запутан, что обычному человеку разобраться в нём нет никакой возможности. А значит, и надобности.
Сегодня мы попробуем развеять эту легенду и покажем, как абсолютно любой инженер при наличии достойной идеи, воплощённой в коде, может предложить ее на рассмотрение Linux community для включения в ядро.

0. Подготовка

Как и перед любой инженерной операцией, всё начинается с подготовки своего рабочего места. И первейшее здесь действие — это завести себе аккаунт с адекватным именем. В идеальном мире это будет просто транскрипция имени и фамилии. Если за учётку вроде MamkinC0d$r или Developer31337 в других местах пальцем в вас тыкать не будут, то правила LKC (Linux kernel community) такое прямо запрещают — инкогнито контрибьютить в ядро не принято.

Далее вам понадобится место на локальной машине. Сама папка Linux со скачанными исходниками весит чуть меньше 3-х гигов. Но если ядро пробовать собирать, то вместе с модулями займёт все 30 GB.

Захотелось собрать несколько веток? Умножаем 30 на число веток.
И помним — скорость сборки прямо связана с количеством доступных ядер! Больше ядер — быстрее соберётся. Так что не стесняйтесь выделять под это самую мощную машину.

1. Mail

Самый спорный и поэтому регулярно вызывающий споры момент — это канал коммуникации с LKC. Он безальтернативно один. Почта. Причём сообщения отправляются по классике через smtp.

Вокруг необходимости делать всё через плейнтекст в почте есть масса споров. Недавно в сети была очередная громкая статья на эту тему. Суть материала: письма — это, конечно, здорово, но пихать туда всё, включая куски кода — это вам (т.е. LKC) популярности не добавляет и даже наоборот, отпугивает новичков. С одной стороны вроде и да, если ты не можешь спокойно и структурировано изложить свои мысли в голом тексте, то в низкоуровневой разработке ловить будет особо нечего. С другой стороны, слать в письмах сорсы патчей — это даже архаизмом назвать уже сложно.

Но, как принято в уютном мирке ядра, Линус хлопнул кулаком по столу — и все пишут письма. Возможно, буквально завтра это изменится, но на момент выхода статьи это письма и только письма.

Какой email-client выбрать — есть рекомендации. Самым рекомендуемым почтовым агентом для LKC остаётся mutt. Да, тот самый текстовый почтовый клиент, от которого сводит олдскулы. Для начала mutt нужно поставить (я думаю, со своим пакетным менеджером вы и сами справитесь), а потом задать параметры в файле

Но почты недостаточно. Без Git никуда.

2. Git

Прежде чем что-то делать с исходниками ядра, нужно настроить Git. Можно конфигурировать файлы напрямую, но есть упрощающая жизнь утилита git config, через которую можно регулировать все аспекты работы Git’a.

Внутри есть три уровня настроек: общие для всех пользователей системы и для всех репозиториев (git config —system), общие для всех репозиториев конкретного пользователя (git config —global), отдельные для каждого репозитория (git config —local).

Глобальные настройки хранятся в /etc/gitconfig, настройки пользователя в

/.config/git/config, а настройки отдельных репозиториев хранятся в файле config в каталоге .git/config.

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

/.gitconfig . Основная идея: при отправке коммитов должно отображаться ваше корректное имя.

Примечательно, что параметр sslVerify = true препятствует работе с Git напрямую через git://git.kernel.org и форсит доступ только через https://git.kernel.org . Так, наверное, секьюрнее, хотя какого-то смысла я в этом не вижу. Но, может, чего-то не знаю?

signOff обязателен, чтоб в коммитах была информация об авторе. По идее, надо бы, чтобы коммиты подписывались. Была тут недавно статья на эту тему.

Отправка патча выполняется командой git send-email. У git send-email есть несколько параметров с участием smtp, которые можно (и нужно) переопределить.

Полезный параметр —smtp-debug=1. Осуществляет логирование SMTP запросов и ответов, что помогает при разборе проблем с настройками почты. Например, я столкнулся с тем, что почтовый сервер, на котором есть у меня почтовый ящик, не поддерживает TLS. Возможны проблемы с аутентификацией, а сообщения об ошибке git send-email выдаёт не особо разнообразные и адекватные.

Можно задавать пароль к почте через параметр —smtp-pass=p4ssw0rd или вообще захардкорить в конфиге, но это это для тех, кому терять нечего. Но если каждый раз вводить пароль лень, то есть некий хак: если username был задан (через —smtp-user или sendmail.smtpUser), а пароль не указан, тогда пароль получается через git-credential.

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

3. Coding

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

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

Операция довольно долгая, так что смело можно идти за кофе или на обед. А если попробовать ускорить процесс, отказавшись от истории, то работать с «этим» будет невозможно.

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

Если бродить вслепую по гуглу не хочется, то вся максимально полезная информация по ядру сконцентрирована тут. Прочитать стоит действительно всё. Особенно правильно будет начать с How To о том, как правильно коммуницировать. Потому что мейнтейнеры, как правило, люди весьма занятые, и вникать в невнятно составленные письма им никакого интереса. Да и вам будет обидно, если из-за плохого описание ваше детище не примут в апстрим.

И вот свой небольшой и эффективный код вы написали, отладили, всё протестировали и готовы отправлять на рассмотрение. Но не спешите этого делать. Для начала обязательно проверьтесь на code style. В этом вам поможет ./script/checkpatch.pl . Для этого сделаем патч и отправим его на проверку.

После того, как пройдёт первое удивление и вы доустановите необходимые компоненты для python2 типа ply и git (который у меня так и не установился), наступит чудесное время исправления ошибок и ворнингов. По результатам которых вы а) поймёте, что красивый код писать вы не умеете б) потеряете всякое желание что-то куда-то отправлять. Ведь даже если отбросить все шутки, ещё можно как-то смириться с тем, что длина строк ограничена 100 символами (это начиная с версии 5.7, раньше так было вообще 80). Но вот такие места оставляют неизгладимое впечатление:

Для .h файлов строка с информацией о лицензии должна быть в ремарках / * */, а для *.c файлов должна быть в ремарках //. Такое запросто выбьет кого угодно из душевного равновесия. Вопрос: «Зачем?!» до сих пор болтается в моей голове, хотя есть вера в то, что это не просто ошибка в скриптах.

Кстати, чтобы просто проверить один файл достаточно вызвать

Можно прикрутить этот вызов к git, чтобы автоматически запускался этот скрипт при попытке что-то зачекинить.

Ещё важное замечание: clang-format добрался и до ядра Linux. Файл .clang-format расположился в корне ядра в кучке с другими конфигами. Но я не советую добавлять его в хук для git. Лучше всего корректно настроить среду разработки и запомнить code style. Лично мне не понравилось как он делает переносы длинных строк. Если вдруг строка оказалась длиннее допустимой, то скорее всего функция, в которой эта строка расположилась, является кандидатом на рефакторинг, и лучше его не откладывать. С другой стороны, если у вас много уже готового кода который нужно адаптировать для ядра — clang-format может сильно облегчить вам задачу.

4. Kernel build

Несмотря на то, что процесс описан в других статьях тут и тут, я все же повторюсь.

По шагам процесс сборки ядра довольно прост, если не вдаваться в детали. Для начала ставим необходимые пакеты (использовался Debian 10):

Это без компилятора и обычного для С/С++ разработчика набора программ.
Запускаем конфигурацию:

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

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

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

Если какой-то модуль не собирается, просто вырубите его в ближайшем Makefile-е (если 100% уверены, что не пытались в нём что-то улучшить). Наверняка он вам не пригодится, и тратить время на исправления смысла нет.

Теперь можно деплоить то, что получилось, на эту же систему.

Хотя, конечно, экспериментировать с ядром на той же машине, где ведётся разработка — дело рискованное.

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

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

Update: Как верно заметил gavk, ядро давно уже умеет собирать пакеты, причём как для deb, так и для rpm.
Команда

выводит весь ассортимент. Так что команда

должна собрать пакет с ядром.

5. Patches

Вот теперь мы действительно подготовили код для отправки. Лучше всего, чтобы это был единственный коммит. Так проще делать ревью и так быстрее вам ответят. Всё проверив, наконец-то делаем коммит.

Ещё можно комментарии к коммиту дополнить в человеческом текстовом редакторе.

И теперь его можно оформить в виде того самого письма. Правила хорошего тона, или best practice, если угодно — это 75 символов на строку.

В результате получите два файла. В первом 000-cover-letter.patch нужно указать заголовок письма «Subject» и основное описание патча. В описании патча пишем, для чего он создавался, кому он сделает жизнь на нашей планете лучше и каким образом. Только не словоблудим про космические корабли в Большом театре, а пишем лаконично и по делу. И не в коем случае не пишите корпоративную лабуду а-ля «Без этого патча мой бизнес встанет, меня уволят, а дети мои умрут от голода». Нет, строго по существу: «Увидел вот такую проблему вот тут, починить решил вот таким образом, исходники патча прилагаю». Всё, вы восхитительны! А если не превысили 75 символов на строку, то восхитительны в квадрате.

А ещё один волшебный скриптик ./scripts/getmaintainers.pl

позволит узнать, кому письмо отправлять.

И вот он, момент отправления письма, ради которого всё и затевалось:

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

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

6. Debuging

И чуть-чуть про отладку. Бонус «на сладкое» для начинающих разработчиков ядра, так сказать.

Как правило, при ошибке вы получаете лог с calltrace-ом. Там указываются имена функций и смещения. Примерно вот так:

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

Важно, чтобы в модуле сохранились символы (stripped модуль вам тут не поможет).

Выполнив команду list

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

И на этом позвольте откланяться.

Буду рад вопросам и замечаниям в комментариях.

Источник