UnixMountainSkiFun

Unix Горы Лыжи

29-05-2008 16:36

Достижение комфорта с исходным кодом


Трудность: 3 (требуется средний уровень в Linux)

"Just compile it!" ("Просто откомпилируй!") -- это слоган, который вы наверняка никогда не увидите в компании, сшибающей деньги, или по крайней мере, не на данный момент, когда склад готовой продукции находится в сортире, а большинство dot-коммерсантов, те что продают товар через Internet, не могут позволить себе даже пачки Доширак. Однако еще одной причиной, по которой такой вы никогда не увидите подобный слоган, может являться следующее:

Слоганы всякого рода компаний (Shoe company, Прим.переводчика: Компании, которые устраивают конкурсы на слоганы по рекламе ботинок, соков "Моя семья" и проч.) чаще всего призывают нас делать какие-то странные трудновыполнимые вещи. Они желают, чтобы мы сломя голову неслись в какие-то странные, закупоренные места и сидели там как цуцики, или вообще состязались как в Формуле-1 (со светофорами и постоянно мотаясь на огромной скорости по кругу). Боюсь, я человек не такого сорта. Когда я хочу погонять на машинках, то играю в тот или иной вариант "Need for Speed". А когда попадаю странные, закупоренные места, то я трачу время на удовольствие поглазеть по сторонам. Отчего-то мне кажется, что мне не понравится вкалывать на поприще "TV-коммерции".

Вот почему я все чаще призываю людей -- "Just compile it!". Это проще, даже чем использование чего-нибудь типа RPM (менеджер пакетов RedHat, -- утилита, которая предполагаемо прекрасно работает, но на практике у меня всегда с ней проблемы). Почти каждый GPL-проект, который бы я не загружал, с легкостью конфигурируется и компилируется, без какого либо нейронного разряда (neuronal discharge) с моей стороны (нейронный разряд это мизерная величина, -- для тех, кто не знаком с медицинской терминологией). Поверхностное изучение файла README обычно информирует меня, какие пакеты требуются для этого пакета, где их можно найти, и в конце концов, какие команды должны быть использованы для конфигурирования, компиляции и инсталляции пакета.

Я могу посветить целую главу тому, почему я не люблю RPM, однако вместо этого подытожу все в одну фразу -- большинство людей, которые формируют RPM-пакеты, чрезвычайно небрежны. Они требуют, для устанавливаемого вами RPM-пакета, всякого рода прочие пакеты, большинства из которых не требуется вовсе. RedHat, Mandrake, и TurboLinux должны стыдиться. Инсталляция одного из их .rpm-файла, несомненно приведет вас на край сумасшествия по той причине, что он потребует чуть ли "не каждой твари по паре" со всего света. SuSE будет несколько умнее. В списке зависимостей каждого пакета этого дистрибутива только те пакеты без которых не обойтись. И как результат, я использую некоторые .rpm файлы от SuSE. К сожалению SuSE прекратил распространение бесплатных iso-образов своего Linux-дистрибутива. Однако я отвлекся.

Примечание: ISO -- это сокращение International Standards Organization (Организация Международных Стандартов). В данном случае это частое употребляемое сокращение термина ISO-9660, -- стандарта файловой системы CD-ROM. В данном контексте "iso" -- это образ CD-ROM, который может быть загружен и "прожжен" на CD-R или CD-RW. См. Главу 18?.

Чувство комфорта в компиляции и инсталляции исходного кода сродни способности заправить маслом и антифризом свою собственную машину -- такое умение не обязательно, однако может упростить вашу жизнь, и несомненно даст более ясное понимание того, как работает ваш компьютер.

Компиляция ядра с нуля это одна из моих фобий. Я поместил статью на эту тему в online -- http://www.jurai.net/~patowic/computer/pre-kernel.html (Прим.переводчика: я обнаружил, что статья "переехала" на новое место -- http://www.angelar.com/~jeremy/computer/linux/pre-kernel.html)

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

Как минимум раз в неделю я отвечаю на вопрос "Почему я не должен использовать прекомпилированное ядро?". Это простой вопрос, с предельно простым ответом.

И короткий ответ таков -- не доверяйте вашему производителю дистрибутива (vendor).

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

Исходя из этой потребности растет количество модулей ядра, которые дают возможность добавлять код в ядро "на лету". Это действительно великолепно для большинства систем. Но это не так выгодно для Ивана Ивановича Иванова. Иван Иванович Иванов, как вы уже наверное понимаете, не так уж часто изменяет аппаратное обеспечение своего PC. Он как правило собирает свой компьютер сам, и, сам же, инсталлирует операционную систему. В идеале, он должен знать о том, что собственно имеется в его компьютерной системе.

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

Помимо скорости необходимо также принимать во внимание безопасность. RedHat пользуется дурной славой из-за того, что оставляет огромные дыры в безопасности, на протяжении всех его дистрибутивов. Ядро этого дистрибутива не исключение. Припомним историю, -- они оставляли включенными опции отладки во всех ядрах. Этой особенностью пользовалось менее 1% пользователей Linux, однако эта особенность открыла дыру наружу. Вот это и есть то, что большинство пользователей называют словом "плохо".

Upgrade ядра должен выполняться в известной степени регулярно. Когда выпускаются новые ядра, смотрите на их особенности и исправления ошибок, которые они предлагают. На основании этой информации решайте сами использовать ли такое ядро. Когда было выпущено ядро 2.2.16, исправляющее некоторую большую дыру в безопасности, которая существовала во всех предыдущих версиях, прошла неделя, прежде чем основные поставщики (vendors) предоставили новые ядра для upgrade. А я обновил все мои машины за какой-то час, после того как услышал о анонсе ядра -- и это все потому, что я строю свои собственные ядра.

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

Теперь вы понимаете почему я не люблю предкомпилированные ядра. Считаю, что это касается практически каждого прекомпилированного программного обеспечения. Лучше уж я скачаю исходный текст, откомпилирую его самостоятельно, а затем буду им пользоваться.

Компиляция программного обеспечения

Компиляция программного обеспечения под Linux как правило следует одному из трех шаблонов: autoconf, makefiles, и imakefiles. Перед тем, как мы рассмотрим каждый из них, я хочу отметить общие для каждого из них черты. В любом из случаев, должны быть внимательно прочитаны файлы INSTALL и README. В этих файлах вы несомненно найдете ответы на любой возникший вопрос. Конфигурация и компиляция должна выполняться под обычной учетной записью, и только инсталляция выполняется от имени root.

Старайтесь избегать от использования учетной записи root, когда это возможно. Учетная запись root -- это Магнум калибра .44 вашего Linux-компьютера. Взлом обычной учетной записи может быть болезненен. Взлом же учетной записи root весьма критичен.

Я храню все исходники в ветке /usr/src. Это вполне логичное место, оно позволяет помочь мне содержать мой домашний каталог в порядке. Файлы, которые оканчиваются на .tar.gz, либо .tgz, либо .tar.bz2 обычно называют tarballs или тарболами. Вот так вот! Это действительно настоящее слово (по крайней мере в мире Unix). Tar это Tape ARchival (программа, для архивирования на ленту), которая существует с незапамятных времен и является стандартом де-факто, для распространения не-RPM файлов. Заметим, что RPM-файлы используются только в RedHat и его производных, именно поэтому вы не найдете RPM для SlackWare, OpenBSD или FreeBSD. Опля, мы же говорим о Linux? Короче говоря, просто выбросьте из головы последние два названия (по крайне мере на некоторое время).

Imakefiles

Разработан специально для X Windows. Единственный пакет, который я собирал в своей практике с использованием Imake, это был XFree86. Он был нацелен на то, чтобы стать платформеннонезависимой версией make, однако на практике так и не стал ей. Imake четко и ясно описан в одной из книг O'Reilly, которую я никогда не читал, и, как мне кажется, не я один. Это сложный инструмент, весьма отличающийся от других подобных, и Gnu Autoconf достиг больших успехов в том, что требуется от такого рода программ. Более того, даже сам XFree86 на данный момент может быть собран вовсе без использования Imake -- загрузите исходный код, и выполните "make World" в корневом каталоге пакета.

Обычный Makefile

Даже простейший make-файл (прим.перев.: в книге употребляется идиома: Plain-Jane make files. Фраза Plain-Jane обясняется следующим образом: She is homely and simple, just a plain Jane) может требовать модификации для компиляции на вашей системе. Для начала просто попробуйте посмотреть как это работает: 

 tar zxvf mypackage.tar.gz
 cd mypackage
 more README
 more INSTALL
 [make config]
 make
 su -c "make install"
 make clean

И, как обычно, мы сначала читаем инструкции, и помним, что /usr/src, то самое место где лучше всего держать исходный код. Следующий шаг, make config, необязателен. Многие пакеты не используют его. Но некоторые используют. А некоторые используют вообще другой подход, обо всем этом сказано в файлах README и INSTALL. Шаг make config в общем означает то, что вам зададут различные вопросы. И вы должны дать правильные ответы (например, может быть такой вопрос: "Где располагается md5sum?"), иначе компиляция закончится ошибкой.

Для пакетов, которые не имеют config-опции, и которые сразу не получается откомпилировать, вам придется открыть в редакторе Makefile и разобраться с переменными, которые могут быть изменены. Скорее всего это будет что-то незначительно, вроде указания пути к бинарному файлу. Кроме того будет полезным просмотреть Makefile, чтобы выяснить куда предполагается поместить откомпилированный бинарный код. Главная проблема с Makefile состоит в том, что он требует либо глубокого понимания Makefile (которое имеют, как мне кажется, не так много людей), либо общения по e-mail с лицом, поддерживающим этот пакет. Последнее в общем-то даже предпочтительнее, так как если это действительно ошибка в Makefile, то главный разработчик должен быть в курсе событий. Тем не менее, не поднимайте ложную тревогу, будьте вежливы когда общаетесь с разработчиком по e-mail.

Autoconf

Gnu autoconf одна из наиболее искусных частей программного обеспечения, из имеющихся в наличии. В общих чертах, это способ, которым пакет программного обеспечения может задать сотни вопросов вашей системе, причем спросить систему напрямую. Программа configure, которую и использует autoconf, проверяет местоположение бинарного кода, проверяет режимы компилятора... разве что не почесывает вам спину. Пакет Autoconf на самом деле очень и очень приятен и полезен для компиляции, особенно если сравнивать результаты его работы против ручного редактирования Makefile.

Типовая картина для пакетов, использующих autoconf: 

 tar zxvf myswfr2.tar.gz
 cd mysfwr-2
 more README
 more INSTALL
 ./configure --help
 ./configure [options]
 make
 su -c "make install"
 make clean

Обратите внимание на [options] -- многие пакеты, использующие autoconf, имеют огромное количество разношерстной информации, которую можно вручную передать скрипту configure. Зачастую можно попросту игнорировать эти опции, однако их использование позволяет получить явную выгоду. Так, например, в пакете XMMS (Кроссплатформенная мультимедийная система), есть ключи, которые позволяют включить 3DNOW! оптимизацию, превосходно работающую на процессорах Athlon, Duron, K6, K6/2, K6-III, но полностью бесполезную на кристаллах Intel или Cyrix. Вот пример использования некоторых опций коммандной строки для скрипта configure: 

 tar zxvf xmms-1.2.4.tar.gz
 cd xmms-1.2.4
 ./configure --with-x --enable-3dnow
 make
 su -c "make install"
 make clean

Просто, не так ли? Однако проницательный читатель отметит, что я включил еще и поддержку X-windows. Все эти флаги рознятся от пакета к пакету, поэтому использование configure --help, -- единственный способ (исключая конечно же чтение документации) понять, что означает каждая из опций.

Если что-то не дает вам откомпилировать пакет успешно и требуется перезапустить configure, то убедитесь, что стерли результаты предыдущей неудачной попытки! Они хранятся в файлах config.cache или .config.cache, -- эти файлы должны быть удалены, прежде чем вы снова запустите configure.

Как собрать свое собственное ядро

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

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

Файл /etc/lilo.conf

Следующие строки относятся, к сожалению, только к Linux, работающем на процессорах Intel. Мне нравится предоставлять равные сведения о всех платформах, однако Intel-компьютеры, это единственная платформа, на которой я работал с Linux. Помимо этого, большей части читателей книги наверняка доступны только Intel-компьютеры. И по этим причинам мы будем следовать стадному принципу, и опишем платформу "Lintel". Необходимо предупредить, что Linux на Alpha, PowerPC, Sparc или другой процессорной платформе будет иметь сходные структуры и возможности, но тем не менее это не одно и то же.

Каждый дистрибутив Linux, с которым я знаком, по умолчанию использует загрузчик (boot loader) LILO. Что такое загрузчик? Возможно вам это не известно, однако PC имеет две невидимые программы. Они не представлены файлами и не видны в структуре каталогов. Одна из них возможно вам известна. И называется она -- BIOS, что происходит от basic input/output system (основная система ввода/вывода), которая "прошита" (или "профлэшена", если это современный PC) в отдельной микросхеме на материнской плате. Другой программой является загрузчик.

Когда BIOS запускается, то она знает как найти особый небольшой участок диска, называемый superblock (суперблок). Superblock содержит две важные вещи. Первой является partition table (таблица разделов). Другой -- небольшая область данных, называемая master boot record (главная загрузочная запись) или MBR.

BIOS считывает данные из MBR, в определенное место в оперативной памяти (RAM), а затем выполняет инструкции, сохраненные в RAM. Вы можете написать свою собственную маленькую ассемблерную программу, и поместить ее в MBR, на своем жестком диске, после этого ваш компьютер будет в состоянии выполнять только эту вашу маленькую программу. Злобные маленькие порождения, называемые бут-вирусами (boot sector viruses), делают в точности именно это.

Так как большинство компьютеров поставляется с предустановленной Windows, той или иной версии, то ее (Windows-овская) MBR-программа, содержит достаточно когда, чтобы определить какой раздел помечен как "загружаемый", и затем загрузить операционную систему, которая хранится там.

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

То как будет функционировать LILO, определяется конфигурационным файлом /etc/lilo.conf. Вот простейший конфигурационный файл: 

 boot    = /dev/hda
 vga     = normal
 timeout = 30
 read-only
 linear
 prompt

    image  = /boot/vmlinuz
    label  = linux
    root   = /dev/hda3

    image  = /boot/vmlinuz.suse
    label  = suse
    root   = /dev/hda3

    other  = /dev/hda1
    label  = win

Я отделил глобальные опции от опций по загрузке добавлением отступов. Все эти пробелы исключительно косметические и не являются обязательными.

Вот трактовка наиболее важных опций, которые возможно будут вами использованы.

ОпцияОписание
bootЭта опция указывает какое устройство будет являться загрузочным. В данном случае это первый жесткий диск IDE (/dev/hda).
defaultЭта опция указывает образ, который будет загружен по умолчанию. Если опция не указана, то первый образ выбирается как загрузочный.
delay Указывает количество десятых долей секунд, которые будут выдержаны, прежде чем будет загружен образ по умолчанию.
read-onlyЭта опция на самом деле параметр ядра, а не опция LILO. Она указывает, что корневой раздел изначально монтируется в режиме "только для чтения". Это позволяет запустить проверку и исправление файловой системы.
linearЭта опция предписывает LILO использовать адресацию логических секторов, вместо так называемой cylinder/head/sector -- цилиндр/головка/сектор, CHS-адресации. Если ваш lilo.conf работоспособен, то вам не стоит добавлять или удалять эту опцию.
lockЭта опция приводит к том, что LILO "запоминает" любую опцию, которую вы применили вручную при загрузке, и использует ее в следующий раз, когда образ снова будет загружаться. Другими словам, эта опция делет опции ядра Linux, которые вы набрали в приглашении на этапе загрузки, "sticky" (прилипшими).
promptОбычно LILO загружает образ по умолчанию, если не нажата клавиша Shift. Когда клавиша Shift нажата в течение загрузки, то появляется приглашение "boot:". Если эта опция указана, то приглашение "boot:" появляется всегда. Отметим, что у Вас не получится загрузка без участия оператора, если эта опция указана, а опция "timeout" -- нет.

Использование LILO

Чтобы инсталлировать LILO, вам необходимо быть root, а затем, предполагая, что файл lilo.conf располагается в /etc/lilo.conf, просто наберите: 

 # lilo
 Added linux *
 Added suse
 Added win
 #

Строки, выдаваемые программой на экране, представляют собой имена образов, определенных в файле lilo.conf. Звездочка означает образ по умолчанию.

Каталог /boot (опционально)

Большинство дистрибутивов помещают некоторое количество файлов, требуемых для ядра и LILO, в каталог /boot. Это то самое место, в котором располагаются ядра по умолчанию (прекомпилированные ядра) вашего установленного дистрибутива. Помимо этого, тут же располагаются карты ядра, образы загрузочного сектора, прежние копии содержимого загрузочного сектора и т.д.

Добро пожаловать в /usr/src/linux

Теперь мы сделаем решительный шаг! Посетим /usr/src/linux. Посмотрим на рисунок 1-1. Это базовый каталог исходного кода ядра Linux 2.2.x. На самом деле это внешний вид ядра 2.2.16 на моем Linux-laptop. Вам не надо знать слишком много о ядре, чтобы откомпилировать его так, как необходимо. Но хоть это и так, тем не менее мы сделаем обзор базового каталога, чтобы вы могли использовать его как стартовую точку, даже если вам и не потребуется зарываться в дебри ядра.

Рисунок 1-1. Наш первый взгляд на /usr/src/linux.

Файл README содержит очень краткое введение к ядру и информацию о том, как его компилировать. Makefile -- это "формула" для построения ядра (это построение похоже на те случаи, которые описывались в этой главе ранее, хотя процесс сборки ядра Linux не в точности соответствует любому из "стандартных" make-шаблонов, упоминавшихся ранее).

Documentation/ Это, как вы можете предположить, набор документации по ядру Linux и его подсистемам. Эта документация изменяется очень медленно. Некоторая из нее написана таким образом, чтобы быть понятной конечным пользователям; некоторая же понимается только разработчиками ядра. Другая несколько устарела. Как часто бывает и с любыми другими программами, документирование отстает от процесса программирования. Однако, это богатейшая кладезь знаний, и зачастую наилучшее место, к которому следует обратиться в первую очередь, когда вы столкнулись с проблемами в использовании какой-либо особенности ядра.
arch/ В этом каталоге располагается архитектурно-зависимый код (читай: процессоро-зависимый). Подкаталоги этого каталога включают в себя следующий перечень:
  • i386
  • alpha
  • arm
  • m68k
  • mips
  • ppc
  • s390
  • sparc
  • sparc64

Итак, как вы уже увидели, Linux может выполняться на приличном количестве аппаратных платформ. В скором времени вы увидите еще и что-либо похожее на "ia64", которое будет означать поддержку следующего поколения процессоров Intel ("Itanium"). А "s390" ни что иное, как тот самый IBM mainframe S/390. Приятно констатировать тот факт, что Linux работает от маленьких 386-ых и вплоть до мэйнфрэймов от IBM.

drivers/ Каталог drivers содержит код для драйверов различных устройств, от последовательных портов до сетевых карт, от флоппи дисководов до RAID-массивов, а также всего того, что может быть в виде устройств.
fs/ Каталог fs содержит код, который реализует различные файловые системы, поддерживаемые Linux-ом. Linux поддерживает большое число файловых систем. Предпочитаемой, родной файлововой системой является ext2, которая сосуществует с другими, включая FAT, NTFS и HPFS, а также такими сетевыми файловыми системами, как smbfs, nfs и coda.
include/ Этот каталог содержит заголовочные файлы (.h-файлы или "include"-файлы), которые используются повсеместно в исходном тексте ядра. Этот каталог может быть интересен, чтобы прощупать ядро, так как структуры данных по большей части описываются в таких файлах.
init/ Duh, gee, Tennessee... (Аты-баты-шли солдаты?): Это инициализационный код ядра.
ipc/ Здесь располагается код, который реализует System V InterProcess Communication API (API межпроцессной коммуникации System V), -- семафоры, очереди сообщений и разделяемая память.
kernel/ Это то место, где "живет" главная часть кода ядра. Здесь вы обнаружите код, который организует управление процессами (process scheduling), выделение ресурсов (resource allocation), сигналы (signals), модули ядра (kernel modules) и т.д.
lib/ Здесь вы найдете код для ядерных версий некоторых знакомых всем библиотечных функций C, включая ctype, sprintf и т.д. Ядро не может вызывать версии функций уровня пользователя, по причине thread-safety (помимо прочих других причин). А посему оно должно иметь свои собственные реализации функций.
mm/ Этот каталог содержит систему управления памятью (memory management system) Linux-а. Вы можете сказать, что управление памятью явно "ядреная" функция, так почему же она располагается тут, а не в "kernel"? Простой ответ состоит в том, что система управления памятью сама по себе содержит настолько много кода, как, в общем-то, и вся оставшаяся часть ядра. Вынесение ее в отдельный каталог позволяет с большей легкостью разобраться в том, какой исходный файл вовлечен в данное конкретное критичное действие. Более сложный ответ таков, что подсистема управления памятью весьма сложная система, причем такая, что ошибки в ее коде могут иметь катастрофические последствия. Всегда проще поддерживать и отлаживать код, который "сам по себе".
net/ Здесь располагается, как вы уже наверное поняли, реализация различных сетевых протоколов, поддерживаемых ядром Linux. Отметим, что здесь находится именно код протоколов, а не код сетевых устройств (ethernet-плат и т.д.). Код для таких устройств находится в каталоге drivers. ||
scripts/ Здесь находятся различные скрипты, "поддерживающие" процессы конфигурации и сборки. Например, здесь вы обнаружите, Perl/Tk-скрипт, который реализует конфигурационный инструмент xconfig. ||

Конфигурирование ядра с дружественным интерфейсом (menuconfig, xconfig)

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

Имеется три способа запустить интерактивную конфигурацию. Наиболее простой, написать make congif, что приведет к тому, что будут задаваться вопросы, по одному на каждую возможную опцию конфигурации. Я не рекоммендую использовать этот способ потому, что вы перелопатите длинный список до тех пор, пока доберетесь до нужной опции. Два других способа это make menuconfig, -- с текстовым интерфейсом "выбри-нажми", и make xconfig, -- с GUI-интерфейсом "выбри-щелкни", основанным на X-windows.

Интерфейс make menuconfig представлен на Рисунке 1-2, а make xconfig -- на Рисунке 1-3.

Рисунок 1-2. menuconfig

Рисунок 1-3. xconfig

Вам необходимо быть root, чтобы конфигурировать, собирать и инсталлировать новое ядро.

Необязательный код в ядре Linux, может быть либо исключен (disabled), либо "вкомпилирован" в ядро, либо построен как модуль. Модуль предоставляет превосходную гибкость, однако он приводит к уменьшению производительности, из-за трат на его загрузку и выгрузку; если вам потребуется загружать или выгружать модули, то необходимо использовать специальный набор комманд для манипуляции ими (insmod, rmmod и т.д.). Лично я считаю, что много проще включать весь необходимый код в ядро (вкомпилировать в ядро, без модулей), а затем, если вдруг потребуется другая функциональность, загружать то или иное ядро, с необходимой функциональностью. Одно из преимуществ Linux состоит в том, что можно собирать ядро таким образом, как вам кажется удобным. А вы можете это делать несколькими способами.

Некоторые главы этой книги будут рассказывать о том, как конфигурировать ядро так, чтобы включить функцию IP Masquerading и Parallel Line Internet Protocol (PLIP). Такие главы будут говорить только о том, какую установку изменить. Это единственная глава в книге, которая проводит вас по всему процессу компиляции и подготовки к использованию нового ядра. Когда в дальнейшем, при чтении глав этой книги, вам потребуется переконфигурировать ядро, и возникнут вопросы, то перечитайте именно эту главу. Мы попытаемся объяснить весь процесс так, чтобы он был для вас как можно менее болезненным.

Использование make menuconfig или make xconfig позволяет переконфигурировать ваше Linux-ядро различными способами.

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

Согасно другого общего правила, изменяйте как можно меньше параметров за один раз. Например, если вам необходимо инсталлировать Intel EtherExpress Pro и еще поднять PLIP, то сначала разберитесь с первым, -- откомпилируйте, проверьте ядро, а уж затем беритесь за вторую задачу.

Сборка нового ядра

Теперь, когда вы выполнили конфигурацию, необходимо выполнить make dep, чтобы перестроить зависимости. Что это означает? Некоторый код, требует чтобы другой код был собран и прилинкован к ядру. Если такой код не подключен по каким-либо причинам, то компиляция не пройдет. Выполнение make dep приводит к тому, что такой необходимый код будет откомпилирован для любого внесенного вами изменения.

Теперь вы можете собрать свое ядро. Имеется некоторое количество целей для построения -- build targets (аргументы для make, чтобы построить ядро). Некоторые из них собирают (build) и инсталлируют (install) ядро. Мы не будем использовать эти опции. Мы будем делать все это "вручную", так как я не знаю какой из дистрибутивов у вас в наличии и насколько корректно будет работать та или иная инсталляция ядра. Поэтому мы будем делать это пошагово, и опишем это в книге. Большинство ядер получаются настолько большими, что потребуется компрессия ядра. Для этого используются цели zImage или bzImage. bzImage-ядро будет сжато с помощью bzip. Это сделает его компактнее, и такой вариант поддерживают как правило все дистрибутивы. Именно такое ядро я и использую. Заметим, что make bzImage это все, что вам необходимо; однако некоторые пользователи, из-за какой-то непонятной паранойи, по каждому пуку перестраивают код. Поэтому они запускают make clean перед запуском make bzImage. Это можно не делать, однако если сделано, то и вреда особого непричинит (кроме может быть только того, что компиляция будет длиться дольше).

Есть еще кое-что, что потребуется сделать. Если любая из опций установлена как модуль, то вы должны запустить make modules, а затем make modules_install, чтобы инсталлировать модули туда, где им положено быть.

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

 # make dep && make clean && make bzImage && make modules && make modules_install

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

Инсталляция нового ядра

Чтобы установить новое ядро, потребуется настроить элемент /etc/lilo.conf, который будет указывать на новое ядро.

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

Предположим, что вы работаете с компьютером на котором такой же самый lilo.conf, как мы приводили ранее в этой главе.

Ваше новое откомпилированное ядро можно найти в каталоге /usr/src/linux/arch/i386/boot (помните, мы предполагаем, что у вас Intel-совместимый PC?), оно будет называться bzImage. Скопируем его в загрузочный каталог и назовем vmlinuz.new: 

 # cp arch/i386/boot/bzImage /boot/vmlinuz.new

Кроме этого необходимо скопировать карту памяти ядра (kernel memory map), System.map (которая используется, чтобы разрешить адреса ядра в имена функций ядра, в случае kernel panic). Это мы делаем потому, что нехотим проблем с этим.

Теперь добавим новое ядро в наш файл /etc/lilo.conf. (Новые строки выделены жирным шрифтом): 

 boot    = /dev/hda
 vga     = normal
 timeout = 30
 read-only
 linear
 prompt

  image  = /boot/vmlinuz
  label  = linux
  root   = /dev/hda3

  image  = /boot/vmlinuz.suse
  label  = suse
  root   = /dev/hda3

  image  = /boot/vmlinuz.new
  label  = new
  root   = /dev/hda3

  other  = /dev/hda1
  label  = win

Теперь обязательно надо запустить lilo, иначе новое ядро не будет доступно на стадии загрузки: 

 # lilo
 Added linux *
 Added suse
 Added new
 Added win
 #

А теперь наступает момент истины.

Загружаем новое ядро

Ну что, готовы? Перекреститесь, или что уж вы привыкли делать в таком случае, и наберите фатальное: 

 # init 6

Или, если у вас есть работающие пользовати в системе: 

 # shutdown -r 5

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

 LILO:

Наберите: 

 LILO: new

Набор "new" и нажатие Enter приведелт к тому, что LILO загрузит ваше вновь построенное и установленное ядро вместо того, что установленно по умолчанию (которое в данном случае "linux"). Если все пойдет хорошо, то ваша система вскорости загрузится.

Ай! или загружаем старое ядро

Но что делать, если ничего не получилось? Если вы сделали изменения в ''/etc/lilo.conf именно так, как мы говорили, то в случае краха ядра все, что необходимо это всего лишь устроить "холодную" перезагрузку вашего компьютера. Ваше прежнее (точно работающее) ядро Linux загрузится вместо нового, а затем система продолжит восстановление после краха.

Но что же могло пойти не так? Из-за большого разнообразия конфигураций PC и Linux-ядер, я вряд ли могу предположить заранее, что же случилось в вашем случае.

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

Другой возможной причиной может быть то, что настройки ядра в /usr/src/linux на самом деле не соответствуют конфигурации того, что загружается.

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

  1. Обратитесь к другу, который работает в Linux. Зачастую это лучший вариант. Большинство линуксоидов с радостью помогают другим людям получить дополнительные знания в области Linux и используют любую возможность, чтобы помочь.
  2. Обратиться в местную группу пользователей Linux.
  3. Просмотрите web-сайты типа LinuxCare или web-сайт, производителя вашего Linux-дистрибутива.
  4. Просмотреть linux newsgroups.
  5. Воспользоваться поисковиком, например google.com.

Утешением может служить то, что по большей части все возможные проблемы уже обнаружены и разрешены как минимум одним человеком задолго до вас. А значит помощь всегда можно найти.

Поиск исходного кода

web-сайт Freshmeat, http://www.freshmeat.net/, самое крупное хранилище и новостной сайт opensource-проектов. Sourceforge, http://www.sourceforge.net/, -- еще одно хранилище, оно также имеет новостную секцию. Еще один способ найти opensource-проект, это использование моей любимой поисковой машины Google, http://www.google.com/.

Исходный код это хорошо!

Загрузка исходного кода может привести и к другим полезным привычкам, как например просмотр исходного кода, когда вы обнаруживаете проблему. Я не видел ни одного Linux или opensource-проекта, который не находился бы в постоянном развитии/разработке. Обычно как минимум один человек активно просматривает текущий проект на предмет того, чтобы его улучшить. Исходный код не так уж трудно понять. Это в сущности просто еще один язык (прим.перев.: имеется в виду язык общения, -- английский, русский...), созданный для того, чтобы решать задачи. Обучение языку исходного кода сходно тому, как например обучение ограниченному подмножеству иностранного языка -- например, изучения только той части турецкого языка, чтобы быть в состоянии читать турецкие рецепты.

Можно найти несколько хороших книг по различным языкам программирования. Когда мне требуются справочные руководства по программированию, я использую книги издательства O'Reilly. Заметьте, что я сказал справочные руководства. Для того, чтобы обучиться языку программирования, можно найти сотни, если не тысячи бесплатных уроков и руководств в web. Основными языками программирования, используемыми для Linux и opensource-проектов являются C, C++, Perl, and Python.

Используя такие книги я могу разобраться в достаточно небольших программах и найти ответы на некоторые проблемы компиляции. Работая над главой о Wine (Глава 17?), я не смог собрать Wine debugger. Он сыпал и сыпал ошибками, сообщая, что разделяемая библиотека (shared library, .so-файл в Linux) не содержит необходимой функции. Думаю себе -- "Что за чудеса?", и начинаю быстренько искать какие библиотеки использовались при компиляции Wine. Ага, нашел! Моя компиляция провалилась потому, что использовалась старая версия библиотеки. Когда я скопировал новую библиотеку, компилятор промурлыкал, что он вполне доволен этой библиотекой.

Надеюсь, что однажды, "когда у меня будет больше времени" (что надо понимать как никогда), я начну ковырять C++ код в Wine (или в чем-нибудь подобном) и исправлять незначительные ошибки. Большинство opensource-проектов имеют пометки 'FIXME!' (Исправь-меня!) в их исходном коде. Эти пометки отмечают код, который должен быть исправлен, однако это не настолько приоритетно, чтобы у кого-то хватило времени внести изменения. Если вы желаете попрактиковаться в программировании, то это то самое место с которого следует начать.

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

Я говорю, отринь RPM! Стань на светлую сторону силы, используй Исходные Тексты!

<< Определение понятия Свобода (Free) | Multi Tool Linux | Требования >>


edit RightSideBar