LINUX.ORG.RU

Посоветуйте руководство, объясняющее каждый пункт при конфигурации ядра

 , ,


0

1

Есть ли руководства по конфигурированию и сборке ядра, уделяющий внимание тонкостям работы определенных механизмов внутри ядра (желательно, чтобы с кусочками кода, делающего ту или иную вещь)? При просмотре меню при конфигурации ядра через make menuconfig далеко не у каждого пункта есть хорошее объяснение того, что именно он делает. Конечно, рекомендации типа «Если не знаете, что выбрать, ставьте Y» - хорошо, но было бы неплохо получить более развернутый и подробный ответ

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

Shprot
()

А нет такого в природе. Иногда какие-то подробности бывают в дереве Documentation/, но тоже не всегда. С параметрами модулей ещё хуже, там вообще единственный достоверный источник — исходники.

alegz ★★★★
()

В menuconfig внизу есть кнопочка help, которая разъясняет каждый пункт, на котором лежит плашечка выбора. В тексте могут быть ссылки на соответствующие документы в Documentation/, но не всегда. Если смысл написанного непонятен или неочевиден — в гугль по этому параметру, скорее всего найдётся тот пост в lkml в котором предлагался патч с этой фичей, и соответствующая нить обсуждения. Так же иногда приходится смотреть в сами исходники и читать там комментарии разработчика кода\фичи. Если это всё не помогло и яснее не стало — смирись с тем что это всё «не твоё», ты не вывозишь, и пользуйся готовыми ядрами дистрибутива. Ну и https://docs.kernel.org/ конечно же тоже существует не просто так.

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

Решается этот парадокс деньгами, которые идут на оплату труда «писателя технической литературы» или используются для мотивации\принуждения самих разработчиков сопровождать свой код документацией. Причём второе работает так себе, так как писать код, и писать внятные тексты на естественных языках — это разные таланты и разные профессии.

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

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

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 4)
Ответ на: комментарий от J

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

Всё так. Помнится, во времена моего студенчества была «Ядерная физика для домохозяйки» и она очень стремительно теряла актуальность.

skiminok1986 ★★★★★
()
Ответ на: комментарий от J

То есть, если посчитать diff флагов за последние 10 лет, то окажется, что если бы кто-то, 10 лет назад написал документацию по имеющимся на тот момент флагам, она бы стала в бОльшей степени неактуальна на сегодняшний день и ему бы пришлось почти все переписывать заново, а не просто дописывать документацию по мере появления новых и устаревания старых?

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

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

javascript
()
Последнее исправление: javascript (всего исправлений: 1)
Ответ на: комментарий от javascript

Забавно, но у некоторых флагов описание действительно 10-летней, а то 20-летней давности, особенно по всяким (уже) легаси штукам.

Короче, действительно, ничего больше описания нет. Можно где-то подсмотреть в Documentation/.

Если вы сомневаетесь что включить, а что выключить, могу посоветовать создать конфиг с allnoconfig, и постепенно создавать себе минимальное ядро. Если у вас какая-то железка под которое ядро использует CONFIG_OF, то есть скрипт сверяющий опции в device tree и конфиге.

a1ba ★★
()
Ответ на: комментарий от a1ba

не будет. переименование <равно> переделывание работы ключа. может порушить больше чем принести пользы.

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

pfg ★★★★★
()
Ответ на: комментарий от pfg

О чём я выше и написал. Никто не переименовывает и даже если вдруг у кого-то рука поднимается, погрепав Kconfig можно найти несколько ключей оставленных для совместимости.

a1ba ★★
()
Ответ на: комментарий от valentin13

И оно по сути являлось переводом описания пунктов на русский язык. Гуглем переводим https://cateee.net/lkddb/web-lkddb/ и получаем актуальную книгу. Ну разве что без лапидарного изложения тривиальных заклинаний на тему накладывания патчей и команд запускающих сборку.

Jameson ★★★★★
()