в чем преимущество компиляции вашего собственного ядра linux?

<p>какую пользу я могу получить, собрав собственное ядро linux? есть ли какая-то эффективность, которую вы могли бы создать, настроив ее на свое оборудование?</p>

<p>на мой взгляд, единственное преимущество, которое вы действительно получаете от компиляции своего собственного ядра linux:</p><p><strong> вы узнаете, как скомпилировать собственное ядро linux.</strong></p><p>это не то, что вам <em> нужно </em> для увеличения скорости/памяти/xxx. это ценно, если вы чувствуете, что находитесь на той стадии своего развития. если вы хотите иметь более глубокое понимание того, что представляет собой весь этот "открытый исходный код", о том, как и каковы различные части ядра, то вам следует попробовать. если вы просто хотите ускорить загрузку на 3 секунды, тогда ... в чем смысл ... иди купи ssd. если вам любопытно, если вы хотите учиться, то компиляция собственного ядра - отличная идея, и вы, вероятно, многого добьетесь.</p><p>с учетом вышесказанного, есть несколько конкретных причин, когда было бы целесообразно скомпилировать ваше собственное ядро (как указали несколько человек в других ответах). как правило, они возникают из-за конкретной потребности в конкретном результате, например:</p><ul> <li>мне нужно, чтобы система загружалась/работала на оборудовании с ограниченными ресурсами</li> <li>мне нужно протестировать патч и оставить отзыв для разработчиков</li> <li>мне нужно отключить то, что вызывает конфликт</li> <li>мне нужно разработать ядро linux</li> <li>мне нужно включить поддержку моего неподдерживаемого оборудования</li> <li>мне нужно улучшить производительность х, потому что я бью текущие ограничения системы (и я знаю, что я делаю)</li> </ul><p>проблема заключается в том, чтобы думать, что компилирование вашего собственного ядра имеет определенную выгоду, когда все уже работает так, как должно быть, и я не думаю, что это так. хотя вы можете тратить бесчисленные часы, отключая ненужные вам вещи и настраивая настраиваемые, на самом деле ядро linux уже довольно хорошо настроено (вашим дистрибутивом) для большинства <em> </em> пользовательские ситуации.</p>

<p>большинству пользователей не нужно компилировать свое собственное ядро, их дистрибутив сделал эту работу за них. обычно дистрибутивы включают в себя набор исправлений, которые либо интегрируются с определенными частями работы дистрибутива, бэкпортами драйверов устройств и исправлений от более новых, но не выпущенных версий ядра или функций, которые они первыми открывают для своих пользователей.</p><p>когда вы компилируете свое собственное ядро, у вас есть пара опций, вы можете скомпилировать официальное ядро линуса торвальдса, это не будет включать какие-либо патчи или настройки, которые были добавлены вашим дистрибутивом (которые могут быть хорошими или плохими), или вы можете используйте инструмент перестройки дистрибутива для сборки собственного ядра.</p><p>причины, по которым вы можете захотеть пересобрать ядро, включают в себя:</p><ul> <li>исправление ошибок или добавление определенной функции в производственную систему, где вы не можете рисковать обновлением всего ядра для одного или двух исправлений.</li> <li>чтобы опробовать определенный драйвер устройства или новую функцию</li> <li>чтобы расширить ядро, работайте над ним</li> <li>тестирование некоторых модулей или функций "альфа".</li> </ul><p>многие разработчики используют его также для создания пользовательских версий ядра для встроенных систем или приставок, где им нужны специальные драйверы устройств, или они хотят удалить функциональность, которая им не нужна.</p>

<p>собственная компиляция ядра позволяет вам включать только те части, которые относятся к вашему компьютеру, что делает его меньше и потенциально быстрее, особенно во время загрузки. общие ядра должны включать поддержку как можно большего количества оборудования; во время загрузки они обнаруживают, какое оборудование подключено к вашему компьютеру, и загружают соответствующие модули, но для этого требуется время, и им нужно загружать динамические модули, а не запекать код непосредственно в ядре. нет смысла в том, чтобы ваше ядро поддерживало 400 различных процессоров, когда на вашем компьютере есть только один, или для поддержки bluetooth-мышей, если у вас их нет, это все потраченное впустую пространство, которое вы можете освободить.</p>

<p>я не могу поверить, что принятый ответ здесь начинается со слов: "это не то, что вам нужно делать для увеличения скорости/памяти/ххх".</p><p>это абсолютно неверно. я обычно настраиваю свои ядра для удаления ненужного кода, а также кода для повышения производительности, в основном связанных с аппаратным обеспечением. например, я использую старое оборудование и могу получить некоторое повышение производительности, включив редко включаемые драйверы ядра, такие как поддержка набора микросхем hpt36x, на некоторых старых mobos, которые имеют эту встроенную функцию.</p><p>другой пример, big smp под slackware используется по умолчанию, а на dell 2800, например, потребляется значительный отпечаток для запуска таких вещей, как gfsd (не как модуль ядра), который, кстати, также потребляет тики процессора для чего-то, что я не нужно аналогично для nfsd и других универсальных средств, чтобы угодить всем менталитетам, что хорошо, если вы просто пытаетесь получить linux на коробке и работает, но если вам не безразличны "скорость/память/xxx", тогда эти вещи имеют значение и работают ,.</p><p>все мои производственные ящики изготовлены на заказ. если я использую обычное оборудование, такое как оборудование серии dell (2800, 2850, 2900 и т.д.), то просто скопировать файл .config ядра в каждую коробку, скомпилировать ядро и установить.</p>

<p>вот несколько ситуаций, когда компиляция вашего собственного ядра принесет вам пользу:</p><ul> <li> <p>ядро с отключенной загрузкой модулей более безопасно. это потребует от вас выбора необходимых вам модулей и включения их в состав ядра, а не их компиляции в виде модулей.</p> </li> <li> <p>отключение поддержки/dev/kmem или отключение ее с помощью соответствующей опции компилятора - это хорошо для безопасности. я думаю, что большинство дистрибутивов делают это по умолчанию сейчас.</p> </li> <li> <p>я предпочитаю не использовать initrd, когда это возможно. адаптация вашего ядра к оборудованию, с которого оно загружается, удаляет initrd.</p> </li> <li> <p>иногда более поздняя версия ядра будет иметь нужные вам функции, но сегодня это очень редко. я помню, когда я впервые начал использовать debian, он использовал ядра 2.4, но для поддержки udev мне было нужно ядро 2.6.</p> </li> <li> <p>отключение сетевых протоколов/опций, которые вам не нужны, может ускорить вашу производительность tcp/ip.</p> </li> <li> <p>отключение ненужных опций снижает объем памяти ядра, что важно в средах с низким ram. когда вы используете систему 256 мб ram как маршрутизатор, это помогает.</p> </li> <li> <p>я нахожу все устройства "tty" в/dev раздражающими в системах, где я обычно вхожу только через последовательный или ssh.</p> </li> </ul>

<p>компиляция вашего собственного ядра позволяет вам участвовать в процессе разработки ядра, будь то простые вещи, такие как предоставление идентификаторов устройств pci/usb для существующего драйвера, которые могут заставить работать более новое устройство, чтобы глубоко погрузиться в борьбу с ядром разработка ядра.</p><p>это также позволяет вам тестировать ядра разработки на вашем оборудовании и предоставлять обратную связь, если вы заметили какие-либо регрессии. это может быть особенно полезно для вас и других, если у вас есть необычное оборудование. если вы ждете ядра дистрибутива, исправления из ваших отчетов о проблемах могут занять некоторое время, чтобы перейти в новый выпуск ядра дистрибутива.</p><p>мне также нравится собирать собственные ядра, чтобы включить поддержку только того оборудования, которое у меня есть. когда вы запускаете ядра дистрибутивов и смотрите на вывод <code>lsmod(8)</code>, вы видите множество модулей, загруженных для оборудования, которого у вас нет. это может загрязнить список модулей,/proc,/sys и ваши журналы, так что когда вы ищете что-то, оно может быть скрыто среди шума; вы также не можете быть на 100% уверены, что эти модули не способствуют возникновению проблемы, которую вы пытаетесь диагностировать.</p>

<p>я второй ответ gabe. (мой комментарий слишком длинный, поэтому я публикую в качестве ответа).</p><p>если у вас нет узкоспециализированной цели (например, встроенные машины, строгое профилирование безопасности), я не вижу никакой практической пользы для компиляции собственного ядра, кроме как посмотреть, как это делается. путем методического анализа вариантов можно увидеть, как они взаимодействуют друг с другом для построения системы, и это отличный способ понять, как работает ваша система. удивительно, что вы обнаруживаете, когда пытаетесь удалить компоненты, которые, кажется, не имеют никакого значения для задач, которые вы пытаетесь выполнить.</p><p>тем не менее, будьте осторожны - почему прыжки с кроличьей норы, несомненно, волнуют, они откашлят больше ночей и выходных, чем вы думали!</p>

<p>на работе мы используем свернутые вручную ядра, чтобы применять исправления вне дерева, такие как vserver и unionfs.</p><p>дома я собираю откатанные вручную ядра, чтобы найти, какой коммит привел к ошибке, с которой я столкнулся. когда я закончу это, я, вероятно, буду придерживаться свернутого вручную ядра, пока ошибка не будет исправлена в моем дистрибутиве (debian), после чего я снова вернусь к их ядрам.</p>

<p>эта ветка устарела и все еще действует сегодня, как и тогда, когда был задан вопрос!</p><p>ответ таков: вы компилируете ядро linux по вашему выбору в соответствии с вашими потребностями и требованиями.</p><p>многие сценарии действительны:</p><ol> <li> <p>вы являетесь инженером и требуете, чтобы ваша сборка отвечала требованиям и требованиям к производительности и безопасности вашей системы, вы перекомпилируете, чтобы соответствовать и/или превосходить указанные критерии.</p> </li> <li> <p>вы обычный пользователь, и у вас есть старая система, которую вы хотите продолжать работать как можно дольше, вы перекомпилируете добавление/удаление компонентов, чтобы сохранить вашу старую систему оптимизированной.</p> </li> <li> <p>вы обычный пользователь с новейшим самым быстрым оборудованием, и у него более чем достаточно памяти/оперативной памяти. не нужно перекомпилировать, но вы все равно можете это сделать, если хотите узнать немного больше о своей системе.</p> </li> <li> <p>вы просто хотите быть похожим на обычного пользователя microsoft и/или mac, не перекомпилируйте и просто следите за обновлениями из вашего апстрима.</p> </li> <li> <p>следите за сценариями :-)</p> </li> </ol><p>в отличие от пользователей mac/windows, linux предлагает выбор. выбор прост или оптимизация системы под ваши требования.</p>

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

<p>я удивлен, что никто не упомянул эту причину для сборки собственного ядра:</p><p>потому что вы хотите использовать другой компилятор c/c ++. gcc довольно хорош для компиляции ядра linux. но есть и превосходные компиляторы! оптимизация gcc немного отстает от компилятора intel c/c++. и intel поставляет библиотеки примитивов производительности и инструмент vtune, которые необходимы для создания высокопроизводительного ядра linux. вы можете достичь этого только с gcc и g ++. практически независимо от того, что вы делаете, результат будет ограничен компилятором. итак, я использую компилятор intel и библиотеки производительности. он немного большой - загрузка 1,5 гб, но это дает представление о том, что содержится в хорошем компиляторе.</p><p>компилятор intel c/c++ предоставляется бесплатно для некоммерческого использования. но проще найти на странице загрузки компилятора intel c ++ некоммерческую лицензию для поиска на сайте intel. я обычно не использую gcc/g ++ для чего-либо. и вам не нужно быть программистом. вы просто устанавливаете свою среду и меняете две строки в файле make, чтобы они указывали на компилятор intel.</p><p>тогда вы можете получить серьезную скорость!</p>

<p>для большинства применений универсальные ядра хороши практически для любого оборудования. кроме того, они обычно содержат (ed) патчи для конкретного дистрибутива, поэтому компиляция вашего собственного ядра может (может) вызвать проблемы.</p><p>резонанс для компиляции вашего собственного ядра:</p><ul> <li>вы используете дистрибутив на основе исходного кода, поэтому не существует "общего" ядра</li> <li>вы разработчик ядра и вы разрабатываете ядро</li> <li>вы должны настроить ядро, например, для встроенного устройства с очень ограниченным жестким диском</li> <li>некоторые драйвера не скомпилированы в (очень редкий случай)</li> <li>вы хотите исправить ядро <strong> и </strong> вы знаете, что делаете</li> <li>вы хотите узнать, как скомпилировать ядро</li> </ul><p>если бы я не использовал дистрибутив на основе исходного кода, я бы вообще не компилировал ядро.</p>