я таки подозревал, что придётся "ответ держать". извольте.
спрашивали?
Attila комментирует...
А вот почему бы не вкомпилить модули, необходимые для работы жёсткого диска, сетевой карты, корневой файловой системы и т.п монолитно? Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти.
Всё в ядре и вообще никакой мороки с модулЯми?
отвечаем...
любое подобное "включение" приводит к снижению уровня "гибкости" системы. начиная от банальной потери возможности передать модулю какие-то параметры при загрузке и заканчивая тупой аксиомой - "а яго ужо не выгрузишь". примерно процитирую высказывания с LDP о преимуществах использования модулей:
1) нет нужды пересобирать каждый раз ядро;
2) любой баг в ядре гораздо труднее отследить, чем баг в модуле;
3) любой баг в модуле менее критичен, чем баг в самом ядре и отслеживается в разы быстрее (спорно, но это правда);
3) более оптимальное использование памяти компьютера;
4) нет прироста в производительности при жёстком включении.
с учётом вышесказанного никакого смысла нет в ядро пихать даже драйвер корневой файловой системы - Initial Ramdisk придумали явно не зря, не так ли?
морока именно имеет место быть, когда люди от большого ума пытаются засунуть в ядро абсолютно лишние компоненты. история из реальной жизни. один знакомый молодой человек, начитавшись статей многоуважаемого г-на Федорчука, решил поставить себе на ноут Zenwalk. да только не обратил, сердешный, внимания в пылу энтузиазма на фразу: "В Zenwalk функции управления тактовой частотой ноутбучных процессоров вкомпилированы в ядро, а не собраны с виде модуля, как это делается обычно. Поэтому, если обладателя двухгигарецового процессора раздражает работа на тактовой частоте 800 Mhz (а меня, например, это раздражает весьма сильно), то придется пересобирать ядро, чем я намерен заняться в ближайшее время." очень интересная фраза... я буду весьма признателен, если кто-нибудь мне объяснит необходимость пересборки ядра в данном случае. необходимо и достаточно поставить пакет "cpufrequtils" и ознакомиться с man-страницей или просто разобраться в схеме управления параметрами ядра через /proc, /sys. в нашем же случае всё было с точностью до наоборот. ядро Zenwalk-а раскочегарило "Кору-дуру" так, что вентиляторы были готовы "рвануть в небо", а на клавиатуре можно было еду разогревать. пакета "cpufrequtils" знакомый не нашёл (что не повод делать выводы, хотя...), посему тупенько через /sys выставили дефолтный cpu governor на ondemand. и всё. "сковородочка стала остывать".
включение в ядро только минимума стимулирует "любознательность" не в пример сильнее, чем безалаберное пихание в него чего ни попадя. да и на будущее в разы полезнее.
отдельно выделим фразу: "Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти". а вот в компании Red Hat в "Red Hat Enterprise Linux 4: Руководство по системному администрированию" считают иначе:
"Ядро Linux имеет модульную структуру. При загрузке в память загружается только минимальное резидентное ядро. После этого, если пользователь вызывает функцию, отсутствующую в резидентном ядре, нужный модуль ядра, иногда называемый драйвером, динамически загружается в память."
правда на правду? или всё же RTFM? что и находит подтверждение в LDP: "LKMs did not exist in Linux in the beginning. Anything we use an LKM for today was built into the base kernel at kernel build time instead. LKMs have been around at least since Linux 1.2 (1995)." то бишь с 1995-го года ядро имеет "модульную структуру", а мы всё заикаемся о "некоторой поддержкой модульнотсти" и рвёмся "придется пересобирать ядро, чем я намерен заняться в ближайшее время". вот это и называется "Пиздец", господа, и именно с большой буквы "П".
Показаны сообщения с ярлыком kernel. Показать все сообщения
Показаны сообщения с ярлыком kernel. Показать все сообщения
четверг, 1 ноября 2007 г.
среда, 31 октября 2007 г.
Взгляд ушастого ламера на компиляцию ядра из исходников...
приветствуются любые замечания, предложения, дополнения и т.п.. тема заезжена, ни на какую оригинальность сей опус не претендует, но, может кто найдёт сей метод более удобным, поскольку он предполагает довольно быстрый и удобный способ модификации конфига.
какие могут быть причины для подобного шага? их всего три:
1) использование новых функций, отсутствующих в текущем ядре дистрибутива;
2) оптимизация под текущую конфигурацию "железа";
3) если установлено специфичное оборудование или возникает конфликт аппаратного обеспечения со стандартным ядром
вторая причина довольно неоднозначна, ибо эффект от модернизации самого железа, который достигается за, не побоюсь этого слова, копейки, в разы перекроет любую оптимизацию программного обеспечения. но она же подразумевает сборку ядра без лишних компонентов/модулей, что оправдано для ряда специализированного оборудования. всё остальное - не серьёзно. можно заниматься этиим ради удовлетворения собственного любопытства, можно экспериментировать с флагами опримизации, можно... можно даже встать на уши, разогнаться и впечататься в ближайшую стену - гулять так с музыкой... третью причину ранее смело выносили на первое место, да времена ужо не те.
нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый diff файл или тянуть десяток мегабайт кем-то скомпиленного готового ядра? это справедливо для любых "крупных" пакетов, будь то OpenOffice, kernel, E17 :).
ещё один спорный момент: монолит или модульное? на ваше усмотрение, господа присяжные заседатели. с точки зрения "ламера ушастого" - монолит ноне не нужен.
что нам понадобится из "инструментария":
Meld
( пользователи SuSE имеют в "загашнике" JMeld )
и конфиг ядра дистрибутива, работающего в данный момент (стоит ли напомнить, что желательно иметь одинаковую major версию ядра - например 2.6.*?). предположим, что конфиг вкомпилен в ядро и его можно "достать" командой:
zcat /proc/config.gz
что мы и делаем в качестве нашего первого шага:
zcat /proc/config.gz > /home/USER/config_current
распаковываем исходники нового ядра и выполняем:
make menuconfig
затем выбираем опцию: "Load an Alternate Configuration File" -> /home/USER/config_current
тем самым загружая текущую конфигурацию ядра. после сразу же делаем:
"Save an Alternate Configuration File" -> /home/USER/config_new
всё, что нам осталось сделать, это пройтись meld-ом по этим двум файлам (config_current и config_new) и сформировать наш будущий конфиг с учётом всех новых опций, загрузив его уже известным "Load an Alternate Configuration File". если есть сомнения в параметрах новых опций - ставим "=m", видим явно лишнюю опцию - комментируем, ставя в начало строки "#". желаете описание каждой опции в параметрах конфигурации ядра - читайте документацию. основное правило: в ядро - только необходимый минимум, всё, что только можно, - вынести в модули. именно при таком подходе можно получить выигрыш во времени как при старте системы (подгружая только необходимое), так и по использованию памяти самим ядром.
N.B. товарищ, помни: "автоматом" подгрузить модуль можно, но выгрузить - только "вручную" (как вариант - использовать скрипты-"обвязки").
дальнейшие команды по сборке и установке нового ядра (make dep && make clean успели устареть):
make
make modules
sudo make modules_install
sudo make install
необязательные (но иногда крайне полезные) команды, выполняемые после установки (но до перезагрузки). если внимательно смотреть на вывод предыдущих 2-х команд, то в них нужды особой нет (так как именно они и выполняются в процессе), хотя...:
sudo depmod -a
(sudo depmod -aq)
смотрим на вывод команды и проверяем, какие модули будут активированы при загрузке того или иного установленного в системе ядра и собственно проверяем корректность .map файла нового ядра. эта каманда позволит сравнить загружаемые модули вашего старого/(старых) и только что установленного нового кернела. излишне пожалуй говорить, что практически все проблемы разряда "сабрал новае видро а ано нигрузиццо..." могут/должны быть устранены на этой стадии.
в зависимости от системы можно (естественно при желании) пересобрать Initial RAM Disk командами "mkinitrd" или "mkinitcpio" (обратите внимание на /etc/mkinitcpio.conf !!! отсутствие необходимых опций в нём может привести к провалу при загрузке нового кернела) - читайте справку по опциям. приведу для примера свой /etc/mkinitcpio.conf:
MODULES="pata_via sata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"
сие означает, что на чипсете VIA имею IDE и SATA винты, плюс пользую reiserfs. основная же нагрузка падает на HOOKS. для понимания оных - читайте доки и комментарии в самом /etc/mkinitcpio.conf (мне хватило комментариев).
на закуску - несколько интересных статей в продолжение темы:
Ядерная физика для домохозяйки
ещё одна абсолютно чумовая статейка с использованием временных "рэперов" и живым примером перехода от 2.4 до 2.6:
Установка ядра linux-2.6.1 (вместо 2.4.x)
намеренно не затронут вопрос модификации загрузчика (внесения нового ядра в список оного) - ибо пошло и неинтересно.
какие могут быть причины для подобного шага? их всего три:
1) использование новых функций, отсутствующих в текущем ядре дистрибутива;
2) оптимизация под текущую конфигурацию "железа";
3) если установлено специфичное оборудование или возникает конфликт аппаратного обеспечения со стандартным ядром
вторая причина довольно неоднозначна, ибо эффект от модернизации самого железа, который достигается за, не побоюсь этого слова, копейки, в разы перекроет любую оптимизацию программного обеспечения. но она же подразумевает сборку ядра без лишних компонентов/модулей, что оправдано для ряда специализированного оборудования. всё остальное - не серьёзно. можно заниматься этиим ради удовлетворения собственного любопытства, можно экспериментировать с флагами опримизации, можно... можно даже встать на уши, разогнаться и впечататься в ближайшую стену - гулять так с музыкой... третью причину ранее смело выносили на первое место, да времена ужо не те.
нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый diff файл или тянуть десяток мегабайт кем-то скомпиленного готового ядра? это справедливо для любых "крупных" пакетов, будь то OpenOffice, kernel, E17 :).
ещё один спорный момент: монолит или модульное? на ваше усмотрение, господа присяжные заседатели. с точки зрения "ламера ушастого" - монолит ноне не нужен.
что нам понадобится из "инструментария":
Meld
( пользователи SuSE имеют в "загашнике" JMeld )
и конфиг ядра дистрибутива, работающего в данный момент (стоит ли напомнить, что желательно иметь одинаковую major версию ядра - например 2.6.*?). предположим, что конфиг вкомпилен в ядро и его можно "достать" командой:
zcat /proc/config.gz
что мы и делаем в качестве нашего первого шага:
zcat /proc/config.gz > /home/USER/config_current
распаковываем исходники нового ядра и выполняем:
make menuconfig
затем выбираем опцию: "Load an Alternate Configuration File" -> /home/USER/config_current
тем самым загружая текущую конфигурацию ядра. после сразу же делаем:
"Save an Alternate Configuration File" -> /home/USER/config_new
всё, что нам осталось сделать, это пройтись meld-ом по этим двум файлам (config_current и config_new) и сформировать наш будущий конфиг с учётом всех новых опций, загрузив его уже известным "Load an Alternate Configuration File". если есть сомнения в параметрах новых опций - ставим "=m", видим явно лишнюю опцию - комментируем, ставя в начало строки "#". желаете описание каждой опции в параметрах конфигурации ядра - читайте документацию. основное правило: в ядро - только необходимый минимум, всё, что только можно, - вынести в модули. именно при таком подходе можно получить выигрыш во времени как при старте системы (подгружая только необходимое), так и по использованию памяти самим ядром.
N.B. товарищ, помни: "автоматом" подгрузить модуль можно, но выгрузить - только "вручную" (как вариант - использовать скрипты-"обвязки").
дальнейшие команды по сборке и установке нового ядра (make dep && make clean успели устареть):
make
make modules
sudo make modules_install
sudo make install
необязательные (но иногда крайне полезные) команды, выполняемые после установки (но до перезагрузки). если внимательно смотреть на вывод предыдущих 2-х команд, то в них нужды особой нет (так как именно они и выполняются в процессе), хотя...:
sudo depmod -a
(sudo depmod -aq)
смотрим на вывод команды и проверяем, какие модули будут активированы при загрузке того или иного установленного в системе ядра и собственно проверяем корректность .map файла нового ядра. эта каманда позволит сравнить загружаемые модули вашего старого/(старых) и только что установленного нового кернела. излишне пожалуй говорить, что практически все проблемы разряда "сабрал новае видро а ано нигрузиццо..." могут/должны быть устранены на этой стадии.
в зависимости от системы можно (естественно при желании) пересобрать Initial RAM Disk командами "mkinitrd" или "mkinitcpio" (обратите внимание на /etc/mkinitcpio.conf !!! отсутствие необходимых опций в нём может привести к провалу при загрузке нового кернела) - читайте справку по опциям. приведу для примера свой /etc/mkinitcpio.conf:
MODULES="pata_via sata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"
сие означает, что на чипсете VIA имею IDE и SATA винты, плюс пользую reiserfs. основная же нагрузка падает на HOOKS. для понимания оных - читайте доки и комментарии в самом /etc/mkinitcpio.conf (мне хватило комментариев).
на закуску - несколько интересных статей в продолжение темы:
Ядерная физика для домохозяйки
ещё одна абсолютно чумовая статейка с использованием временных "рэперов" и живым примером перехода от 2.4 до 2.6:
Установка ядра linux-2.6.1 (вместо 2.4.x)
намеренно не затронут вопрос модификации загрузчика (внесения нового ядра в список оного) - ибо пошло и неинтересно.
четверг, 25 октября 2007 г.
Kernel 2.6.23
начитавшись страшилок и пару раз обжёгшись "иду на второй круг"... и сразу же "по полной программе" - ибо к чёрту полумеры:
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
(это значит, что переходим на новый диспетчер управления ресурсами и сажаем "под капот" сразу 1000 лошадей :)). запущены: сборка kernel26 2.6.23.1-4, сборка E17-го, OOo, mpd, mplayer, xmms, ffmpeg потрошит авишку, плюс до кучи демонов и служб. имеем (может не совсем удачно, но общий смысл предельно ясен):
top - 21:54:24 up 1:25, 0 users, load average: 3.06, 2.68, 2.39
Tasks: 120 total, 7 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 73.4%us, 25.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Mem: 1035436k total, 984068k used, 51368k free, 73564k buffers
Swap: 2104472k total, 4k used, 2104468k free, 620396k cached
тормозов и заиканий нет.
из приятного - CONNLIMIT таки внесли в исходники (теперь можно не извращаться с глобальным ограничением количества соединений с одного IP-а). на запись правда примонтировать партицию Mac OS X не рискнул (бэкап староват для такого развлечения).
вердикт: must have! что по-русски значит - все на kernel.org за исходниками!
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
(это значит, что переходим на новый диспетчер управления ресурсами и сажаем "под капот" сразу 1000 лошадей :)). запущены: сборка kernel26 2.6.23.1-4, сборка E17-го, OOo, mpd, mplayer, xmms, ffmpeg потрошит авишку, плюс до кучи демонов и служб. имеем (может не совсем удачно, но общий смысл предельно ясен):
top - 21:54:24 up 1:25, 0 users, load average: 3.06, 2.68, 2.39
Tasks: 120 total, 7 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 73.4%us, 25.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Mem: 1035436k total, 984068k used, 51368k free, 73564k buffers
Swap: 2104472k total, 4k used, 2104468k free, 620396k cached
тормозов и заиканий нет.
из приятного - CONNLIMIT таки внесли в исходники (теперь можно не извращаться с глобальным ограничением количества соединений с одного IP-а). на запись правда примонтировать партицию Mac OS X не рискнул (бэкап староват для такого развлечения).
вердикт: must have! что по-русски значит - все на kernel.org за исходниками!
Подписаться на:
Комментарии (Atom)
