К центру ядра…

О компиляции ядра Linux написано много. Очень много. Зачастую при путешествии по линуксовым сайтам даже создается впечатление, что в ней, родимой, и заключена цель установки оной системы.

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

Ныне большинство дистрибутивов устанавливается с ядрами, поддерживающими работу всех обычных (а иногда и экзотических) устройств. В результате пользователь сразу получает систему, пригодную к употреблению. Конечно, за все приходится платить. В том числе и тем, что ядра (как и сами дистрибутивы, к слову сказать) разбухают, включая в себя поддержку массы устройств, у среднестатистического пользователя обычно отсутствующих. Что, как пугают знатоки, чревато снижением и устойчивости, и быстродействия.

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

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

Процесс переустановки ядра распадается на три стадии: установка исходников, конфигурирование и собственно компиляция и установка. О первой и последней говорить не буду за их тривиальностью и документированностью. Под конфигурированием же ядра понимается включение или, напротив, отключение поддержки всякого рода устройств, файловых систем и прочего, для чего в Linux предусмотрено три средства, основанных на стандартной программе make.

Первое - make config, мрачноватая текстовая утилита, задающая в интерактивном режиме множество вопросов, смысл которых, IMHO, далеко не всегда кристально ясен. Правда, ответив вопросом (?) на вопрос, можно получить комментарий по поводу данной опции. Однако лучше, прежде чем приступать к конфигурированию, обзавестись какой-нибудь справочной литературой.

На другом полюсе - средство под именем make xconfig. Это, напротив, графическая оболочка, запускаемая из X Window. Здесь группы вопросов о конфигурации оформлены в виде кнопок, нажатие на которые вызывает панели с дополнительными вопросами (рис. 1). Работать с ней, вероятно, удобнее, но графический режим может показаться нежелательным в столь тонком вопросе.

На мой взгляд, целесообразнее прибегнуть к промежуточному варианту - средству make menuconfig, имеющему псевдографическое меню (рис. 2). Make menuconfig позволяет вернуться к уже пройденным вопросам и внести коррективы, а главное - одним взглядом окинуть весь круг родственных тем, что бывает не лишним.

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

Вероятно, оба тезиса имеют под собой основания, но мне они кажутся не вполне оправданными. Первый - в гносеологическом аспекте: если доверять, не проверяя, умолчаниям, непонятные опции так и останутся непонятными. Второй же тезис не оправдан технологически: ведь повышение быстродействия системы - одна из целей перегенерации ядра, не правда ли?

Я, напротив, предложил бы (при наличии толики времени и любопытства) иной подход: безжалостно исключить поддержку всех отсутствующих устройств и всех непонятных опций. Ведь они, как правило, потому и непонятны, что отвечают за устройства, которых нет, которые не нужны или не используются. Что может грозить в этом случае? - Ядро откажется компилироваться, или при сборке модулей последует сообщение об ошибке. И то и другое не страшно: внимательно читая сообщения, выводимые на экран, причину сбоя можно локализовать, а затем вернуться к конфигурированию и внести коррективы.

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

Впрочем, все указанные риски можно свести к минимуму, если воспользоваться конфигурационными файлами, следующими с исходниками как образцы. К большинству дистрибутивов прилагается достаточно широкий их выбор - и для различных процессоров (от абстрактного i386 до Pentium 4 и Athlon), и разной степени продвинутости с точки зрения полноты опций. Главное - соблюдать последовательность и методичность. Многие опции, причем рассеянные по разным группам, взаимно связаны между собой, и отключение одной может вызвать неработоспособность прочих.

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

[i40832]