Каково преимущество компиляции Вашего собственного ядра Linux?
Нет никакой встроенной команды, но можно легко записать функцию, которая звонит mkdir затем cd:
mkcd () {
mkdir "$1"
cd "$1"
}
Вставьте этот код Ваш ~/.bashrc файл (или ~/.kshrc для ksh пользователей, или ~/.zshrc для zsh пользователей). Это определяет вызванную функцию mkcd. "$1" будет заменен аргументом функции, когда Вы выполните его.
Эта простая версия имеет несколько дефектов:
- Вы не можете создать цепочку подкаталогов сразу. Зафиксируйте: передайте
-pопция кmkdir. (Это может или не может быть желательно, поскольку это увеличивает риск опечатки, идущей необнаруженный, например.mkcd mydierctory/newsubсчастливо создастmydierctoryиmydierctory/newsubкогда Вы означали создаватьnewsubв существующемmydirectory.) - Если аргумент начинается
-но не просто-, затемmkdirиcdинтерпретирует его как опцию. Если это справедливо-, затемcdинтерпретирует его для значения$OLDPWD. Если это+сопровождаемый 0 или больше цифрами, затемcdв zsh интерпретирует его как индекс в стопке каталога. Можно решить первую проблему, но не другие два, путем передачи--перед аргументом. Можно решить все эти проблемы путем предварительного ожидания./к аргументу, если это - относительный путь. mkdirне следуетCDPATH, ноcdделает, поэтому если Вы установилиCDPATHк значению, которое не начинается.(по общему признанию несколько необычная конфигурация), затемcdможет принести Вам к другому каталогу, чем тот, который был просто создан. Предварительное ожидание./к относительным путям фиксирует это (это вызываетCDPATHбыть проигнорированным).- Если
mkdirсбои, это пытается выполнитьсяcd. Зафиксируйте: использовать&&разделить две команды.
Все еще довольно простой:
mkcd () {
case "$1" in /*) :;; *) set -- "./$1";; esac
mkdir -p "$1" && cd "$1"
}
Эта версия все еще имеет потенциал для создания cd войдите в другой каталог от того это mkdir просто созданный в одном пограничном случае: если аргумент mkcd содержит .. и проходит символьную ссылку. Например, если текущий каталог /tmp/here и mylink символьная ссылка на /somewhere/else, затем mkdir mylink/../foo создает /somewhere/else/foo тогда как cd mylink/../foo изменения в foo. Недостаточно искать символьные ссылки в аргументе, потому что оболочка также отслеживает символьные ссылки в своем собственном текущем каталоге, таким образом, cd /tmp/mylink; mkdir ../foo; cd ../foo не изменяется в новый каталог (/somewhere/else/foo) но в /tmp/foo. Фиксация для этого должна позволить cd встроенная твердость все .. компоненты контура сначала (не имеет смысла использовать foo/.. если foo не существует, таким образом, mkdir никогда потребности не видеть никого ..).
Мы приезжаем в это устойчивое если немного окровавленная версия:
mkcd () {
case "$1" in
*/..|*/../) cd -- "$1";; # that doesn't make any sense unless the directory already exists
/*/../*) (cd "${1%/../*}/.." && mkdir -p "./${1##*/../}") && cd -- "$1";;
/*) mkdir -p "$1" && cd "$1";;
*/../*) (cd "./${1%/../*}/.." && mkdir -p "./${1##*/../}") && cd "./$1";;
../*) (cd .. && mkdir -p "${1#.}") && cd "$1";;
*) mkdir -p "./$1" && cd "./$1";;
esac
}
(Осуществление: почему я использую подоболочку для первого cd звонить?)
Если mkdir перестал работать, я хочу убедиться не изменить текущий каталог. Возврат с CD - или $OLDPWD не достаточно хорош, если оболочка не имеет разрешения измениться в его текущий каталог. Кроме того, вызов CD обновляет OLDPWD, таким образом, мы только хотим сделать это однажды (или восстановить OLDPWD).
Существуют также менее специализированные способы не должным быть перепечатать слово от предыдущей строки:
- Ввести
cd, затем Esc. (или Высокий звук +.) для вставки последнего аргумента от предыдущей команды. cd !$выполняетсяcdна последнем аргументе предыдущей команды.- Нажмите Up, чтобы вспомнить предыдущую командную строку, затем отредактировать его для изменения
mkdirвcd.
В моем уме единственное преимущество Вы действительно добираетесь от компиляции Вашего собственного ядра Linux:
Вы изучаете, как скомпилировать Ваше собственное ядро Linux.
Это не что-то, что необходимо сделать для большей скорости / память / xxx безотносительно. Это - ценная вещь сделать, если это - этап, Вы чувствуете, что Вы в в Вашей разработке. Если Вы хотите иметь более глубокое понимание того, что эта целая вещь "с открытым исходным кодом" о, о том, как и каковы различные части ядра, то необходимо дать ему движение. Если Вы просто надеетесь ускорять свое время начальной загрузки на 3 секунды, то... какой смысл... идут, покупают ssd. Если Вам любопытно, если Вы хотите учиться, то компиляция Вашего собственного ядра является прекрасной идеей, и Вы, вероятно, вытащите много из него.
После этих слов существуют некоторые определенные причины, когда было бы уместно скомпилировать Ваше собственное ядро (как несколько человек указали в других ответах). Обычно они проистекают из определенной потребности, которую Вы имеете для определенного результата, например:
- Я должен заставить систему загружать/выполнять на аппаратных средствах с ограниченными ресурсами
- Я должен проверить патч и предоставить обратную связь разработчикам
- Я должен отключить что-то, что вызывает конфликт
- Я должен разработать ядро Linux
- Я должен включить поддержку своих неподдерживаемых аппаратных средств
- Я должен улучшить производительность x, потому что я поражаю ограничения по току системы (и я знаю то, что я делаю),
Проблема находится в размышлении, что существует некоторое внутреннее преимущество для компиляции Вашего собственного ядра, когда все уже работает способ, которым это должно быть, и я не думаю, что существует. Хотя можно провести бесчисленные часы, отключая вещи, Вам не нужно и тонкая настройка вещей, которые tweakable, факт является ядром Linux, уже вполне прилично настраивается (Вашим распределением) для большинства пользовательских ситуаций.
-
1я утверждал бы что, если Вы хотите создать свое собственное ядро просто для полезного опыта, что Вы делаете это с основанным на источнике дистрибутивом Linux как хинду или Linux С нуля. Хинду документация установки этапа 2 является превосходным руководством по пониманию, что это означает создавать Linux из ядра. – Sandy 20.08.2010, 20:04
-
2Согласованный... те два проекта разрабатываются для этого типа вещи. – gabe. 20.08.2010, 21:08
-
3Конечно, Вы знаете о фактическом противоречии себе в своем ответе. Если бы единственное преимущество компиляции ядра должно было изучить, как сделать это, то это было бы бесполезно - не имеют никакого значения. Но затем несколько слов позже, Вы говорите это, являются ценной вещью... – rozcietrzewiacz 01.08.2011, 21:14
-
4@rozcietrzewiacz имеет предельную ценность. Компиляция ядра помогает Вам расширить свое знание. Если Вы не покупаете это, то вот это - знание - сила, и люди платят хорошие деньги для получения питания, и деньги содержат значение в современном мире, таким образом, переходным свойством.... :P – lunchmeat317 02.09.2011, 22:38
-
5, который я согласовываю, Это стоит того только для полученного знания. – 1100110 25.01.2012, 13:07
Большинство пользователей не должно компилировать свое собственное ядро, их распределение сделало эту работу для них. Обычно дистрибутивы будут включать ряд патчей для или интеграции с определенными частями способа, которым распределение работает, бэкпорты драйверов устройств и фиксирует от более новых, но невыпущенных версий ядра или функций, что они являются новаторскими со своими пользователями.
При компиляции собственного ядра у Вас есть несколько опций, можно скомпилировать ядро чиновника Linus Torvalds, это не будет включать ни одного из патчей или настроек, которые были добавлены распределением (который может быть хорошим или плохим), или можно использовать распределение, восстанавливают инструмент для создания собственного ядра.
Причины Вы могли бы хотеть восстановить свое ядро, включают:
- Исправление ошибок или добавление определенной опции к производственной системе, где Вы не можете действительно рискнуть обновлять целое ядро для единственной фиксации или два.
- Испытывать конкретный драйвер устройства или новую возможность
- Для расширения ядра работайте над ним
- тестирование некоторых "Альфа-" модулей или функций.
Многие разработчики используют его для создания также пользовательских версий ядра для встроенных систем или абонентских установок, где им нужны драйверы специального устройства, или они хотят удалить функциональность, в которой они не нуждаются.
-
1+1. Дети в эти дни, они даже не знают то, что 'делают menuconfig', означает и никогда не должен был исправлять их код сети ядра для предотвращения быть pwned деточками сценария. К счастью, тех дней главным образом не стало. – axel_c 21.08.2010, 02:21
-
2необходимо добавить
bisectлуг для нахождения, где ошибка была представлена... – xenoterracide 22.08.2010, 15:10 -
3, удивительный, как этот комментарий возрос проголосовавший, когда он не имеет никакого отношения к вопросу OP. "Большинство пользователей...." не продвигается теперь. Вопрос OP очень соглашается с желанием знать преимущества; не Ваше мнение о том, что "большинство пользователей" делает тут и там. – Eric 30.09.2010, 21:24
Компиляция ядра самостоятельно позволяет Вам только включать части, относящиеся к Вашему компьютеру, который делает это меньшим и потенциально быстрее, особенно во время начальной загрузки. Универсальные ядра должны включать поддержку как можно большего количества аппаратных средств; во время начальной загрузки они обнаруживают, какие аппаратные средства присоединены к Вашему компьютеру и загружают соответствующие модули, но это занимает время, чтобы сделать все это, и они должны загрузить динамические модули, вместо того, чтобы испечь код непосредственно в ядро. Нет никакой причины иметь Вашу поддержку ядра 400 различных центральных процессоров, когда существует только один в Вашем компьютере, или поддерживать мышей Bluetooth, если Вы не имеете один, это все потратило впустую пространство, которое можно освободить
-
1, который я согласовываю с большей частью Вашего ответа, но мне было бы любопытно для некоторых неопровержимых фактов о "значительно быстрее". Я не хотел бы производить новому пользователю впечатление, что их рабочий стол будет работать обычно быстрее с изготовленным вручную ядром (на основе моего опыта с хинду, это просто не верно). Можно ли определить количество усилений в скорости начальной загрузки? – Sandy 20.08.2010, 20:02
-
2Этот ответ был верен 15 лет назад, но это не действительно релевантно в эти дни. Большинство драйверов прибывает в модули так или иначе, таким образом, они только берут комнату на диске, не в памяти. (Или некоторые дистрибутивы все еще происходят без initrd? Без initrd ядро действительно должно включать все драйверы, которые оно, возможно, должно было бы загрузить.) Что касается времени начальной загрузки, несколько драйверов, которые тратят больше, чем миллисекунда, пытающаяся обнаружить несуществующие аппаратные средства, могут быть отключены с параметром загрузки ядра. – Gilles 'SO- stop being evil' 20.08.2010, 22:22
-
3@Michael, если это - непроверенное предположение, я думаю, заменяя "значительно быстрее" "потенциально быстрее" в Вашем ответе, могла бы быть хорошая идея... только, чтобы удостовериться, что № n00bs введен в заблуждение. :-) – Sandy 20.08.2010, 22:30
-
4@Sandy, так как похоже, что я - один из тех n00bs :). Зафиксированный – Michael Mrozek♦ 21.08.2010, 00:36
-
5я думаю "значительно" быстрее, на самом деле выравнивается по ширине с протестом, что мы говорим о времени начальной загрузки. Ядра дистрибутива запаса занимают легко 5 - 10 секунд дольше для начальной загрузки той, которую я разделил вниз для не поиска любых аппаратных средств, которые я не планирую на использовании. Скорость времени выполнения, вероятно, незначительна, я не могу на самом деле измерить это надежно. оценка – Caleb 18.06.2011, 00:03
Я не могу полагать, что принятый ответ здесь начинает говорить, что "Это не что-то, что необходимо сделать для большей скорости / память / xxx безотносительно".
Это полностью ложно. Я обычно сделанный на заказ мои Ядра обоим удаляю ненужный код, а также включая код улучшения производительности, главным образом связанный с аппаратными средствами. Например, я выполняю некоторые более старые аппаратные средства, и может eek некоторое увеличение производительности путем включения редко включаемых Драйверов ядра, таких как поддержка чипсета HPT36x на некоторых более старых MoBos, которые имеют это встроенное.
Другой пример, БОЛЬШОЙ SMP под Slackware является значением по умолчанию и на Dell 2800, например, использует большой след для выполнения вещей как GFSD (не как модуль ядра), который, также между прочим, использует галочки ЦП для чего-то, в чем я не нуждаюсь. Аналогично для NFSD и другого вместилища для угождения всех менталитетов, который прекрасен, если Вы просто пытаетесь получить Linux на поле и выполнении, но если Вы действительно заботитесь о "скорости / память / xxx безотносительно" затем эти вещи вопрос и работа.
Всеми моими производственными полями являются пользовательские Ядра. Если я нахожусь на общих аппаратных средствах, таких как серия Dell (2800, 2850, 2900, и т.д....) аппаратные средства, это - простой вопрос копирования .config файла ядра вокруг к каждому полю и компиляции ядра и установке.
-
1я думаю основной момент принятого ответа, - то, что для большинства аппаратных средств, производительность, полученная путем компиляции собственного ядра, не стоит времени, требуемого изучить, как сделать это (и изучить то, что опции означают). Это, вероятно, основано на опыте: было бы замечательно найти некоторые числа на этом. – Andres Riofrio 05.05.2012, 05:31
-
2хорошо затем, что это лицемерно, чтобы не указать это в исходном вопросе и затем принять ответ, который находится на основаниях, которые Вы утверждаете. – Eric 10.05.2012, 05:20
-
3Ну, это не мой отказ, мой ответ был принят. И в то время как да существуют случаи, где компиляция Вашего ядра поможет Вам "eek некоторая производительность" или встанет и работа машины низкой мощности, я сделал предположение, что исходный вопрос задавал кто-то, кто не имел определенной потребности заранее и был просто любопытен в общем смысле, каково преимущество компиляции ядра было. Я утверждал бы, что только люди с конкретными требованиями в памяти извлекают выгоду из тонких настроек ядра. Так как мой ответ был принят, я улучшу его для обращения к большему количеству причин продвинутого пользователя пользовательских ядер – gabe. 06.02.2014, 15:45
Вот некоторые ситуации, где компиляция Вашего собственного ядра принесет пользу Вам:
Ядро с отключенной загрузкой модуля более безопасно. Это потребует, чтобы Вы выбрали модули, Вы знаете, что нуждаетесь и включаете их как часть ядра, в противоположность компиляции их как модули.
Отключение поддержки/dev/kmem или нанесение вреда ему с соответствующим параметром компилятора являются хорошей вещью для безопасности. Я думаю, что большинство дистрибутивов делает это по умолчанию теперь.
Я предпочитаю не использовать initrd's, если это возможно. Настройка Вашего ядра к аппаратным средствам, от которых это загружается, устраняет initrd.
Иногда более поздняя версия ядра будет иметь функции, в которых Вы нуждаетесь, но это очень редко сегодня. Я помню, когда я сначала начал использовать Debian, он использовал 2,4 ядра, но мне были нужны 2,6 ядра для поддержки udev.
Отключение сетевых протоколов/опций, в которых Вы не нуждаетесь, может ускорить Вашу производительность TCP/IP.
Отключение опций, в которых Вы не нуждаетесь, понижает объем потребляемой памяти ядра, которое важно в низких средах RAM. Когда Вы используете систему RAM 256 МБ в качестве маршрутизатора, это помогает.
Я нахожу все "tty" устройства в/dev раздражении в системах, где я обычно только регистрируюсь на пути последовательный или ssh.
-
1Все верные. Однако удаление загрузки модуля может вызвать проблемы на начальной загрузке: большинство, если не все, дистрибутивы сегодня просто предполагают, что модули должны будут быть загружены. В прошлый раз, когда я выключил модули, это вызвало унылый перечень сообщений об ошибках к всплывающему во время процесса начальной загрузки Red Hat. – Mei 04.02.2012, 02:58
Компиляция Вашего собственного ядра позволяет Вам участвовать в процессе разработки ядра, является ли это простым материалом, таким как предоставление идентификаторов PCI/USB-устройства для существующего драйвера, который может заставить более новое устройство работать на Вас к связыванию глубоко с дракой базовой разработки ядра.
Это также позволяет Вам тестировать ядра разработки на своих аппаратных средствах и обеспечивать обратную связь, если Вы замечаете какие-либо регрессии. Это может быть особенно полезно Вам и другим, если у Вас есть редкая часть аппаратных средств. Если Вы ожидаете ядра дистрибутива, оно может занять время для мер от Вашей проблемы, сообщает для фильтрации в новый выпуск ядра дистрибутива.
Мне также лично нравится компилировать мои собственные ядра для включения поддержки только аппаратных средств, которые я имею. Когда Вы выполняете ядра дистрибутива и смотрите на вывод lsmod(8), Вы видите много модулей, загруженных для аппаратных средств, которые Вы не имеете. Это может загрязнить список модулей,/proc,/sys и Ваши журналы, таким образом что при поиске чего-то, которое он может быть скрыт среди шума; Вы также не можете быть на 100% уверены, что те модули не способствуют проблеме, которую Вы пытаетесь диагностировать.
Я ответ второго gabe. (мой комментарий является слишком длинным, таким образом, я отправляю как ответ).
Если у Вас нет узкоспециализированной цели (например, встроенные машины, строгое профилирование безопасности), я не вижу практического преимущества для компиляции Вашего собственного ядра кроме видеть, как это сделано. Путем методического рассмотрения опций наблюдения то, как они взаимодействуют друг с другом для создания системы, является отличным способом понять, как система работает. Удивительно, что Вы узнаете, когда Вы пытаетесь удалить компоненты, которые, кажется, не имеют цели для задач, которые Вы пытаетесь выполнить.
Предупредите однако - почему спрыгивающий от кроличьей норы является, несомненно, волнующим, она высосет назад больше ночей и выходных, чем Вы думали возможные!
На работе мы используем скрученные вручную ядра для применения патчей из дерева, таких как vserver и unionfs.
Дома, я компилирую скрученные вручную ядра для нахождения, какая фиксация представила ошибку, которую я испытываю. После того как я закончил это, я буду, вероятно, придерживаться скрученного вручную ядра, пока ошибка не будет исправлена в моем распределении (Debian), в которой точке я вернулся бы к их ядрам снова.
Для большей части использования универсальные ядра хороши для фактически любых аппаратных средств. Дополнительно они обычно содержат (редактор), определенные для распределения патчи, настолько компилирующие Ваше собственное ядро, могут (мог) бы вызвать проблемы.
Причина скомпилировать Ваше собственное ядро:
- Вы используете основанный на источнике дистрибутив, таким образом, нет никакого 'универсального' ядра
- Вы - разработчик ядра, и Вы разрабатываете ядро
- Необходимо настроить ядро, например, для встроенного устройства с очень ограниченным жестким диском
- Некоторый драйвер не компилируется в (очень редком случае)
- Вы хотите исправить ядро, И Вы знаете то, что Вы делаете
- Вы хотите изучить, как скомпилировать ядро
Если бы я не использовал основанный на источнике дистрибутив, то я не скомпилировал бы ядро вообще.
Другой случай помимо многих, упомянутых здесь для того, чтобы иметь пользовательские скомпилированные ядра, настраивает специализированные среды сетевой загрузки, где загрузка модуля не выполнима, и необходимо раздать полностью рабочие ядра к определенным машинам для определенных задач.
Я удивлен, что об этом никто не упомянул причина для компиляции собственного ядра:
потому что вы хотите использовать другой компилятор C / c ++. GCC очень хорош для компиляции ядра Linux. Но есть компиляторы намного лучше! Оптимизация GCC немного отстает от компилятора Intel C / C ++. Кроме того, Intel предоставляет библиотеки примитивов производительности и инструмент vtune, которые незаменимы при создании высокопроизводительного ядра Linux. Вы можете продвинуться так далеко только с GCC и G ++. Практически независимо от того, что вы делаете, результат будет ограничен компилятором. Итак, я использую компилятор Intel и библиотеки производительности. Он немного велик - загрузка 1,5 ГБ, но это дает некоторое представление о том, что все содержится в хорошем компиляторе.
Компилятор Intel C / C ++ доступен бесплатно для некоммерческого использования. Но проще найти в Google страницу загрузки компилятора Intel c ++ с некоммерческой лицензией, чем искать на сайте Intel. Обычно я ни для чего не использую GCC / G ++. И вам не нужно быть программистом. Вы просто устанавливаете свою среду и изменяете две строки в файле make, чтобы они указывали на компилятор Intel.
Тогда вы сможете набрать серьезную скорость!
Эта ветка устарела, но все еще актуальна сегодня, как и тогда, когда был задан вопрос!
Ответ: :Вы компилируете ядро Linux по вашему выбору в соответствии с вашими потребностями и требованиями.
Допустимы многие сценарии:
Вы инженер и требуете, чтобы ваша сборка соответствовала требованиям/требованиям производительности и безопасности для вашей системы, вы перекомпилируете, чтобы соответствовать и/или превзойти указанные критерии.
Вы обычный пользователь и у вас есть старая система, которую вы хотите поддерживать как можно дольше, вы перекомпилируете, добавляя/удаляя компоненты, чтобы ваша старая система оставалась оптимизированной.
Вы обычный пользователь с новейшим быстрым оборудованием и более чем достаточным объемом памяти/ОЗУ. Нет необходимости перекомпилировать, но вы все равно можете это сделать, если хотите узнать немного больше о своей системе.
Вы просто хотите быть похожим на обычного пользователя Microsoft и/или Mac, не перекомпилируйте и просто установите обновления из исходного дистрибутива.
Следите за сценариями:-)
В отличие от пользователей Mac/Windows, Linux предоставляет выбор. Выбор между упрощением или оптимизацией системы в соответствии с вашими требованиями.