Зачем компилировать ядро?

Зачем это делать если есть динамически загружаемые модули ядра и можно собрать только необходимые модули, а ядро оставить как есть?

Какой модуль надо подключить, чтобы ядро собранное для x86_64 запустилось i386?

BzImage-i386 очевидно

канпиляй

Зачем?

У меня только 8 мегабайт ОЗУ, какой модуль подключить, чтобы запустился канпилятор?

другой канпутир на котором канпиалять

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

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

Зачем компилировать ядро?

из этого диалога оно должно понять зачем канпилять ядро

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

Если не знаешь зачем, значит оно тебе не надо и можешь не задумываться над этим.

Когда у тебя слегка нестандартное железо и майнтейнер не включил нужные опции по умолчанию. У меня например десктоп с NUMA и майнтейнер ядра в моём дистрибутиве не включает Numa Memory Allocation Support. Ещё когда хочется странного, например попробовать muQSS шедулер или наложить патчик для поддержки fsync от Valve для Proton. Ну и ещё когда нужно ужаться в малый размер ОЗУ или на маленький диск.

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

из этого диалога оно должно понять зачем канпилять ядро

Чтобы понимать, надо иметь необходимость понимать. Ао н поставил вопрос так, что неоходимости в понимании у него нет.

Какой модуль надо подключить, чтобы ядро собранное для x86_64 запустилось i386?

Круглый, который у тебя сверху. Ты в него еду ешь, но это не основная его функция.

например выставить таймер на 1000 вместо дефолтных 250 герц

Таймер прерывания использовать не умеет? В Haiku умеет.

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

Скомпилировать и установить модуль ядра нельзя?

Круглый, который у тебя сверху.

Рот?

во вторых если ты хочешь монолит для именно твоей системы

Зачем? Разве что для

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

не скомпилированное не запускается

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

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

Прям в 10 раз система быстрее запускается?

иди проспись.

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

Можешь не компилять.

Тесты проводил?

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

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

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

Портос: — Собираю ядро… просто потому, что я собираю ядро!
Д’Артаньян: — Мы поспорили по поводу монолитности ядра.
Атос: — Ага…

Таймер прерывания использовать не умеет?

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

Скомпилировать и установить модуль ядра нельзя?

Так там модули в основном и занимают большую часть времени компиляции, само ядро крошечное и компилируется минут 5-10. Если экспериментальный модуль собран, но не подгружен, это делается через modprobe и добавление модуля в initramfs. Если он вообще не собран - то включать его в Kconfig и собирать со всей кучей. Ну а если же драйвер вообще в виде отдельного от ядра модуля поставляется - то используется DKMS, который также автоматом пересобирает модуль после обновления ядра.

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

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

Добавление или доработка функциональности, исправление ошибок. Иногда даже если пишешь код в виде модуля, нужно бывает пересобрать ядро с включенным AddressSanitizer. Или добавить куда-нибудь printk, чтобы посмотреть значения переменных. Отладчиком не всегда удобно, некоторые переменные исчезают в оптимизированном коде.

Таймер прерывания использовать не умеет?

Умеет. Речь о том, чтобы выбрать частоту этих прерываний. В чём вообще вопрос?

Когда у тебя слегка нестандартное железо и майнтейнер не включил нужные опции по умолчанию. У меня например десктоп с NUMA и майнтейнер ядра в моём дистрибутиве не включает Numa Memory Allocation Support. Ещё когда хочется странного, например попробовать muQSS шедулер или наложить патчик для поддержки fsync от Valve для Proton. Ну и ещё когда нужно ужаться в малый размер ОЗУ или на маленький диск.

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

This.

Умеет. Речь о том, чтобы выбрать частоту этих прерываний. В чём вообще вопрос?

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

Ну как вариант - ЧСВ. Хотя некоторые отдельно взятые Мегабаксы, например, доказывают, что это даёт прирост скорости работы.

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

Потому что в виде исходников оно не запускается же. Отмечай тред как решенный.

не скомпилированное не запускается

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

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

Уже третий с одним и тем же. Я писал

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

Отмечай тред как решенный.

Хочу посмотреть для чего ещё ядро компилируют. Из легитимного уже предложили NUMA и таймеры.

Уже третий

И, чувствую, не последний %)

Зачем компилировать ядро?

Чтобы оно было скомпилировано! Или ты уже изобрёл интерпретируемый C и даже впилил его в фирмварь материнок?

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

А они, значит, от святого духа берутся готовенькие?

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

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

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

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

Или ты уже изобрёл интерпретируемый C

Не совсем по теме, но есть компилятор TCC который может работать в режиме интерпретации (можно написать #!/usr/bin/tcc -run в начале исходника и поставить исполняемый флаг) и TCCBOOT который позволяет запустить ядро Linux из исходников без бинарников ядра.

Из легитимного уже предложили NUMA и таймеры.

Справедливости ради отмечу что десктопные ядра обычно по умолчанию собираются с 1000hz, так что пересобирать ядро для изменения частоты опроса таймеров обычно не нужно. Кстати то что делает Haiku Линукс тоже может, https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt. Только это обычно отключают для десктопа, так как отзывчивость страдает. Но если энергоэффективность важнее можно и включить.

Про таймеры какой-то древний баян, доказывающий, что компелисты даже не смотрят что там в дистрибутивах наложено. Когда и где они видели ядра для десктопа собранне не с 1000Гц? Да и тогда, когда так было - в рапах таких дистров лежали ядра lowlatency, именно со счётчиком в 1000, которого им так не хватает. Но компелисты - они компелисты. Если ядро собралось, они выключают комп до следующей компеляции.

дефолтных 250 герц

Это где так?

man перфекционизм, man обсессивно-компульсивное расстройство.

Это где так?

В дефолте

обсессивно-компульсивное расстройство

o_O

Это к «шифровальщикам» системного раздела скорее, да и к тем кто хомяк прячет.

в рапах таких дистров лежали ядра lowlatency

Опять таки справедливости ради low latency ядра это немножко больше чем просто включение 1000hz и далеко не всем нужны остальные их фичи и особенности. Но в целом сказано верно, все десктопные ядра собираются с этой частотой по умолчанию уже с десяток лет наверное, если не больше.

Это не будет работать на железе.

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