Секция 10 из 10 - Предыдущая - Следующая
Все секции - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10

умение делать фары не должно означать, что вы должны препятствовать другим
делать их просто потому, что вам не нравится цвет, в который они собираются их
окрашивать. Эта метафора означает, что вам не нужно обсуждать каждую мелочь
просто потому, что вы знаете о ней достаточно много. Некоторые люди отмечают,
что объём шума, генерируемый при появлении некоторого изменения, находится в
обратной зависимости от сложности самого изменения.

Более пространный и полный ответ заключается в том, что после очень долгого
обсуждения того, должна ли утилита sleep(1) обрабатывать дробное число,
заданное в качестве второго аргумента, Poul-Henning Kamp <phk@FreeBSD.org>
опубликовал большое сообщение, озаглавленное " Велосипедная фара (любого цвета)
на зелёной траве...". Соответствующие части этого сообщения цитируются ниже.

        "Что там насчёт этой велосипедной фары?" Кто-то из вас меня
        спрашивал.

        Это долгая история, или же это старая история, но на самом
        деле она коротка. В начале 1960-х годов Паркинсон (C.
        Northcote Parkinson) написал книгу "Закон Паркинсона", которая
        содержит много интересных взглядов на процесс управления.

        [немного выдержек из краткого содержания книги]

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

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

        Паркинсон объясняет это тем, что атомная станция настолько
        большой, дорогой и сложный объект, что люди не могут его
        осознать и вместо того, чтобы попробовать это сделать, они
        полагаются на то, что кто-то уже проверил все мелочи до того,
        как всё зашло так далеко. В своей книге Ричард П. Фейнманн
        (Richard P. Feynmann) даёт несколько интересных и очень
        поучительных примеров, связанных с Лос Аламос.

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

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

  --Poul-Henning Kamp <phk@FreeBSD.org> on freebsd-hackers, October 2,
                                                                  1999

12.15. Сколько требуется разработчиков FreeBSD, чтобы сменить электрическую
лампочку?

Необходимо иметь ровно одну тысячу сто семьдесят два разработчика:

Двадцать три сообщат в -CURRENT о том, что не горит свет;

Четыре начнут утверждать, что это проблема конфигурации и такие сообщения нужно
посылать в -questions;

Трое оформят PR по этому поводу, причём одно их них будет направлено в doc и
будет содержать только строчку "здесь темно";

Один закоммитит неоттестированную лампочку, что сломает построение системы, а
затем через пять минут вернёт все назад;

Восемь поругаются с авторами PR по поводу включения патчей в PR;

Пять сообщат о том, что не проходит компиляция системы;

Тридцать один человек ответит, что у них всё работает и наверное, те выполняли
cvsup в неподходящее время;

Один пошлёт патч для новой лампочки в -hackers;

Один пожалуется, что у него имелись патчики ещё три года назад, но когда он
послал их в -CURRENT, они были проигнорированы и он имел неудачный опыт работы
с системой PR; кроме того предлагаемая лампочка не имеет отражателя.

Тридцать семь начнут кричать, что лампочки не относятся к базовой системе, что
коммиттеры не имеют права делать такие вещи без опроса общественности и ЧТО В
ООБЩЕ -CORE ДЕЛАЕТ ПО ЭТОМУ ПОВОДУ?

Две сотни напишут о цвете велосипедных фар;

Трое скажут, что этот патч не соответствует style(9);

Семнадцать возразят, что предлагаемая новая лампа подпадает под лицензию GPL;

Пятьсот восемьдесят шесть раздуют флейм по поводу сравнения лицензий GPL, BSD,
MIT, NPL и личных мнений о неизвестных основателей FSF;

Семеро пошлют различные части этих обсуждений в -chat и -advocacy;

Один закоммитит предлагаемую лампу, хотя она светит хуже, чем старая;

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

Сорок шесть громко воспротивятся этому изменению и потребуют объяснений от
-core;

Одиннадцать попросят уменьшить размер лампочки, чтобы она подошла к их Тамагочи
на случай, если мы когда-нибудь соберёмся переносить FreeBSD на эту платформу;

Семьдесят три заявят о SNR в -hackers и -chat и в знак протеста отпишутся;

Тринадцать пошлют письма "unsubscribe", "How do I unsubscribe?", и "Please
remove me from the list" с обычной подписью;

Один закоммитит работающую лампочку в то время, как все будут слишком заняты
руганью, чтобы это заметить;

Тридцать один человек напишет, что новая лампочка будет светить на 0.364% ярче,
если её откомпилировать с помощью TenDRA (хотя при этом она приобретёт форму
куба) и что FreeBSD должна перейти на компилятор TenDRA, а не на EGCS;

Один заметит, что у лампочки отсутствует цоколь;

Девять (включая авторов PR) спросят "что такое MFC?";

Спустя две недели после смены лампочки пятьдесят семь человек сообщат о том,
что света всё равно нет.

Nik Clayton <nik@FreeBSD.org> добавил:

Я сильно смеялся над всем этим.

И тогда я подумал, "Постойте-ка, найдётся ли кто-нибудь, чтобы задокументиров
ать это где-нибудь?"

И на меня снизошло озарение :-)

Авторские права на этот параграф: Copyright + 1999 Dag-Erling C. SmЬrgrav <
des@FreeBSD.org>. Пожалуйста, не воспроизводите этот материал без указания ав
торских прав.

-------------------------------------------------------------------------------

Chapter 13. Только для серьёзных хакеров FreeBSD

13.1. Что такое SNAP и RELEASE?
13.2. Как самим сделать релиз?
13.3. Как создать инсталляционные диски?
13.4. По команде make world были переустановлены все программы.
13.5. При загрузке системы выдаётся сообщение "(bus speed defaulted)".
13.6. Можно ли работать с current при ограниченном доступе в Internet?
13.7. Как вы разделяете дистрибутив на файлы по 240К?
13.8. Я написал некоторое добавление к ядру, кому его послать?
13.9. Как распознаются и инициализируются адаптеры ISA Plug N Play?
13.10. Поддерживает ли FreeBSD аппаратные платформы, отличные от x86?
13.11. Мне нужно старшее число для написанного мною драйвера устройства.
13.12. Альтернативный метод размещения каталогов
13.13. Что делать при аварийном остановах системы
13.14. Перестала работать функция dlsym() для ELF!
13.15. Увеличение и уменьшение адресного пространства ядра

13.1. Что такое SNAP и RELEASE?

В Репозитории CVS сейчас находятся три активно/полуактивно развивающихся ветки
FreeBSD (ветвь RELENG_2 меняется от силы пару раз в год, вот почему в
разработке только три активных ветки):

  * RELENG_2_2 AKA 2.2-STABLE

  * RELENG_3 AKA 3.X-STABLE

  * RELENG_4 AKA 4-STABLE

  * HEAD AKA -CURRENT AKA 5.0-CURRENT

HEAD - это не реальный тэг ветки, как другие два; это просто символьная
константа для обозначения "текущего, не ветвящегося, находящегося в разработке
дерева", то есть "-CURRENT".

На данный момент "-CURRENT" является находящимся в разработке деревом 5.0, в
етка 4-STABLE, RELENG_4, отделилась от "-CURRENT" в марте 2000 года.

Ветвь 2.2-STABLE, RELENG_2_2, отделилась от -CURRENT в ноябре 1996 и развитие
этой ветви было полностью прекращено.

13.2. Как самим сделать релиз?

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

    pseudo-device vn         #Vnode driver (turns a file into a device)


Во-вторых, вам нужно иметь на диске полное дерево CVS. Чтобы добиться этого, вы
можете использовать CVSUP, указав в файле supfile в качестве имени релиза cvs и
удалив все поля с тегами и датами:

    *default prefix=/home/ncvs
    *default base=/a
    *default host=cvsup.FreeBSD.org
    *default release=cvs
    *default delete compress use-rel-suffix

    ## Main Source Tree
    src-all
    src-eBones
    src-secure

    # Other stuff
    ports-all
    www
    doc-all


После этого запустите cvsup -g supfile для выкачки всех нужных исходных текстов
на ваш компьютер...

Наконец, вам нужно свободное место для построения системы. Допустим, что св
ободное место есть в каталоге /some/big/filesystem и, как в примере выше, вы
поместили дерево CVS в каталог /home/ncvs:

    # setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
    # cd /usr/src
    # make buildworld
    # cd /usr/src/release
    # make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release



        Note: Пожалуйста, отметьте, что вам не нужно выполнять процедуру
        построения системы полностью, если у вас уже есть заполненный /usr/obj.

Полный релиз будет строиться в каталоге /some/big/filesystem/release и по
окончании этого процесса дистрибутив, готовый к помещению на FTP-сервер, будет
находиться в каталоге /some/big/filesystem/release/R/ftp. Если вы захотите
построить SNAP другой ветки, не -CURRENT, то можете указать RELEASETAG=SOMETAG
в командной строке make release выше, например, при указании RELEASETAG=
RELENG_2_2, будет строиться самый свежий снэпшот ветки 2.2-STABLE.

13.3. Как создать инсталляционные диски?

Весь процесс создания инсталляционных дисков и дистрибутивов исходных текстов и
бинарников автоматизирован в файле /usr/src/release/Makefile. Информации, в нём
содержащейся, должно быть достаточно, чтобы начать. Однако, должны вас
предупредить, что этот процесс включает в себя выполнение make world и поэтому
занимает много времени и дискового пространства.

13.4. По команде make world были переустановлены все программы.

Да, так и должно быть; как говорит название этой команды, make world выполняет
построение всех системных файлов с нуля, так что в итоге можете быть уверены,
что получите чистую рабочую систему (вот почему это занимает столько времени).

Если в момент запуска команд make world или make install определена переменная
окружения DESTDIR, то вновь создаваемые файлы будут помещены в дерево каталого
в. идентичное существующему, с корнем, располагающимся в ${DESTDIR}. Однако
некоторые случайные комбинации модификаций совместно используемых библиотек и в
ерсий компилируемых программ при исполнении команды make world, может этому
помешать.

13.5. При загрузке системы выдаётся сообщение "(bus speed defaulted)".

Адаптеры SCSI Adaptec 1542 позволяют программно изменять скорость доступа к
шине. Предыдущие версии драйвера 1542 пытались определить максимально возможную
скорость работы и установить это значение. Мы обнаружили, что у некоторых
пользователей это приводило к нарушению работоспособности системы, поэтому эта
возможность сейчас вынесена в параметр конфигурации ядра TUNE_1542. Использов
ание этой опции на тех системах, где она работает, может привести к ускорению
доступа к дискам, а там, где это не работает, может привести к потере данных.

13.6. Можно ли работать с current при ограниченном доступе в Internet?

Да, это можно делать без скачивания полного дерева исходных текстов с помощью
системы CTM.

13.7. Как вы разделяете дистрибутив на файлы по 240К?

Команда split в современных BSD-системах имеет опцию -b, позволяющую разрезать
файлы на части с точностью до байта.

Вот пример из файла /usr/src/Makefile.

    bin-tarball:
    (cd ${DISTDIR}; \
    tar cf - . \
    gzip --no-name -9 -c | \
    split -b 240640 - \
    ${RELEASEDIR}/tarballs/bindist/bin_tgz.)


13.8. Я написал некоторое добавление к ядру, кому его послать?

Обратитесь к соответствующему разделу Руководства, в котором описано, как это
сделать.

И спасибо вам за ваши усилия!

13.9. Как распознаются и инициализируются адаптеры ISA Plug N Play?

От: Фрэнка Дурды IV (Frank Durda IV)

Если рассматривать на самом низком уровне, то существует несколько портов ввода
/вывода, в которые должны выводить информацию все адаптеры PnP, когда компьютер
пытается выполнить запрос о наличии установленных адаптеров. Так что, когда
запускается процедура определения адаптеров PnP, она выполняет запрос о наличии
каких-либо адаптеров PnP, а все такие адаптеры выдают свой номер модели при
чтении того же порта ввода/вывода, поэтому процедура определения получит ответ
на свой запрос, состоящий из логически наложенных номеров моделей,
интерпретируемый как "да". В этом ответе по крайней мере один бит будет установ
лен в единицу. Затем код определения адаптеров может "выключать" адаптеры с ID
(назначаемыми Microsoft/Intel), большими, чем X. Потом следует попытка
определить, остались ли ещё адаптеры, отвечающие на запрос. Если ответ 0, то
адаптеров с ID, большими чем X, нет. После этого делается попытка определить
наличие адаптеров с номерами, меньшими чем X. Если они есть, то становится изв
естно, что есть адаптеры с номерами, меньшими, чем X. Тогда происходит запрос
адаптерам, большим чем X-(limit-4), на выключение. Запрос повторяется. Применив
этот метод полудвоичного поиска границ расположения ID достаточное количество
раз, код идентификации найдёт все адаптеры PnP, установленные в данной машине
за число итераций, гораздо меньшее, чем может занять перебор 2^64 возможных в
ариантов ID.

ID представляет собой два 32-разрядные числа (всего их 2^64) + 8 бит
контрольной суммы. Первые 32 бита являются идентификатором производителя. Они
никогда не сообщаются, однако часто бывает, что различные типы адаптеров от
одного и того же производителя имеют различные 32-битные значения
идентификатора производителя. Необходимость в 32 разрядах только для задания
производителя адаптера выглядит несколько излишним.

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

Группы по 32 бита не могут быть нулевыми. Это позволяет при логическом
объединении OR их номеров получать ненулевое значение во время начального
поиска адаптеров.

Как только система определила ID всех адаптеров, она активизирует каждый
адаптер, по одному за раз (через те же порты ввода/вывода), и определяет, какие
ресурсы требуются данному адаптеру, какие возможные прерывания доступны и тд.
Сканирование и сбор информации происходит по всем адаптерам.

Эта информация соотносится с содержащейся в файлах ECU на диске или в MLB BIOS.
Поддержка PnP из ECU и BIOS для аппаратуры на MLB обычно имеет синтетический
характер, и периферия не выполняет полностью процедуру настоящего PnP. Однако,
используя BIOS и информацию из ECU, процедура инициализации может обнаружить
устройства PnP, которые не могут быть найдены другим способом.

Затем устройства PnP опрашиваются ещё раз для назначения им портов ввода/выв
ода, DMA, IRQ и адресов отображаемой памяти. Теперь устройства должны иметь
именно такие настройки и они должны оставаться такими до следующей
перезагрузки, хотя нигде не сказано, что вы не можете их менять, когда
захотите.

Здесь сделано много упрощений, однако общую идею вы должны уловить.

Microsoft использовала для PnP некоторые порты статуса первого принтера, по их
логике, не существует адаптеров, использующих эти адреса для ввода/вывода. Я
обнаружил один такой адаптер принтера от IBM, который декодирует запись в порт
статуса в момент начального опроса устройств PnP, на что MS ответил "хулиган".
Так что они выполняют запись в порт статуса принтера для установки адресов, в
добавок используют этот адрес + 0x800, и ещё один порт ввода/вывода, который
может располагаться где угодно в диапазоне между 0x200 и 0x3ff, для чтения.

13.10. Поддерживает ли FreeBSD аппаратные платформы, отличные от x86?

Интерес к работе над поддержкой многоплатформенности во FreeBSD проявили
несколько групп разработчиков, и одна из попыток переноса на другую
архитектуру, FreeBSD/AXP (ALPHA), оказавшаяся достаточно удачной, в настоящее в
ремя доступна по адресу ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha. Эта реализация
для ALPHA сейчас поддерживает всё увеличивающееся число машин ALPHA, в
частности, модели AlphaStation, AXPpci, PC164, Miata и Multia. Чтобы быть в
курсе событий, происходящих с этим проектом, подпишитесь на соответствующий <
freebsd-alpha@FreeBSD.org> список рассылки.

Также был проявлен интерес к переносу FreeBSD на платформу SPARC. Если вы
хотите подключиться к этому проекту, подпишитесь на соответствующий <
freebsd-sparc@FreeBSD.org> список рассылки. В список планируемых к поддержке
платформ совсем недавно добавились архитектуры IA-64 и PowerPC, дополнительную
информацию можно получить, подключившись к соответствующим спискам рассылки <
freebsd-ia64@FreeBSD.org> и/или <freebsd-ppc@FreeBSD.org>. Для обсуждение общих
вопросов, касающихся новых аппаратных платформ, предназначен список рассылки <
freebsd-platforms@FreeBSD.org>.

13.11. Мне нужно старшее число для написанного мною драйвера устройства.

Всё зависит от того, планируете вы сделать этот драйвер общедоступным или нет.
Если это так, то, пожалуйста, пошлите нам копию исходных текстов драйвера в
месте с соответствующими модификациями в файле files.i386, пример описания
устройства в файле конфигурации ядра и соответствующий код MAKEDEV для создания
специальных файлов устройств, которые использует ваше устройство. Если это не
так. или это невозможно из-за лицензионных ограничений, то для старшего числа
символьного устройства и старшего числа блочного устройства для этих целей были
зарезервированы значения 32 и 8 соответственно; используйте их. В любом случае.
мы будем рады услышать о вашем драйвере в списке рассылки <
freebsd-hackers@FreeBSD.org>.

13.12. Альтернативный метод размещения каталогов

В ответ на вопрос о других методах размещения каталогов могу сказать, что
используемая в настоящее схема не претерпела изменений с 1983 года. Эти
соглашения были предназначены для оригинальной файловой системы FFS, я никогда
их не пересматривал. Эта схема прекрасно работает, позволяя избежать
переполнения групп дорожек. Как некоторые из вас замечали, она работает плохо
при поиске. Большинство файловых систем создаются из архивов, которые были
созданы с глубиной первого поиска (aka ftw). Это приводит к тому, что их
каталоги размещаются на нескольких группах дорожек, создавая наихудший случай
для последующего поиска глубиной один. Если бы было известно общее количество
каталогов, которые должны быть созданы, выходом было бы создание (общее
количество / количество групп дорожек) на дорожку группу перед переходом.
Обычно это число определяется чисто эвристически. Даже при использовании
маленького фиксированное числа, скажем 10, значительно улучшает ситуацию. Чтобы
различать операции восстановления от обычных операций (где текущий алгоритм
подходит), вы можете использовать объединение в кластеры объёмом до 10, если
они делаются в окне, равным 10 секундам. Во всяком случае, я думаю, что это
требует некоторых экспериментов.

Кирк МакКузик (Kirk McKusick), Сентябрь 1998

13.13. Что делать при аварийном остановах системы

[Этот раздел был вырезан из письма, написанного Bill Paul <wpaul@FreeBSD.org> в
список рассылки freebsd-current Dag-Erling C. SmЬrgrav <des@FreeBSD.org>,
который исправил несколько опечаток и добавил комментарии в квадратных скобках]

    From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
    Subject: Re: the fs fun never stops
    To: ben@rosengart.com
    Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
    Cc: current@FreeBSD.org


[<ben@rosengart.com> отправил письмо, содержащее следующее аварийное сообщение
системы]
    > Fatal trap 12: page fault while in kernel mode
    > fault virtual address   = 0x40
    > fault code              = supervisor read, page not present
    > instruction pointer     = 0x8:0xf014a7e5
                                    ^^^^^^^^^^
    > stack pointer           = 0x10:0xf4ed6f24
    > frame pointer           = 0x10:0xf4ed6f28
    > code segment            = base 0x0, limit 0xfffff, type 0x1b
    >                         = DPL 0, pres 1, def32 1, gran 1
    > processor eflags        = interrupt enabled, resume, IOPL = 0
    > current process         = 80 (mount)
    > interrupt mask          =
    > trap number             = 12
    > panic: page fault

[Если] вы увидите такое сообщение, просто его воспроизвести и послать нам не
достаточно. Указатель инструкций, выделенный мною, важен, к сожалению, его
значение зависит от конфигурации ядра. Другими словами, его значение меняется в
зависимости от конкретного ядра, которое вы используете. Если вы используете
ядро GENERIC одного из снэпшотов, то кто-то ещё может отследить функцию, вызвав
шую ошибку, но если вы работаете со специально отконфигурированным ядром, то
только вы можете сказать нам, где случилась ошибка.

Вот что вы должны сделать:

  * Запишите значение указателя инструкций. Заметьте, что часть 0x8: в этом
    случае не важна: нам нужна часть 0xf0xxxxxx.

  * Когда система перезагрузится, сделайте следующее:
        % nm -n /kernel.that.caused.the.panic | grep f0xxxxxx

    где f0xxxxxx - это значение указателя инструкций. Однако неприятность
    заключается в том, что вы не получите точного соответствия, так как в
    таблице имен ядра для точек входа в функции даны адреса на начало функций,
    а указатель инструкций будет указывать куда-то внутрь её тела. Если вы не
    получили точного соответствия, опустите последнюю цифру в значении
    указателя инструкций и попробуйте снова, то есть:
        % nm -n /kernel.that.caused.the.panic | grep f0xxxxx

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

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

Лучшим способом выяснить причину, вызвавшую аварийный останов, является
создание аварийного дампа системы, а затем использование gdb(1) для трассировки
вызовов. Конечно, это зависит от корректности работы gdb(1) с -CURRENT, что я
гарантировать не могу (помнится, кто-то говорил, что новый ELF gdb(1)
некорректно работает с аварийными дампами ядра: необходимо проверить это до в
ыхода 3.0, иначе не избежать краски стыда на наших лицах после выпуска CD).

Во всяком случае, обычно я использую такой способ:

  * Отредактируйте конфигурационный файл ядра, добавив строку options DDB, если
    вам зачем-то понадобился встроенный отладчик. (Я использую его в основном
    для указания точек останова, если подозреваю возникновение бесконечных
    циклов.)

  * Выполните config -g KERNELCONFIG для создания каталога построения ядра.

  * cd /sys/compile/KERNELCONFIG; make

  * Дождитесь окончания компиляции ядра.

  * make install

  * reboot

В процессе выполнения команды make(1) будут построены два ядра, kernel и
kernel.debug. kernel будет установлен как /kernel, тогда как kernel.debug может
быть использован в качестве источника отладочной информации для gdb(1).

Чтобы включить сброс аварийного дампа, вам нужно отредактировать файл /etc/
rc.conf так, чтобы устройство dumpdev указывало на раздел подкачки. В этом
случае скрипты rc(8) будут вызывать команду dumpon(8) для включения создания ав
арийных дампов. Вы можете запустить команду dumpon(8) вручную. После аварийной
остановки аварийный дамп может быть получен с помощью программы savecore(8);
если значение переменной dumpdev было установлено в /etc/rc.conf, скрипты rc(8)
запустят savecore(8) автоматически и поместят аварийный дамп в каталог /var/
crash.

    Note: Аварийные дампы FreeBSD обычно имеют размер, равный физическому объё
    му оперативной памяти вашей машины. Так что если у вас 64МБ ОЗУ, вы
    получите дамп размером 64МБ. Поэтому вы должны удостовериться, что в
    каталоге /var/crash достаточно места для хранения дампа. Либо вы можете в
    ручную запустить savecore(8) и создать аварийный дамп в другом каталоге,
    где достаточно места. Размер аварийного дампа можно уменьшить, указав в
    конфигурации ядра options MAXMEM=(размер) подходящее значение для объёма
    памяти, которое будет использоваться ядром. Например, если у вас 128 МБ
    ОЗУ, вы можете ограничить использование памяти ядром 16 мегабайтами, так
    что размер аварийного дампа будет равен 16МБ, а не 128.

Как только вы получили аварийный дамп, вы можете выполнить трассировку вызовов
с помощью gdb(1) таким образом:

    % gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
    (gdb) where


Заметьте, что при этом может быть выведено несколько экранов информации; в
идеале вы должны использовать script(1) для их перехвата. При использовании
необработанного образа ядра со всей отладочной информацией может быть найдена
конкретная строка исходного текста ядра, при достижении которой случилась ав
арийная остановка. Для выяснения последовательности событий, приведших к ав
арийному останову, обычно читается трассировка стека снизу вверх. Вы можете
также использовать gdb(1) для вывода значений различных переменных или
структур, чтобы выяснить состояние системы во время аварии.

Теперь, если вы в самом деле душевнобольной и у вас есть второй компьютер, то
можете настроить gdb(1) для удалённой отладки, так, что сможете использовать
gdb(1) на одном компьютере, чтобы отладить ядро на другом, включая использов
ание точек останова, пошагового прохода по коду ядра, всё как с обычной
прикладной программой. Я пока с этим не игрался, так как не часто имею в
озможность поставить две машины одну напротив другой для отладки.

[Билл (Bill) добавил: "Я забыл обратить ваше внимание на одну вещь: если у вас
включена поддержка DDB и ядро переходит в режим отладки, вы можете намеренно в
ызвать аварийный останов (и создание аварийного дампа), набрав 'panic' в
командной строке ddb. Этот процесс может снова вызвать отладчик. В этом случае
наберите 'continue' и процесс будет завершён созданием аварийного дампа." -ed]

13.14. Перестала работать функция dlsym() для ELF!

По умолчанию при работе с форматом ELF символы, определённые в выполнимом
файле, не доступны динамическому загрузчику. Поэтому при вызове функции dlsym
(), которая осуществляет поиск по дескриптору, полученному после вызова dlopen
(NULL, flags), желаемый результат достигнут не будет.

Если вы хотите осуществить поиск в выполнимом файле процесса с помощью функции
dlsym(), вам нужно компоновать выполнимый файл с опцией -export-dynamic компоно
вщика ELF.

13.15. Увеличение и уменьшение адресного пространства ядра

По умолчанию размер адресного пространства ядра равен 256 МБ во FreeBSD 3.x и 1
ГБ во FreeBSD 4.x. Если вы используете FreeBSD в качестве сервера с интенсивной
сетевой нагрузкой (скажем, большой FTP или HTTP сервер), вы можете обнаружить,
что 256 МБ недостаточно.

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

Первая проблема решается увеличением значения константы NKPDE в файле src/sys/
i386/include/pmap.h. В случае 1 ГБ адресного пространства он должен выглядеть
примерно так:

    #ifndef NKPDE
    #ifdef SMP
    #define NKPDE                   254     /* addressable number of page tables/pde's */
    #else
    #define NKPDE                   255     /* addressable number of page tables/pde's */
    #endif  /* SMP */
    #endif


Для вычисления значения NKPDE разделите желаемый объём адресного пространства
(в мегабайтах) на четыре и вычтите из получившегося числа единичку в случае
однопроцессорной машины и двоечку в случае многопроцессорного ядра.

Для достижения второй цели вам нужно правильный адрес для загрузки ядра: просто
отнимите размер адресного пространства (в байтах) от 0x100100000; результат
будет равным 0xc0100000 для адресного пространства в 1 ГБ. Установите значение
константы LOAD_ADDRESS в файле src/sys/i386/conf/Makefile.i386 в это значение;
затем установите значение счётчика в начале списка секций в файле src/sys/i386/
conf/kernel.script в то же самое значение, как это сделано здесь:

    OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
    OUTPUT_ARCH(i386)
    ENTRY(btext)
    SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
    SECTIONS
    {
      /* Read-only sections, merged into text segment: */
      . = 0xc0100000 + SIZEOF_HEADERS;
      .interp     : { *(.interp)    }


После этого переконфигурируйте и перестройте ядро. Вы можете столкнуться с
проблемами при работе утилит ps(1), top(1) и подобных им; решить их может make
world (или ручная перекомпиляция libkvm, ps и top после копирования исправ
ленного pmap.h в /usr/include/vm/).

ЗАМЕЧАНИЕ: Размер адресного пространства ядра должен быть кратен четырём
мегабайтам.

[David Greenman <dg@FreeBSD.org> добавил: Я думаю, что размер адресного
пространства ядра должен быть степенью двойки, но я в этом не уверен. Для
работы с верхними адресами памяти использовался код старого загрузчика, и я
ожидаю по крайней мере точность в 256 МБ.]

-------------------------------------------------------------------------------

Chapter 14. Наши благодарности

        Если вы обнаружили неточности в этом FAQ или хотите что-то в
        него добавить, пожалуйста, напишите нам по адресу FAQ
        Maintainer <faq@FreeBSD.org>. Мы ждём ваши отзывы и пожелания,
        чтобы с вашей помощью сделать этот документ ещё лучше!

                                                   --FreeBSD Core Team

Jordan K. Hubbard <jkh@FreeBSD.org>

    Различные упорядочения и добавления в FAQ.

Doug White <dwhite@FreeBSD.org>

    Работа со списком рассылки freebsd-questions

JЖrg Wunsch <joerg@FreeBSD.org>

    Работа с телеконференциями Usenet

Garrett Wollman <wollman@FreeBSD.org>

    Раздел о сети и форматирование

Jim Lowe

    Информация о протоколе многоадресной передачи

Peter da Silva <pds@FreeBSD.org>

    Раб-наборщик

Andrey Zakhvatov

    Перевод на русский язык

The FreeBSD Team

    Охи, вздохи, стоны, добавления

И всем остальным, оставшимся неизвестными, наши глубочайшие извинения и
сердечные благодарности!

Секция 10 из 10 - Предыдущая - Следующая

© faqs.org.ru