WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |

«; ...»

-- [ Страница 8 ] --

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

Демоны bdflush и kupdated В ядрах серий до 2.6 работа потоков pdflush выполнялась двумя другими пото ками ядра bdflush и kupdated.

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

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

Между демонами bdfl ush и pdflush существует два главных отличия. Первое состоит в том, что демон bdflush был всего один, а количество потоков pdflush может меняться динамически. Об этом более подробно будет рассказано в следую щем разделе. Второе отличие состоит в том, что демон bdflush работал с буферами, он записывал на диск измененные буферы. Демон pdflush работает со страница ми, он записывает на диск целые измененные страницы памяти. Конечно, страницы памяти могут соответствовать буферам, но единицей ввода-вывода является целая страница памяти, а не один буфер. Это дает преимущество, поскольку работать со страницами памяти проще, чем с буферами, так как страница памяти — более общий и более часто используемый объект.

Так как демон bdflush выполнял обратную запись, только когда количество сво бодной памяти очень сильно уменьшалось или количество буферов было очень боль шим, то был введен поток ядра kupdated, который периодически выполнял обрат ную запись измененных страниц памяти. Он использовался для целей, аналогичных функции wb_kupdate () демона pdflush.

Потоки bdflush и kupdated и их функциональность сейчас заменены потоками pdflush.

Предотвращение перегруженности:

для чего нужны несколько потоков Один из главных недостатков решения на основе демона bdflush состоит в том, что демон bdflush имел всего один поток выполнения. Это приводило к возмож ности зависания демона при большом количестве операций обратной записи, когда Страничный кэш и обратная запись страниц один поток демона bdflush блокировался на очереди запросов ввода-вывода пере груженного устройства, в то время как очереди запросов других устройств могли быть в этот момент сравнительно свободными. Если система имеет несколько дис ков и соответствующую процессорную мощность, то ядро должно иметь возмож ность загрузить работой все диски. К сожалению, даже при большом количестве данных, для которых необходима обратная запись, демон bdflush может оказаться загруженным работой с одной очередью и не сможет поддерживать все диски в на груженном состоянии. Это происходит потому, что пропускная способность диском конечна и, к несчастью, очень низкая. Если только один поток выполняет обратную запись страниц, то он может проводить много времени в ожидании одного диска, так как пропускная способность диска ограничена. Для облегчения этой ситуации ядру необходима многопоточная обратная запись. В таком случае ни одна очередь запросов не может стать узким местом.

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

Количество потоков изменяется в процессе работы системы в соответствии с простым алгоритмом. Если все существующие потоки pdflush оказываются заняты ми в течение одной секунды, то создается новый поток pdflush. Общее количество потоков не может превышать значения константы MAX_PDFLUSH_THREADS, которая по умолчанию равна 8. И наоборот, если поток pdflush находился в состоянии ожи дания больше одной секунды, то он уничтожается. Минимальное количество потоков равно, по крайней мере, значению константы MIN_PDFLUSH_THREADS, что по умол чанию соответствует 2. Таким образом, количество потоков pdflush изменяется ди намически в зависимости от количества страниц, для которых необходима обратная запись, и загруженности этих потоков. Если все потоки pdflush заняты обратной записью, то создается новый поток. Это гарантирует, что ни одна из очередей запро сов устройств не будет перегружена, в то время как другие очереди устройств не так загружены и в них тоже можно выполнять обратную запись. Если перегрузка предот вращается, то количество потоков pdflush уменьшается, чтобы освободить память.

Вce это хорошо, но что если все потоки pdflush зависнут в ожидании записи в одну и ту же перегруженную очередь? В этом случае производительность нескольких потоков pdflush не будет выше производительности одного потока, а количество занятой памяти станет значительно большим. Чтобы уменьшить такой эффект, для потоков pdflush реализован алгоритм предотвращения зависания (congestion avoi dance). Потоки активно начинают обратную запись страниц для тех очередей, ко торые не перегружены. В результате потоки pdflush распределяют свою работу по разным очередям и воздерживаются от записи в перегруженную очередь. Когда все потоки pdfl ush заняты работой и запускается новый поток, то это означает, что они действительно заняты.

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

340 Глава Коротко о главном В этой главе был рассмотрен страничный кэш и обратная запись страниц. Было показано, как ядро выполняет все операции страничного ввода-вывода, как опера ции записи откладываются с помощью дискового кэша и как данные записываются на диск с помощью группы потоков пространства ядра pdf lush.

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

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

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

Модуль "Hello,World!" В отличие от разработки основных подсистем ядра, большинство из которых были уже рассмотрено, разработка модулей подобна созданию новой прикладной программы, по крайней мере в том, что модули имеют точку входа, точку выхода и находятся каждый в своем бинарном файле.

Может показаться банальным, но иметь возможность написать программу, кото рая выводит сообщение "Hello World!", и не сделать этого- просто смешно. Итак, леди и джентльмены, модуль "Hello, World!".

/* * hello.с - модуль ядра Hello, World!

/* #include #include #include /* * hello_init - функция инициализации, вызывается при загрузке модуля, * В случае успешной загрузки модуля возвращает значение нуль, * и ненулевое значение в противном случае.

*/ static int hello_init(void) { printk(KERN_ALERT "I bear a charmed life.\n")

;

return 0

;

} /* * hello_exit - функция завершения, вызывается при выгрузке модуля.

*/ static void hello_exit (void) { printk(KERN_ALERT "Out, out, brief candle!\n")

;

} module_init(hello_init)

;

module_exit(hello_exit)

;

MODULE_LICENSE{"GPL")

;

MODULE_AUTHOR("Shakespeare")

;

Это самый простой модуль ядра, который только может быть. Функция hello_ i ni t () регистрируется с помощью макроса module_init () в качестве точки входа в модуль. Она вызывается ядром при загрузке модуля. Вызов module_init () — это не вызов функции, а макрос, который устанавливает значение своего параметра в ка честве функции инициализации. Все функции инициализации должны соотпетство вать следующему прототипу.

int my_init(void)

;

Так как функция инициализации редко вызывается за пределами модуля, ее обыч но не нужно экспортировать и можно объявить с ключевым словом st at i c.

Функции инициализации возвращают значение тина i nt. Если инициализация (или то, что делает функция инициализации) прошла успешно, то функция должна возвратить значение нуль. В случае ошибки возвращается ненулевое значение.

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

Функция hel l o_exi t () регистрируется в качестве точки выхода из модуля с помощью макроса module_exit (). Ядро вызывает функцию hel l o_exi t (), когда модуль удаляется из памяти. Завершающая функция должна выполнить очистку ре сурсов, гарантировать, что аппаратное обеспечение находится в непротиворечивом состоянии, и т.д. После того как эта функция завершается, модуль выгружается.

Завершающая функция должна соответствовать следующему прототипу.

void my_exit(void)

;

Так же как и в случае функции инициализации, ее можно объявить как st ati c.

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

Макрос MODULE_LICENSE () позволяет указать лицензию на право копирования модуля. Загрузка в память модуля, для которого лицензия не соответствует GPL, при ведет к установке в ядре флага t ai nt ed (буквально, испорченное). Этот флаг служит для информационных целей, кроме того, многие разработчики уделяют меньше вни мания сообщениям об ошибках, в которых указан этот флаг. Более того, модули, у которых лицензия не соответствует GPL, не могут использовать символы, которые служат "только для GPL" (см. раздел "Экспортируемые символы" ниже в этой главе).

Наконец, макрос MODULE_AUTHOR () позволяет указать автора модуля. Значение этого макроса служит только для информационных целей.

Сборка модулей Благодаря новой системе сборки "kbuild", в ядрах серии 2.6 сборка модулей вы полняется значительно проще, чем в старых сериях. Первое, что нужно сделать при сборке модулей, — это решить, где будет находиться исходный код модуля. Исходный код модуля необходимо правильно объединить с деревом исходных кодов ядра. Это можно сделать в виде заплаты или путем добавления в официальное дерево исходно го кода ядра. Кроме этого, можно компилировать исходный код модуля отдельно от исходных кодов ядра.

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

На первом этапе необходимо решить, где именно будет находиться модуль в де реве исходных кодов ядра. Драйверы необходимо хранить в подкаталогах каталога dri vers/, который находится в корне дерева исходных кодов ядра. Внутри этого каталога драйверы делятся на классы, типы и собственно на отдельные драйверы.

Символьные устройства находятся в каталоге drivers/char/, блочные— в каталоге drivers/block/, устройства USB — в каталоге drivers/usb/. Эти правила не есть жесткими, так как многие устройства USB также являются и символьными устрой ствами. Но такая организация является понятной и четкой.

Допустим, что вы хотите создать свой подкаталог и ваш воображаемый драйвер разработан для удочки с числовым программным управлением, которая имеет интер фейс Fish Master XL 2000 Titanium для подключения к компьютеру. Следовательно, необходимо создать подкаталог fishing внутри каталога drivers/char/.

После этого необходимо добавить новую строку в файл Makefile, который на ходится в каталоге drivers/char/. Для этого отредактируйте файл drivers/char/ Makefile и добавьте в него следующую запись.

obj-m += fishing/ Модули Эта строка указывает системе компиляции, что необходимо войти в подкаталог fishing/ при компиляции модулей. Скорее всего, компиляция драйвера определя ется отдельным конфигурационным параметром, например, CONFIG_FISHING_POLE (как создавать новые конфигурационные параметры, рассмотрено ниже в этой главе в разделе "Управление конфигурационными параметрами"). В этом случае необходи мо добавить строку следующего вида.

obj-$(CONFIG_FISHING_POLE) += fishing/ И наконец, в каталоге drivers/char/fishing необходимо добавить новый файл Makefile, содержащий следующую строку.

obj-m += fishing.о При таких настройках система компиляции перейдет в каталог fishing/ и ском пилирует модуль fishing.ко из исходного файла fishing.с. Да, расширение объ ектного файла указано как.о, но в результате будет создан модуль с расширением.ко.

И снова, скорее всего, факт компиляции модуля будет зависеть от конфигура ционного параметра, в таком случае в Makefile необходимо добавить следующую строку.

obj-$(CONFIG_FISHING_POLE) += fishing.о Однажды драйвер удочки может стать очень сложным. Введение функции авто детектирования наличия лески может привести к тому, что модуль станет очень большим и теперь будет занимать больше одного файла исходного кода. Никаких проблем! Просто нужно внести в Makefile следующую запись.

obj-$(CONFIG_FISHING_POLE) += fishing.о fishing-objs := fishing-main.о fishing-line.о В последнем случае будут скомпилированы файлы f i s hi ng- mai n. с и fishing-line.с и скомпонованы в файл модуля fishing.ко.

Наконец, может потребоваться передать компилятору gcc дополнительные кон фигурационные параметры. Для этого в файле Makefile необходимо добавить сле дующую строку.

EXTRA_CFLAGS += -DTITANIUM_POLE Если вы желаете поместить ваши файлы в каталог dri vers/char/, вместо того чтобы создавать новый подкаталог, то необходимо просто прописать указанные строки (тс, что должны быть прописаны в файле Makefile подкаталога dri vers/ char/fishing/) в файле drivers/char/Makefile.

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

346 Глава Компиляция вне дерева исходных кодов ядра Если вы предпочитаете разрабатывать и поддерживать ваш модуль отдельно от дерева исходных кодов ядра и жить жизнью аутсайдера, просто создайте файл Makefile следующего вида в том каталоге, где находится модуль.

obj-m := fishing.о Такая конфигурация позволяет скомпилировать файл fishing. с в файл fishing. ко.

Если ваш исходный код занимает несколько файлов, то необходимо добавить две строки.

obj-m := fishing.о fishing-objs := fishing-main.о fishing-line.о Такая конфигурация позволяет скомпилировать файлы fi shi ng-mai n. с и fishing-line.с и создать модуль fishing, ко.

Главное отличие от случая, когда модуль находится внутри дерева исходного кода, состоит в процессе сборки. Так как модуль находится за пределами дерева исходных кодов ядра, необходимо указать утилите make местонахождение исходных файлов ядра и файл Makefile ядра. Это также делается просто с помощью следующей ко манды.

make -С /kerncl/source/location SUBDTRS=$PWD modules В этом примере /kernel/source/location — путь к сконфигурированному де реву исходных кодов ядра. Вспомните, что не нужно хранить копию дерева исходных кодов ядра, с которой вы работаете, в каталоге /usr/src/linux, эта копия должна быть где-то в другом месте, скажем где-нибудь в вашем домашнем каталоге.

Инсталляция модулей Скомпилированные модули должны быть инсталлированы в каталог /lib/modules/ version/kernel. Например, для ядра 2.6.10 скомпилированный модуль управления удочкой будет находиться в файле /lib/modules/2.6.10/kernel/drivers/char/ fishing.ко, если исходный код находился непосредственно в каталоге drivers/ char/.

Для инсталляции скомпилированных модулей в правильные каталоги использует ся следующая команда.

make modules_install Разумеется, эту команду необходимо выполнять от пользователя root.

Генерация зависимостей между модулями Утилиты работы с модулями ОС Linux поддерживают зависимости между моду лями. Это означает, что если модуль chum зависит от модуля bai t, то при загрузке модуля chum модуль bai t будет загружен автоматически. Информация о зависимо стях между модулями должна быть сгенерирована администратором. В большинстве поставок ОС Linux эта информация генерируется автоматически и обновляется при Модули загрузке системы. Для генерации информации о зависимостях между модулями не обходимо от пользователя root выполнить следующую команду.

depmod Для быстрого обновления и генерации информации только о более новых моду лях, чем сам файл информации, необходимо от пользователя root выполнить другую команду.

depmod -A Информация о зависимостях между модулями хранится в файле /lib/modules/ version/modules.dep.

Загрузка модулей Наиболее простой способ загрузки модуля — это воспользоваться утилитой insmod.

Эта утилита выполняет самые общие действия. Она просто загружает тот модуль, который ей указан в качестве параметра. Утилита insmod не отслеживает зависимо сти и не выполняет никакой интеллектуальной обработки ошибок. Использовать ее очень просто. От пользователя root необходимо просто выполнить команду insmod module где module— это имя модуля, который необходимо загрузить. Для загрузки модуля управления удочкой необходимо выполнить команду.

insmod fishing Удалить модуль можно аналогичным образом с помощью утилиты rmmod. Для это го от пользователя root нужно просто выполнить команду.

rmmod module Например, удалить модуль управления удочкой можно следующим образом.

rmmod fishing Тем не менее, эти утилиты тривиальные и не обладают интеллектуальным по ведением. Утилита modprobe позволяет обеспечить удовлетворение зависимостей, оповещение об ошибках, интеллектуальную обработку ошибок, а также выполняет множество других расширенных функций. Её настоятельно рекомендуется исполь зовать.

Для загрузки модуля в ядро с помощью утилиты modprobe необходимо от пользо вателя root выполнить команду modprobe module [ module parameters ] где параметр module — это имя модуля, который необходимо загрузить. Все следую щие аргументы интерпретируются как параметры, которые передаются модулю при загрузке. Параметры модулей обсуждаются ниже в одноименном разделе.

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

348 Глава Команда modprobe также может использоваться для удаления модулей из ядра.

Для этого с правами пользователя root необходимо выполнить ее следующим обра зом.

modprobe Pr modules где параметр modules — имя одного или нескольких модулей, которые необходимо удалить. В отличие от команды rmmod, утилита modprobe также удаляет и все моду ли, от которых указанный модуль зависит, если последние не используются.

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

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

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

Благодаря новой системе компиляции ядра "kbuild", которая появилась в серии ядер 2.6, добавление нового конфигурационного параметра является очень простым делом. Все, что необходимо сделать, — это добавить новую запись в файл Kconf ig, который отвечает за конфигурацию дерева исходных кодов ядра. Для драйверов этот файл обычно находится в том же каталоге, в котором находится и исходный код. Если код драйвера удочки находится в каталоге drivers/char/, то необходи мо использовать файл drivers/char/Kconfig.

Если был создан новый каталог и есть желание, чтобы файл конфигурации на ходился в этом новом каталоге, то необходимо на него сослаться из существующего файла Kconf ig. Это можно сделать путем добавления строки source Tdrivers/char/fishing/Kconfig в существующий файл Kconfig, скажем в файл drivers/char/Kconfig.

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

config FISHING_POLE tristate "Fish Master XL support" default n help If you say Y here, support for the Fish Master XL 2000 Titanium with computer interface will be compiled into the kernel and accessible via device node. You can also say M here and the driver will be built as a module named fishing.ko.

If unsure, say N.

Модули Первая строка определяет, какой конфигурационный параметр создается.

Обратите внимание, что префикс CONFIG_ указывать не нужно, он добавляется ав томатически.

Вторая строка указывает на то, что параметр может иметь три состояния (tristate), которые соответствуют следующим значениям: статическая компиляция в ядро (Y), компиляция в качестве модуля (М) или не компилировать драйвер вообще (N). Для того чтобы запретить компиляцию кода, который соответствует конфигурационному параметру, в качестве модуля (допустим, что этот параметр определяет не драйвер.

а просто некоторую дополнительную функцию) необходимо указать ТИП параметра bool вместо t r i s t at e. Текст в кавычках, который следует после этой директивы, определяет название конфигурационного параметра и будет отображаться различны ми утилитами конфигурации.

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

Директива hel p указывает на то, что остальная часть текста будет интерпре тироваться как описание данного модуля. Различные конфигурационные утилиты могут при необходимости отображать этот текст. Так как этот текст предназначен для пользователей и разработчиков, которые будут компилировать ядро, то он дол жен быть коротким и ясным. Обычные пользователя, скорее всего, не будут компи лировать ядро, а сели будут, то тогда они должны понимать, что в этом описании сказано.

Существуют также и другие директивы файла конфигурации. Директива depends указывает на конфигурационные параметры, которые должны быть установлены перед тем, как может быть установлен текущий параметр. Если зависимости не бу дут удовлетворены, то текущий параметр будет запрещен. Например, можно указать следующую директиву.

depends on FISH_TANK При этом текущий модуль не будет разрешен, пока не будет разрешен модуль, со ответствующий конфигурационному параметру CONFIG_FISH_TANK.

Директива s el ect аналогична директиве depends, за исключением того, что она принудительно включает указанный конфигурационный параметр, если вклю чается текущая конфигурационная опция. Ее не нужно использовать так же часто, как директиву depends, потому что она включает другие конфигурационные опции.

Использовать ее так же просто.

select BAIT В этом случае конфигурационный параметр CONF'IG_BAIT автоматически активи зируется при включении конфигурационного параметра CONFIG_FISHING_POLE.

Как для директивы sel ect, так и для директивы depends можно указывать не сколько параметров с помощью оператора &&. В директиве depends с помощью вос клицательного знака перед параметром можно указать требование, что некоторый конфигурационный параметр не должен быть установлен. Например, следующая запись указывает, что для компиляции текущего драйвера необходимо, чтобы был установлен конфигурационный параметр CONFIG_DUMB_DRIVERS и не был установ лен параметр CONFIG_NO_FISHING_ALLOWED.

depends on DUMB_DRIVERS && !NO_FISHING_ALLOWED 350 Глава После директив t r i s t a t e и bool можно указать директиву if, что позволяет сделать соответствующий параметр зависимым от другого конфигурационного па раметра. Если условие не выполняется, то конфигурационный параметр не только запрещается, но и не будет отображаться утилитами конфигурации. Например, сле дующая строка указывает, что функция "Deep Sea Mode" будет доступна, только если разрешен конфигурационный параметр CONFIG_OKEAN.

bool TDeep Sea ModeY if OCEAN Директива if также может быть указана после директивы default, что означает, что значение по умолчанию будет установлено, только если выполняется условие, указанное в директиве if.

Система конфигурации экспортирует несколько метапараметров, чтобы упро стить процесс конфигурации. Параметр CONFIG_EMBEDDED устанавливается только тогда, когда пользователь указывает, что он хочет видеть вес параметры, отвечаю щие за запрещение некоторых ключевых позможностей ядра (обычно с целью со хранения памяти на встраиваемых системах). Параметр CONFIG_BROKEN_ON_SMP используется, чтобы указать, что драйвер не рассчитан на системы с симметричной многопроцессорностью. Обычно этот параметр не устанавливается, при этом от пользователя требуется, чтобы он сам убедился в возможности компиляции драйве ра для SMP. Новые драйверы этот флаг использовать не должны.

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

Параметры модулей Ядро Linux предоставляет возможность драйверам определять параметры, кото рые пользователь будет указывать при загрузке ядра или модуля. Эти параметры бу дут доступны коду модуля в качестве глобальных переменных. Указанные параметры модулей также будут отображаться в файловой системе sysfs (см. главу 17, "Объекты kobject и файловая система sysf "). Определять параметры модуля и управлять ими просто.

Параметр модуля определяется с помощью макроса module_param () следующим образом.

module_param(name, type, perm)

;

где аргумент name — это имя неременной, которая появляется в модуле, и имя пара метра, который может указать пользователь. Аргумент type — это тип данных па раметра. Значения типа могут быть следующими: byte, short, ushort, i nt. uint, long, ulong, charp, bool или invbool. Эти значения соответствуют следующим типам данных: байт

;

короткое целое число

;

короткое целое число без знака

;

целое число

;

целое число без знака

;

длинное целое

;

длинное целое число без знака

;

указа тель на строку символов

;

булев тип

;

булев тип, значение которого инвертируется по сравнению с тем, которое указывает пользователь. Данные типа byte хранятся в пе ременной типа char, а данные булевых типов — в переменных типа int. Остальные типы соответствуют аналогичным типам языка С. Наконец, аргумент perm указыва М одул и ет права доступа к соответствующему файлу в файловой системе sysfs. Права досту па можно указать как в обычном восьмеричном формате, например 0644 (владелец имеет права на чтение и запись, группа имеет права на чтение и запись, остальные пользователи имеют право только на чтение), так и в виде определений препроцес сора, объединенных с помощью оператора "| ", например S_IRUGO | S_IWUSR (все могут считывать данные, а владелец также и записывать). Нулевое значение этого параметра приводит к тому, что соответствующий файл в файловой системе sysfs не появляется.

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

/* параметр модуля, который управляет переменной bait */ static int allow live bait = 1

;

/* по умолчанию включено */ module_param(allow_live_bait, bool, 0644)

;

/* булев тип */ Это определение должно быть в глобальной области видимости, т.е. неременная allow_live_bait должна быть глобальной.

Существует возможность дать внешнему параметру модуля имя, отличное от име ни переменной. Это можно сделать с помощью макроса module_param_named ().

module_param_named(name, variable, type, perm)

;

где name — это имя внешнего параметра модуля, a variable — имя внутренней гло бальной переменной модуля, как показано ниже.

static unsigned int max_test = DEFAULT_МАХ_LINE_TEST

;

module_param_named (maximum_line_test, max_test, int, 0)

;

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

static char *name

;

module_param(name, charp, 0)

;

При необходимости ядро может скопировать строку в заранее определенный массив символов, который указывает разработчик. Это делается с помощью макроса module_param_string().

module_param_string(name, string, len, perm)

;

где name — это имя внешнего параметра, st ri ng — имя внутренней переменной, которая содержит указатель на область памяти массива, len — размер буфера string (или некоторое меньшее число, чем размер буфера, что, однако, обычно не имеет смысла), perm — права доступа к файлу на файловой системе sysfs (нулевое значение запрещает доступ к параметру через sysfs). Пример показан ниже.

static char species[BUF_LEN]

;

module_param_string (specif ies, species, BUF_LEN, 0)

;

В качестве параметров модуля также можно передавать список значений, кото рые разделены запятой и в коде модуля будут записаны в массив данных. Эти пара 352 Глава метры модуля можно обработать с помощью макроса module_param_array() следу ющим образом.

module_param array(name, type, nump, perm)

;

В данном случае аргумент name — это имя внешнего параметра и внутренней пере менной, type — это тип данных одного значения, a perm — это права доступа к файлу на файловой системе sysfs. Новый аргумент nump — это указатель на целочисленное значение, где ядро сохраняет количество элементов, записанных в массив. Обратите внимание, что массив, который передается в качестве параметра name, должен быть выделен статически. Ядро определяет размер массива на этапе компиляции и гаран тирует, что он не будет переполнен. Как использовать данный макрос, показано в следующем примере.

static int fish[MAX_FISH]

;

static int nr_fish

;

module_param_array(fish, int, &nr_fish, 0444)

;

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

module_param_array_named(name, array, type, nump, perm)

;

Параметры идентичны аналогичным параметрам других макросов.

Наконец, параметры модуля можно документировать, используя макрос MODULE_ PARM_DESC().

static unsigned short size = 1

;

module_param(size, ushort, 0644)

;

MODULE_PARMDESC(size, "The size in inches of the fishing pole " \ "connected to this computer.")

;

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

Экспортируемые символы При загрузке модули динамически компонуются с ядром. Так же как и в случае динамически загружаемых бинарных файлов пространства пользователя, в коде мо дулей могут вызываться только те функции ядра (основного образа или других мо дулей), которые явно экспортируются для использования. В ядре экспортирование осуществляется с помощью специальных директив EXPORT_SYMBOL () и EXPORT_ SYMBOL_GPL().

Функции, которые экспортируются, доступны для использования модулями.

Функции, которые не экспортируются, не могут быть вызваны из модулей. Правила компоновки и вызова функций для модулей значительно более строгие, чем для основного образа ядра. Код ядра может использовать любые интерфейсы ядра (кро ме тех, которые определены с ключевым словом static), потому что код ядра ком понуется в один выполняемый образ. Экспортируемые символы, конечно, тоже не должны определяться как stati c.

Набор символов ядра, которые экспортируются, называется экспортируемым ин терфейсом ядра или даже (здесь не нужно удивляться) API ядра.

Модули Экспортировать символы просто. После того как функция определена, необходи мо вызвать директиву EXPORT_SYMBOL ().

/* * get_pirate_beard_color — возвратить значение цвета бороды текущего * пирата pirate — это глобальная переменная, доступная из данной * функции цвета определены в файле */ int get_pirate_beard_color(void) { return pirate->beard->color

;

} EXPORT_SYMBOL(get_pirate_beard_color)

;

Допустим, что функция get_pirate_beard_col or() объявлена в заголовочном файле и ее может использовать любой модуль.

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

EXPORT_SYMBOL_GPL(get_pirate_beard_color)

;

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

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

В следующей главе будут рассмотрены объекты kobject и файловая система sysf's, которые являются основным интерфейсом к драйверам устройств и, следовательно, к модулям ядра.

354 Глава Объекты kobject и файловая система sysfs нифицированная модель представления устройств — это существенно новая осо бенность, которая появилась в ядрах серии 2.6. Модель устройств— это еди У ный механизм для представления устройств и описания их топологии в системе.

Использование единого представления устройств позволяет получить следующие преимущества.

• Уменьшается дублирование кода.

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

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

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

• Обеспечивается возможность связывания устройств с их драйверами и наоборот.

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

• Обеспечивается возможность просмотра иерархии устройств от листьев к кор ню и выключения питания устройств в правильном порядке.

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

Объекты kobject Сердцем модели представления устройств являются объекты kobject, которые представляются с помощью структуры st ruct kobject, определенной в файле . Тип kobject аналогичен классу Object таких объектно-ори ентированных языков программирования, как С# и Java. Этот тип определяет общую функциональность, такую как счетчик ссылок, имя, указатель на родительский объ ект, что позволяет создавать объектную иерархию.

Структура, с помощью которой реализованы объекты kobject, имеет следующий вид.

struct kobject { char *k_name

;

char name[KOBJ_NAME_LEN]

;

struct kref kref

;

struct list_head entry

;

struct kobject *parent

;

struct kset *kset

;

struct kobj_type *ktype

;

struct dentry *dentry

;

}

;

Поле k_name содержит указатель на имя объекта. Если длина имени меньше KOBJ_NAME_LEN, что сейчас составляет 20 байт, то имя хранится в массиве name, a ноле kname указывает на первый элемент этого массива. Если длина имени больше KOBJ_NAME_LEN байт, то динамически выделяется буфер, размер которого достато чен для хранения строки символов имени, имя записывается в этот буфер, а поле k_name указывает на него.

Указатель parent указывает на родительский объект данного объекта kobject.

Таким образом, с помощью структур kobject может быть создана иерархия объ ектов в ядре, которая позволяет устанавливать соотношения родства между раз личными объектами. Как будет видно дальше, с помощью файловой системы sysfs осуществляется представление в пространстве пользователя той иерархии объектов kobject, которая существует в ядре.

Указатель dentry содержит адрес структуры struct dentry, которая представ ляет этот объект в файловой системе sysfs.

Поля kref, ktype и kset указывают на экземпляры структур, которые использу ются для поддержки объектов kobject. Поле entry используется совместно с полем kset. Сами эти структуры и их использование будут обсуждаться ниже.

Обычно структуры kobject встраиваются в другие структуры данных и сами по себе не используются. Например, такая важная структура, как struct cdev, имеет поле kobj.

356 Глава /* структура cdev - объект для представления символьных устройств */ struct cdev { struct kobject kobj

;

struct module *owner

;

struct file_operations *ops

;

struct list_head list

;

dev_t dev

;

unsigned int count

;

}

;

Когда структуры kobject встраиваются в другие структуры данных, то последние получают те стандартизированные возможности, которые обеспечиваются структу рами kobject. Еще более важно, что структуры, которые содержат в себе объекты kobject, становятся частью объектной иерархии. Например, структура cdev пред ставляется в объектной иерархии с помощью указателя на родительский объект cdev->kobj->parent и списка cdev->kobj->entry.

Типы ktype Объекты kobject могут быть связаны с определенным типом, который называ ется ktype. Типы ktype представляются с помощью структуры struct kobj_type, определенной в файле следующим образом.

struct kobj_type { void (*release)(struct kobject * )

;

struct sysfs_ops *sysfs_ops

;

struct attribute **default_attrs

;

}

;

Тип ktype имеет простое назначение— представлять общее поведение для не которого семейства объектов kobject. Вместо того чтобы для каждого отдельного объекта задавать особенности поведения, эти особенности связываются с их полем ktype, и объекты одного "типа" характеризуются одинаковым поведением.

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

Поле sysfs_ops указывает на структуру sysfs_ops. Эта структура определяет поведение файлов на файловой системе sysfs при выполнении операций записи и чтения. Более детально она рассматривается в разделе "Добавлепие файлов на фай ловой системе sysfs".

Наконец, поле default_attrs указывает на массив структур attri bute. Эти структуры определяют атрибуты, которые связаны с объектом kobject и использу ются но умолчанию. Атрибуты соответствуют свойствам данного объекта. Если не который объект kobject экспортируется через файловую систему sysfs, то атрибуты экспортируются как отдельные файлы. Последний элемент этого массива должен со держать значению NULL.

Объекты kobject и файловая система sysfs Множества объектов kset Множества kset представляют собой коллекции объектов kobject. Множество kset работает как базовый контейнерный класс для объектов, например, "все блоч ные устройства". Множества kset очень похожи на типы ktype, и возникает вопрос:

"Для чего нужны два разных обобщения?" Множество kset объединяет несколько объектов kobject, а типы ktype определяют общие свойства, которые связаны с объектами kobject одного типа. Существует возможность объединить объекты одного типа ktype в различные множества kset.

Поле kset объекта kobject указывает на связанное с данным объектом множе ство kset. Множество объектов kset представляется с помощью структуры kset, которая определена в файле следующим образом.

struct kset { struct subsystem *subsys

;

struct kobj_type *ktype

;

struct list_head list

;

struct kobject kobj

;

struct kset_hotplug_ops *hotplug_ops

;

}

;

Указатель ktype указывает на структуру ktype, которая определяет тип всех объ ектов данного множества, поле l i st - список всех объектов kobject данного мно жества, поле kobj — объект kobject, который представляет базовый класс для всех объектов данного множества, а поле hotplug_ops указывает на структуру, которая определяет поведение объектов kobject при горячем подключении устройств, свя занных с данным множеством.

Наконец, поле sybsys указывает на структуру struct subsystem, которая связа на с данным множеством kset.

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

Несмотря на их важную роль, подсистемы представляются с помощью очень про стой структуры данных — struct subsystem.

struct subsystem { struct kset ksot

;

struct rw_semaphore rwsem

;

}

;

Структура subsystem содержит только одно множество kset, тем не менее не сколько множеств kset могут указывать на общую структуру subsystem с помощью 358 Глава поля subsys. Такие однонаправленные взаимоотношения означают, что нет возмож ности определить все множестпа подсистемы, только имея ее структуру subsystem.

Поле kset, которое содержится в структуре subsystem, — это множество kset подсистемы, которое используется по умолчанию, чтобы зафиксировать положение этой подсистемы в иерархии объектов.

Поле rwsem структуры subsystem — это семафор чтения-записи (см. главу 9, "Средства синхронизации в ядре"), который используется для защиты подсистемы и ее множеств kset от конкурентного доступа. Все множества kset должны принадле жать какой-нибудь подсистеме, поскольку они используют семафор подсистемы для защиты своих данных от конкурентного доступа.

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

Самым важным является объект kobj ect, который представляется с помощью структуры s t r uct kobj ect. Структура kobj ect используется для представления наиболее общих объектных свойств структур данных ядра, таких как счетчик ссы лок, взаимоотношения родитель-порожденный и имя объекта. С помощью структуры kobject эти свойства можно обеспечить одинаковым для всех стандартным спосо бом. Сами по себе структуры kobject не очень полезны, они обычно встраиваются в другие структуры данных.

С каждым объектом kobj ect связан один определенный тип данных— ktype, который представляется с помощью структуры s t r uct kobj_type. На экземпляр такой структуры указывает поле ktype каждого объекта kobject. С помощью типов ktype определяются некоторые общие свойства объектов: поведение при удалении объекта, поведение, связанное с файловой системой sysfs, а также атрибуты объекта.

Объекты kobj ect группируются в множества, которые называются ks et.

Множества kset представляются с помощью структур данных st r uct kset. Эти множества предназначены для двух целей. Во-первых, они позволяют использовать встроенный в них объект kobj ect в качестве базового класса для группы других объектов kobject. Во-вторых, они позволяют объединять вместе несколько связан ных между собой объектов kobj ect. На файловой системе sysfs объекты kobj ect представляются отдельными каталогами файловой системы. Связанные между собой каталоги, например все подкаталоги одного каталога, могут быть включены в одно множество kset.

Подсистемы соответствуют большим участкам ядра и являются набором мно жеств kset. Подсистемы представляются с помощью структур st ruct subsystem.

Все каталоги, которые находятся в корне файловой системы sysfs, соответствуют подсистемам ядра.

На рис. 17.1 показаны взаимоотношения между этими структурами данных.

Объекты kobject и файловая система sysfs Подсистема Подсистема kset kobj kset kobj kobj kobj kobj kobj kobj kobj Рис. 17.1. Взаимоотношения между объектами kobject, множествами kset и подсистемами Управление и манипуляции с объектами kobj ect Теперь, когда у нас уже есть представление о внутреннем устройстве объектов kobject и связанных с ними структурах данных, самое время рассмотреть экспор тируемые интерфейсы, которые дают возможность управлять объектами kobject и выполнять с ними другие манипуляции. В основном, разработчикам драйверов не посредственно не приходится иметь дело с объектами kobject. Структуры kobject встраиваются в некоторые специальные структуры данных (как это было в приме ре структуры устройства посимвольного ввода-вывода) и управляются "за кадром" с помощью соответствующей подсистемы драйверов. Тем не менее, объекты kobject не всегда могут оставаться невидимыми, иногда с ними приходится иметь дело, как при разработке кода драйверов, так и при разработке кода управления подсистема ми ядра.

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

void kobject_init(struct kobject *kobj)

;

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

memset(kobj, 0, sizeof (*kobj))

;

После заполнения нулями безопасным будет инициализация полей parent и kset, как показано в следующем примере.

360 Глава kobj = kmalloc(sizeof (*kobj), GFP_KERNEL)

;

if (!kobj) return -ENOMEM

;

memset(kobj, 0, sizeof (*kobj))

;

kobj->ksct - kset

;

kobj->parent = parent_kobj

;

kobject_init (kobj)

;

После инициализации необходимо установить имя объекта с помощью функции kobject_set_name(), которая имеет следующий прототип.

int kobject_set_name(struct kobject * kobj, const char * fmt,,... )

;

Эта функция принимает переменное количество параметров, по аналогии с функ циями pri nt f () и pri nt k (). Как уже было сказано, на имя объекта указывает поле k_name структуры kobject. Если это имя достаточно короткое, то оно хранится в статически выделенном массиве name, поэтому есть смысл без необходимости не указывать длинные имена.

После того как для объекта выделена память и объекту присвоено имя, нужно установить значение его поля kset, а также опционально поле ktype. Последнее необходимо делать только в том случае, если множество kset не предоставляет типа ktype для данного объекта, в противном случае значение поля ktype, которое указано в структуре kset, имеет преимущество. Если интересно, почему объекты kobject имеют свое поле ktype, то добро пожаловать в клуб!

Счетчики ссылок Одно из главных свойств, которое реализуется с помощью объектов kobject, — это унифицированная система поддержки счетчиков ссылок. После инициализации количество ссылок на объект устанавливается равным единице. Пока значение счет чика ссылок на объект не равно нулю, объект существует в памяти, и говорят, что он захвачен (pinned, буквально, пришпилен). Любой код, который работает с объектом, вначале должен увеличить значение счетчика ссылок. После того как код закончил работу с объектом, он должен уменьшить значение счетчика ссылок. Увеличение значения счетчика называют захватом (getting), уменьшение — освобождением (putting) ссылки на объект. Когда значение счетчика становится равным нулю, объект может быть уничтожен, а занимаемая им память освобождена.

Увеличение значения счетчика ссылок выполняется с помощью функции kobject_get().

struct kobject * kobject_get(struct kobject *kobj)

;

Эта функция возвращает указатель на объект kobject в случае успеха и значение NULL в случае ошибки.

Уменьшение значения счетчика ссылок выполняется с помощью функции kobject_put().

void kobject put(struct kobject *kobj)

;

Объекты kobject и файловая система sysfs Если значение счетчика ссылок объекта, который передается в качестве параме тра, становится равным нулю, то вызывается функция, на которую указывает указа тель rel ease поля ktype этого объекта.

Структуры kref Внутреннее представление счетчика ссылок выполнено с помощью структуры kref, которая определена в файле следующим образом.

struct kref{ atomic_t refcount

;

}

;

Единственное поле этой структуры — атомарная переменная, в которой хранится значение счетчика ссылок. Структура используется просто для того, чтобы выпол нять проверку типов. Чтобы воспользоваться структурой kref, необходимо ее ини циализировать с помощью функции kref _i ni t ().

void kref_init(struct kref *krcf) { atomic_set(&kref->refcount, 1)

;

} Как видно из определения, эта функция просто инициализирует атомарную пере менную тина atomic_t в значение, равное единице.

Следовательно, структура kref является захваченной сразу же после инициализа ции, так же ведут себя и объекты kobject.

Для того чтобы захватить ссылку на структуру kref, необходимо использовать функцию kref_get ().

void kref_get(struct kref *kref) { WARN_ON(!atomic_read(&kref->refcount))

;

atomic_inc(&kref->refcount)

;

} Эта функция увеличивает значение счетчика ссылок на единицу. Она не возвра щает никаких значений. Чтобы освободить ссылку на структуру kref, необходимо использовать функцию kref_put ().

void kref_put(struct kref *kref, void (*release) (struct kref *kref)) { WARN_ON(release == NULL)

;

WARN_ON(release == (void (*)(struct kref *))kfree)

;

if (atomic dec_and_test (&kref->refcount)) release (kref)

;

} Эта функция уменьшает значение счетчика ссылок на единицу и вызывает функ цию rel ease (), которая передастся ей в качестве параметра, когда значение счет чика ссылок становится равным нулю. Как видно из использованного выражения WARM_ON (), функция rel ease () не может просто совпадать с функцией kfrее (), 362 Глава а должна быть специальной функцией, которая принимает указатель на структуру struct kref в качестве своего единственного параметра и не возвращает никаких значений.

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

Все эти функции определены в файле l i b/ kr ef. c и объявлены в файле .

Файловая система sysfs Файловая система sysfs — это виртуальная файловая система, которая существу ет только в оперативной памяти и позволяет просматривать иерархию объектов kobject. Она позволяет пользопателям просматривать топологию устройств опера ционной системы в виде простой файловой системы. Атрибуты объектов kobject могут экспортироваться в виде файлов, которые позволяют считывать значения пе ременных ядра, а также опционально записывать их.

Хотя изначально целью создания модели представления устройств было описа ние топологии устройств системы для управления электропитанием, файловая си стема sysfs стала удачным продолжением этой идеи. Для того чтобы упростить отлад ку, разработчик унифицированной модели устройств решил экспортировать дерево устройств в виде файловой системы. Такое решение показало свою полезность вна чале в качестве замены файлов, связанных с устройствами, которые раньше экспор тировались через файловую систему /ргос, а позже в качестве мощного инструмен та просмотра информации о системной иерархии объектов. Вначале, до появления объектов kobject, файловая система sysfs называлась driverfs. Позже стало ясно — новая объектная модель была бы очень кстати, и в результате этого появилась кон цепция объектов kobject. Сегодня каждая система, на которой работает ядро 2.6, имеет поддержку файловой системы sysfs, и практически во всех случаях эта файло вая система монтируется.

Основная идея работы файловой системы sysfs — это привязка объектов kobject к структуре каталогов с помощью поля dentry, которое есть в структуре kobject.

Вспомните из материала главы 12, "Виртуальная файловая система", что структура dentry используется для представления элементов каталогов. Связывание объектов с элементами каталогов проявляется в том, что каждый объект просто видится как каталог файловой системы. Экспортирование объектов kobject в виде файловой системы выполняется путем построения дерева элементов каталогов в оперативной памяти. Но обратите внимание, объекты kobject уже образуют древовидную струк туру — нашу модель устройств! Поэтому простое назначение каждому объекту иерар хии, которые уже образуют дерево в памяти, соответствующего элемента каталога позволяет легко построить файловую систему sysfs.

На рис. 17.2 показан частичный вид файловой системы sysfs, которая смонтиро вана на каталог /sys.

Корневой каталог файлопой системы sysfs содержит семь подкаталогов: block, bus, class, devices, firmware, module и power. В каталоге block содержатся каталоги для каждого зарегистрированного в системе устройства блочного ввода-вывода.

Объекты kobject и файловая система sysfs /sys block/ fd hda dev device->../devices/psi0000:00/0000:00:1f.1/ide/0. hda dev size start star hda hda hda hda hda queue lidc hdd loop loop Ioop Ioop Ioop Ioop Ioop Ioop md bus/ class/ devices/ firmware/ power Рис. 17.2. Содержимое части каталога /sys Каждый из каталогов в свою очередь содержит подкаталоги, соответствующие разделам блочного устройства. Каталог bus позволяет просматривать информа цию о системных шинах. В каталоге class представлена информация о системных устройствах, которая организована в соответствии с высокоуровневыми функциями этих устройств. Каталог devices содержит информацию о топологии устройств в системе. Она отображается непосредственно на иерархию структур устройств ядра.

Каталог firmware содержит специфичное для данной системы дерево низкоуровне вых подсистем, таких как ACPI, EDD, EFT и т.д. В каталоге power содержатся данные по управлению электропитанием всех устройств системы.

Наиболее важным является каталог devices, который экспортирует модель устройств ядра во внешний мир. Структура каталога соответствует топологии устройств в системе. Большинство информации, которая содержится в других ка талогах, — это просто другое представление данных каталога devices. Например, в каталоге /sys/class/net/ информация представлена в соответствии с высоко уровневым представлением зарегистрированных сетевых устройств. В этом каталоге может содержаться подкаталог eth0, который содержит символьную ссылку device на соответствующее устройство каталога devices.

Посмотрите на содержимое каталога /sys той системы Linux, к которой вы имеете доступ. Такое представление системных устройств является очень четким и ясным. Оно показывает взаимосвязь между высокоуровневым представлением ин формации в каталоге class, низкоуровневым представлением в каталоге devices Глава и драйверами устройств — в каталоге bus. Такое представление взаимосвязи между устройствами очень информативно. Оно становится еще более ценным, если осо знать, что все эти данные свободно доступны и описывают все то, что происходит внутри ядра.

Добавление и удаление объектов на файловой системе sysfs Инициализированные объекты kobject автоматически не экспортируются через файловую систему sysfs. Для того чтобы сделать объект видимым через sysfs, необхо димо использовать функцию kobject_add().

int kobject_add(struct kobject *kobj)

;

Положение объекта на файловой системе sysfs зависит от его положения в объ ектной иерархии. Если установлен указатель parent объекта, то объект будет ото бражен внутри каталога, соответствующего объекту, на который указывает указатель parent. Если указатель parent не установлен, то объект будет отображен в каталоге, соответствующем значению переменной kset->kobj. Если для некоторого объекта не установлены ни значение поля parent, ни значение поля kset, то считается, что данный объект не имеет родительского и будет отображаться в корневом каталоге файловой системы sysfs. Такое поведение практически всегда соответствует тому, что нужно. Поэтому одно из полей parent или kset (или оба) должно быть установ лено правильным образом перед вызовом функции kobject_add (). Имя каталога, который представляет объект kobject в файловой системе sysfs, будет определяться значением поля kobj->name.

Вместо того чтобы последовательно вызывать функции kobj ect _i ni t () и kobject_add(), можно вызвать функцию kobject_register ().

int kobject_register(struct kobject *kobj)

;

Удаление объекта из файловой системы sysfs выполняется с помощью функции kobject_del().

void kobject_del(struct kobject *kobj)

;

Функция kob j е c t unr e g i s t er () сочетает в себе выполнение функций kobject_del() и kobject_put().

void kobject_unregister(struct kobject * kobj)

;

Все эти четыре функции определены в файле l ib/kobj ect. с и объявлены в файле .

Если вас заинтересовала информация о файловой системе sysfs, то, вероятно, вам будет интересно также ознакомиться с HAL, hardware abstraction layer (уровень абстракции аппаратного обеспече ния), информация о котором доступна по адресу ht t p: //hal. f r eedes kt op. or g/. Подсистема HAL позволяет создать в оперативной памяти базу данных на основании информации файловой системы sysfs, объединяя вместе понятия классов, устройств и драйверов. На основании этих дан ных уровень HAL предоставляет API, которое позволяет разрабатывать более интеллектуальные программы.

Объекты kobject и файловая система sysfs Добавление файлов на файловой системе sysfs Объекты kobject отображаются на каталоги, и такое отображение выполняется естественным образом. А как насчет создания файлов? Файловая система sysfs — это не что иное, как дерево каталогов без файлов.

Атрибуты, используемые по умолчанию Набор файлов, которые создаются в каталоге по умолчанию, определяется с по мощью поля ktype объектов kobject и множеств kset. Следовательно, все объекты kobject одного типа имеют один и тот же набор файлов в каталогах, которые этим объектам соответствуют. Структура kobject_type содержит поле default_attrs, которое представляет собой массив структур attribute. Атрибуты отображают дан ные ядра на файлы в файловой системе sysfs.

Структура attributes определена в файле .

/* структура attribute - атрибуты позволяют отобразить данные ядра на файлы файловой системы sysfs */ struct attribute { char *name

;

/* имя атрибута */ struct module *owner

;

/* модуль, если есть, которому принадлежат данные */ mode_t mode

;

/* права доступа к файлу */ }

;

Поле name содержит имя атрибута. Такое же имя будет иметь и соответствующий файл на файловой системе sysfs. Поле owner — это указатель на структуру module, которая представляет загружаемый модуль, содержащий соответствующие данные.

Если такого модуля не существует, то значение поля равно NULL. Поле mode имеет тип mode_t и указывает права доступа к файлу на файловой системе sysfs. Если атри бут предназначен для чтения всеми, то флаг прав доступа доллсен быть установлен в значение S_IRUGO, если атрибут имеет право на чтение только для владельца, то права доступа устанавливаются в значение S_IRUSR. Атрибуты с правом на запись, скорее всего, будут иметь права доступа S_IRUGO | S_IWUSR. Все файлы и каталоги на файловой системе sysfs принадлежат пользователю с идентификаторами пользова теля и группы равными нулю.

Структура at t r i but e используется для представления атрибутов, а структура sysfs_ops описывает, как эти атрибуты использовать. Поле sysfs_ops — это ука затель на одноименную структуру, которая определена в файле следующим образом.

struct sysfs_ops { /* метод вызывается при чтении файла на файловой системе sysfs */ ssize_t (*show) (struct kobject *kobj, struct attribute *attr, char *buffer)

;

/* метод вызывается при записи файла на файловой системе sysfs */ ssize_t (*store) (struct kobject *kobj, struct attribute *attr, const char *buffer, size_t size)

;

}

;

366 Глава Метод show() вызывается при чтении файла. Он должен выполнить копирова ние значения атрибута, который передается в качестве параметра attr, в буфер, на который указывает параметр buffer. Размер буфера равен PAGE_SIZE байт. Для ап паратной платформы значение PAGE_SIZE равно 4096 байтов. Функция должна воз вратить количество байтов данных, которые записаны в буфер в случае успешного завершения, и отрицательный код ошибки, если такая ошибка возникает.

Метод store() вызывается при записи. Он должен скопировать size байт дан ных из буфера buffer в атрибут attr. Размер буфера всегда равен PAGE_SIZE или меньше. Функция должна возвратить количество байтов данных, которые прочита ны из буфера при успешном выполнении, и отрицательный код ошибки в случае не удачного завершения.

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

Создание нового атрибута Обычно атрибутов, которые используются по умолчанию и предоставляются ти пом ktype, связанным с объектом kobject, оказывается достаточно. Действительно, все объекты kobject одного типа должны быть чём-то похожи друг на друга или даже быть идентичными по своей природе. Например, для всех разделов жестких дисков один и тот же набор атрибутов должен подходить для всех объектов kobject.

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

Тем не менее иногда требуется, чтобы определенный экземпляр объекта kobject имел некоторые специфические свойства. Для таких объектоп может оказаться же лательным (или необходимым) создать атрибут, которого нет у общего типа данного объекта. Для такого случая ядро предоставляет функцию sysf s_create_file () для добавления атрибута к существующему объекту.

int sysfs_create_file(struct kobject *kobj, const struct attribute *attr)

;

Эта функция позволяет привязать структуру at t ri but e, на которую указывает параметр at t r, к объекту kobject, на который указывает параметр kobj. Перед тем как вызвать эту функцию, необходимо установить значение атрибута (заполнить поля структуры). Эта функция возвращает значение нуль в случае успеха и отрица тельное значение в случае ошибки.

Обратите внимание, что для обработки указанного атрибута используется струк тура sysfs_ops, соответствующая типу ktype объекта. Иными словами, существую щие функции show () и store {), которые используются для объекта по умолчанию, должны иметь возможность обработать вновь созданный атрибут.

Кроме того, существует возможность создавать символьные ссылки. Создать сим вольную ссылку на файловой системе sysfs можно с помощью вызова следующей функции.

int sysfs_create_link(struct kobject *kobj, struct kobject *target, char *name)

;

Объекты kobject и файловая система sysfs Эта функция создает символьную ссылку с именем name в каталоге объекта, соот ветствующего параметру kobj, на каталог, соответствующий параметру target. Эта функция возвращает нулевое значение в случае успеха и отрицательный код ошибки в противном случае.

Удаление созданного атрибута Удаляется атрибут с помощью вызова функции sysfs_remove_f ile ().

void sysfs_remove_file(struct kobject *kobj, const struct attribute *attr)

;

После возврата из этой функции указанный атрибут больше не отображается в каталоге объекта.

Символьная ссылка, созданная с помощью функции sysfs_create_link (), мо жет быть удалена с помощью функции sysfs_remove_link().

void sysfs_remove_link (struct kobject *kobj, char *name)

;

После возврата из функции символьная ссылка с именем name удаляется из ката лога, на который отображается объект kobj.

Все эти четыре функции объявлены в файле . Функции sysfs_create_file() и sysfs_remove_file() определены в файле fs/sysfs/ file.с, а функции sysfs_create_link() и sysfs_remove_link() — в файле fs/sysfs/symlink.c.

Соглашения по файловой системе sysfs Файловая система sysfs — это место, где должна реализовываться функциональ ность, для которой раньше использовался системный вызов i oct l ( ) для специ альных файлов устройств, или файловая система procfs. Сегодня модно выполнять такие вещи через атрибуты файловой системы sysfs в соответствующем каталоге.

Например, вместо того чтобы реализовать новую директиву i oct l () для специаль ного файла устройства, лучше добавить соответствующий атрибут в каталоге файло вой системы sysfs, который относится к этому устройству. Такой подход позволяет избежать использования небезопасных, из-за отсутствия проверки типов аргументов, директив i oct l (), а также файловой системы /рrос с ее бессистемным расположе нием файлов и каталогов.

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

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

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

Во-вторых, данные файловой системы sysfs должны быть организованы в виде четкой иерархии. Для этого необходимо правильно разрабатывать связи "родитель потомок" объектов kobject. Связывать атрибуты с объектами kobject необходимо с учетом того, что эта иерархия объектов существует не только в ядре, но и экспор тируется в пространство пользователя. Структуру файловой системы sysfs необходи мо поддерживать в четком виде!

Наконец, необходимо помнить, что файловая система sysfs является службой ядра и в некотором роде интерфейсом ядра к прикладным программам (Application Binary Interface, ABT). Пользовательские программы должны разрабатываться в соот ветствии с наличием, положением, содержимым и поведением каталогов и файлов на файловой системе sysfs. Изменение положения существующих файлов крайне не рекомендуется, а изменение поведения атрибутов, без изменения их имени или по ложения, может привести к серьезным проблемам.

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

Уровень событий ядра Уровень событий ядра (kernel event layer) — это подсистема, которая позволяет передавать информацию о различных событиях из ядра в пространство пользовате ля и реализована, как вы уже, наверное, догадываетесь, на базе объектов kobject.

После выпуска ядра версии 2.6.0 стало ясно, что необходим механизм для отправле ния сообщений из ядра в пространство пользователя, в частности для настольных рабочих компьютеров, что позволит сделать такие системы более функциональны ми, а также лучше использовать асинхронную обработку. Идея состояла в том, что ядро будет помещать возникающие события в стек. Например, "Жесткий диск пере полнен!", "Процессор перегрелся!", "Раздел диска смонтирован!", "На горизонте по явился пиратский корабль!" (последнее, конечно, шутка).

Первые реализации подсистемы событий ядра появились незадолго до того, как эта подсистема стала тесно связанной с объектами kobject и файловой системой sy sfs. В результате такой связи реализация получилась достаточно красивой. В модели уровня событий ядра, события представляются в виде сигналов, которые посылают ся объектами, в частности объектами типа kobject. Так как объекты отображаются на элементы каталогов файловой системы sysfs, то источниками событий являются определенные элементы пути на файловой системе sysfs. Например, если поступив шее событие связано с первым жестким диском, то адресом источника события яв ляется каталог /sys/block/hda. Внутри же ядра источником события является со ответствующий объект kobject.

Каждому событию присваивается определенная строка символов, которая пред ставляет сигнал и называется командой (verb) или действием (action). Эта строка симво лов содержит в себе информацию о том, что именно произошло, например изменение (modified) или размонтирование (unmounted).

Объекты kobject и файловая система sysfs Каждое событие может нести в себе некоторую дополнительную информацию (дополнительную нагрузку, payload). Вместо того чтобы передавать в пространство пользователя строку, которая содержит эту полезную информацию, данная дополни тельная информация представляется с помощью атрибутов, отображаемых на фай ловой системе sysfs.

События ядра поступают из пространства ядра в пространство пользователя че рез интерфейс netl ink. Интерфейс netl i nk - это специальный тип высокоско ростного сетевого сокета групповой передачи (multicast), который используется для передачи сообщений, связанных с сетевой подсистемой. Использование интерфейса netlink позволяет выполнить обработку событий ядра с помощью простых блоки рующих вызовов функций для чтения информации из сокетов. Задача пространства пользователя— реализовать системный процесс-демон, который выполняет прослу шивание сокета, считывает информацию о всех приходящих событиях, обрабатыва ет их и отправляет полученные сообщения в системный стек пространства пользо вателя. Одна из возможных реализаций такого демона, работающего в пространстве пользователя, — это D-BUS2. который также реализует и системную шину сообщений.

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

Для отправки события в пространство пользователя код ядра должен вызвать функцию kobject_uevent().

int kobject_uevent(struct kobject *kobj, enurn kobject_action action, struct attribute *attr)

;

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

Второй параметр позволяет указать команду или событие, которое описывает сиг нал. Сгенерированное событие ядра будет содержать строку, которая соответству ет номеру, передаваемому в качестве значения параметра enurn kobject_action.

Вместо того чтобы непосредственно передать строку, здесь используется ее номер, который имеет тип перечисления (enum). Это дает возможность более строго выпол нить проверку типов, изменить соответствие между номером строки и самой строкой в будущем, а также уменьшить количество ошибок и опечаток. Перечисления опре делены в файле и имеют имена в формате KOBJ_foo.

На момент написания книги были определены следующие события: KOBJ_MOUNT, KOBJ_UNMOUNT, KOBJ_ADD, KOBJ_REMOVE и КОВJ_CHANGE. Эти значения отобража ются на строки "mount" (монтирование), "unmount" (размонтироваыие), "add" (до бавление), "remove" (удаление) и "change" (изменение) соответственно. Допускается добавление новых значений событий, если существующих значений недостаточно.

Последний параметр — опциональный указатель на структуру at t r i but e. Этот параметр можно трактовать как дополнительную информацию (payload) о событии.

Если только одного значения события недостаточно, то событие может предоста вить информацию о том, в каком файле файловой системы sysfs содержатся допол нительные данные.

Более подробную информацию о демоне D-BUS можно найти на сайте ht t p: //dbus. f reedeskt op. org/.

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

int kobject_uevent_atomic (struct kobject *kobj, enum kobject_action action, struct attribute *attr)

;

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

Использование объектов kobject и их атрибутов не только дают возможность опи сать события в терминах файловой системы sysfs, но и стимулируют создание новых объектов и их атрибутов, которые еще не представлены через файловую систему sysfs.

Обе рассмотренные функции определены в файле lib/kobject_uevent.с и объявлены в файле .

Кратко об объектах kobj ect и файловой системе sysfs В этой главе рассматривается модель представления устройств, файловая си стема sysfs, объекты kobject и уровень событий ядра. Описание материала главы было бы невозможно без рассмотрения родственных вещей: были также описаны множества kset, подсистемы, атрибуты, типы ktype и счетчики ссылок kref. Эти структуры предназначены для использования разными людьми в разных местах.

Разработчикам драйверов необходимо только ознакомление с внешними интерфей сами. Большинство подсистем драйверов эффективно скрывают внутренние механиз мы использования объектов kobject и других, близких к ним структур. Понимание основных принципов работы и знание основного назначения интерфейсов, таких как sysfs_create_file(), является достаточным для разработчиков драйверов.

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

Эта глава — последняя из тех, которые посвящены подсистемам ядра. В следую щих главах будут рассмотрены некоторые общие вопросы, которые также могут ока заться важными для разработчиков ядра. Например, основные рекомендации по от ладке кода!

Объекты kobject и файловая система sysfs Отладка дин из самых существенных факторов, который отличает разработку ядра от разработки пользовательских приложений, — это сложность отладки.

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

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

С чего необходимо начать Итак, готовы ли вы начать охоту за ошибками? Этот путь может оказаться длин ным и полным разочарований. Некоторые ошибки ставили в тупик все сообщество разработчиков ядра на несколько месяцев. К счастью, на каждую из таких злостных ошибок находятся простые, которые легко исправить. Если вам повезет, то все про блемы, с которыми вы столкнетесь, будут простыми и тривиальными. Однако чтобы это проверить, необходимо начать исследования. Для этого понадобится следую щее.

• Сама проблема. Может звучать глупо, но дефект должен быть конкретным и хорошо определенным. Очень помогает, если его хотя бы кто-нибудь может устойчиво воспроизвести. Однако, к сожалению, дефекты обычно ведут себя не так хорошо, как хотелось бы, и не всегда могут быть хорошо определены.

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

• Немного удачи, опыта и их комбинации.

Если дефект нельзя воспроизвести, то многие из приведенных ниже подходов становятся бесполезными. Очень важно, чтобы проблему можно было повторить.

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

Может также показаться странным, что существуют дефекты, которые кто-то не может воспроизвести. Дело в том, что в пользовательских программах дефекты чаще всего проявляются очень просто, например вызов функции foo приводит к соз данию файла core. В ядре все совсем по-друтому. Взаимодействия между ядром, про странством пользователя и аппаратурой могут быть достаточно тонкими. Состояния конкуренции за ресурсы могут возникать с вероятностью одно на миллион итераций алгоритма. Плохо спроектированный или даже не правильно скомпилированный код может обеспечивать удовлетворительную производительность на одной систе ме, но неудовлетворительную на другой, Очень часто происходит так, что на ка кой-то случайной машине, при очень специфическом характере загрузке, начинают проявляться дефекты, которые больше нигде не проявляются. Чем больше доступ но дополнительной информации при локализации дефекта, тем лучше. Во многих случаях, как только удалось устойчиво воспроизвести проблему, можно считать, что большая половина работы сделана.

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

;

от плохой производительности до неправильного функционирования и даже до потери данных.

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

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

Для этого также вероятно потребуется применение блокировок.

374 Глава Отладка ядра может показаться сложным делом, тем не менее, ядро не особо от личается от других больших программных проектов. У ядра есть свои уникальные особенности, такие как ограничения связанные со временем выполнения участков кода, возможности возникновения состояний конкуренции (race) — как результат параллельного выполнения множества потоков в ядре. Можно дать стопроцентную гарантию, что если приложить некоторые усилия и понимание, то проблемы ядра можно с успехом находить и решать (и даже, возможно, получать удовольствие от успешного преодоления трудностей).

Функция printk() Функция форматированного вывода сообщений pri nt k() работает аналогично библиотечной функции pri nt f () языка С. Действительно в этой книге до этого мо мента мы не видели никаких существенных отличий в ее использовании. Для боль шинства задач это именно так: функция pri nt k() — это просто функция ядра, вы полняющая форматированный вывод сообщений. Однако, некоторые различия все же имеются.

Устойчивость функции pr i nt k( ) Одно из проверенных и часто используемых свойств функции pr i nt k() — это ее устойчивость. Функцию pr i nt k () можно вызывать практически в любое время и в любом месте ядра. Её можно вызывать из контекста прерывания и из контекста процесса. Её можно вызывать во время удержания блокировки. Её можно вызывать одновременно на нескольких процессорах и она не требует при этом удерживать ка кие-нибудь блокировки.

Эта функция очень устойчива, и это очень важно, потому что полезность функ ции pri nt k () базируется на том факте, что она всегда доступна и всегда работает.

Неустойчивость функции pri ntk() Слабое место у функции pr i nt k() в плане устойчивости все же существует. Её нельзя использовать до некоторого момента при загрузки ядра, пока консоль еще не инициализирована. Действительно, если нет консоли, то куда будут выводится со общения?

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

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

Отладка Одно из решений проблемы — вариант функции pr i nt k( ), который может выводить информацию па консоль на очень ранних стадиях процесса загрузки ear l y_pr i nt k( ). Поведение этой функции аналогично функции pr i nt k( ), за исключением имени и возможности работать на очень ранних стадиях загрузки.

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

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

Уровни вывода сообщений ядра Главное отличие между функциями pri nt k() и pr i nt f ( ) — это возможность в первой указывать уровень вывода сообщений ядра (loglevel). Ядро использует уровень вы вода сообщений для принятия решения о том, выводить сообщение на консоль или нет. Ядро выводит на консоль все сообщение с уровнями меньшими, или равными, соответствующему значению для консоли (console logleyel). Уровень вывода сообще ний можно указывать следующим образом.

printk(KERN_WARNTNG "Это предупреждение!\n")

;

printk(KERN_DEBUG "Это отладочное сообщение!\n")

;

printk("Мы не указали значения loqlevel!\n" )

;

Строки KERN_WARNING и KERN_DEBUG определены через препроцессор в заголо вочном файле . Эти макросы раскрываются в строки, соответ стпенно "<4>" и "<7>", которые объединяются со строкой формата в самом начале сообщения, выводимого функцией pri ntk(). После этого на основании уровня выпо да сообщения и уровня вывода консоли (значение переменной console_loglevel) ядро принимает решение выводить информацию на консоль или нет. В табл. 18. приведен полный список возможных значений уровня вывода сообщений.

Таблица 18.1. Доступные значения уровня вывода сообщений ядра (loglevel) Значение loglevel Описание KERN_EMERG Аварийная ситуация KERN_ALERT Проблема, на которую требуется немедленно обратить внимание KERN_CRIT Критическая ситуация KERN_ERR Ошибка KERN_WARNING Предупреждение KERN_NOTICE Обычная ситуация, но на которую следует обратить внимание KERN_INFO Информационное сообщение KERN_DEBUG Отладочное сообщение — обычно избыточная информация Если уровень вывода сообщений ядра не указан, то его значение по умолча нию равно DEFAULT_MESSAGE_LOGLEVEL, который в данный момент равен KERN_ WARNING. Так как это значение может измениться, то для своих сообщений необхо димо всегда указывать уровень вывода.

376 Глава Наиболее важный уровень вывода— KERN_EMERG определен как "<0>", а наиме нее важный — KERN_DEBUG, как "<7>". Например, после обработки препроцессором кода из предыдущего примера получается следующее.

printk("<4>Этo предупреждение!\n")

;

printk("<7>Это отладочное сообщение!\n")

;

printk("<4>Мы не указали значения loglevel!\n")

;

Как вы будете использовать функцию pri ntk() зависит только от вас. Конечно, обычные сообщения, которые должны быть видимы, должны иметь соответству ющий уровень вывода. Отладочные сообщения, которые в большом количестве встраиваются в самые разные места кода с целью разобраться с проблемой — "до пустим ошибка здесь", "пробуем", "работает" - могут иметь любой уровень вывода.

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

Уровни вывода сообщений определены в файле .

Буфер сообщений ядра Сообщения ядра хранятся в кольцевом буфере (log buffer) размером LOG_BUF_LEN.

Этот размер можно изменять во время компиляции с помощью параметра CONFIG_ LOG_BUF_SHIFT. Для однопроцессорной машины это значение по умолчанию равно 16 Кбайт. Другими словами в ядре может хранится до 16 Кбайт системных сообще ний. Если общий размер всех сообщений ядра достигает этого максимального зна чения и приходит новое сообщение, то оно переписывается поверх самого старого из хранящихся в буфере сообщений. Буфер сообщений ядра называется кольцевым, потому что запись и считывание сообщений выполняется по круговой схеме.

Использование кольцевого буфера предоставляет определенные преимущества.

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

Демоны syslogd и klogd В стандартной системе Linux для извлечения сообщений ядра из буфера исполь зуется специальный демон пространства пользователя klogd, который направляет эти сообщения в файл журнала системных сообщений. Для чтения системных со общений программа klogd может считывать данные из файла /proc/kmsg, или использовать системный вызов sysl og(). По умолчанию используется подход на Отладка основе файловой системы /рrоc. Если сообщений нет, то демон klogd блокируется на операции чтения, пока не поступит новое сообщение. Когда приходит новое со общение, демон возвращается к выполнению, считывает сообщения и обрабатывает их. По умолчанию сообщения отправляются демону syslogd.

Демон syslogd добавляет полученные сообщения в конец файла журнала, по умолчанию — /var/log/messages. Имя соответствующего файла можно настроить в конфигурационном файле /etc/syslog.conf.

Изменить уровень вывода сообщений на консоль (console loglevel) можно при старте демона klogd с помощью флага -с.

Замечание относительно функции pri nt k( ) и разработки ядра Когда впервые начинают разрабатывать код ядра, то скорее всего очень часто приходится заменять функцию pri nt f () на функцию pri nt k(). Это нормально, по тому что нельзя не принимать во внимание многолетний опыт по написанию поль зовательских программ и использовании функции pr i nt f (). Следует надеяться, что повторение таких ошибок не будет продолжаться долго, потому что повторяющиеся ошибки компоновщика начнут быстро надоедать.

Однажды вдруг окажется, что вы поймали себя на том, что начали использовать функцию pr i nt k( ) вместо функции pr i nt f ( ) в пользовательских программах.

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

Сообщения Oops Сообщения oops — обычный для ядра способ сообщить пользователю, что произо шло что-то нехорошее. Так как ядро управляет всей системой, то оно не может само себя исправить, или завершить, как это возможно для программ пространства поль зователя, когда они делают что-то не так. Вместо этого, ядро выводит сообщение oops. Такое сообщение включает вывод информации об ошибке на консоль, вывод дампа содержимого всех регистров и вывод обратной трассировки вызовов функций (back trace). Сбои в работе ядра трудно обработать, поэтому ядро должно "пролезть'' через многие дыры, чтобы вывести сообщение oops и выполнить за собой все не обходимые действия по очистке. Часто после выдачи сообщения oops ядро нахо дится в несогласованном состоянии. Например, в момент возникновения ситуации, в которой выдается сообщение oops, ядро может находится в процессе обработки важных данных. В этот момент может удерживаться блокировка, или выполняться сеанс взаимодействия с оборудованием. Ядро должно аккуратно отойти от текуще го состояния и попытаться восстановить контроль над системой. Во многих случаях это невозможно. Если ситуация, в которой выдается сообщение oops, возникает в контексте прерывания, то ядро не может продолжать работу и переходит в состо яние паники. Состояние паники проявляется в полной остановке системы. Если oops возникает в холостой задаче (idle task, идентификатор pid равен нулю), или при выполнении процесса i ni t (идентификатор pid равен единице), то ядро также переходит в состояние паники, потому что ядро не может продолжать выполнение 378 Глава без этих важных процессов. Однако, если oops возникает при выполнении любого другого процесса, то ядро завершает этот процесс и продолжает работу.

Сообщение oops может выдаваться по многим причинам, включая недопустимый доступ к памяти (memory access violation) и выполнение недопустимой машинной команды. Как разработчику ядра, вам придется иметь дело с сообщениями oops и далее, несомненно, быть причиной их появления.

Ниже показано сообщение oops для машины аппаратной платформы РРС, кото рое возникло и обработчике таймера для сетевого интерфейсного адаптера tulip.

Oops: Exception in kernel mode, sig: Unable to handle kernel NULL pointer dereference at virtual address NIP: C013A7F0 LR: C013A7F0 SP: C0685E00 REGS: c0905dl0 TRAP: Not tainted MSR: 00089037 ЕЕ: 1 PR: 0 FP: 0 ME: 1 IR/DR: TASK = c0712530[0] swapper Last syscall: GPROO: C013A7C0 C0295E00 C0231530 0000002F 00000001 C0380CB8 C0291B80 C02D GPR08: 000012AO 00000000 00000000 C0292AA0 4020A088 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000005 00000000 00001032 C3F7C000 00000032 FFFFFFFF C3F7C1C Call trace:

[c013ab30] tulip_timer+0xl28/0xlc [c0020744] run_timer_softirq+0xl0c/0xl [c001b864] do_softirq+0x88/0xl [c0007e80] timer_mterrupt+0x284/0x [c00033c4] ret_from_except+0x0/0x [c0007b84] default_idle+0x20/0x [c0007bf8] cpu_idle+0x34/0x [c0003ae8] rest_init+0x24/0x У пользователей ПК может вызвать удивление количество регистров процессора (32 - огромное число!). Сообщение oops для аппаратной платформы х86, которые возможно вам более знакомы, имеют несколько более простой вид. Тем не менее, важная информация идентична для всех аппаратных платформ: содержимое всех ре гистров и обратная трассировка.

Обратная трассировка показывает точную последовательность вызовов функ ций, которая привела к проблеме. В данном случае можно точно определить, что случилось: машина выполняла холостое задание - холостой цикл: вызов функ ции cpu_i dl e(), из которой циклически вызывается функция def aul t _i dl e( ).

Поступило прерывание от системного таймера, в котором вызываются обра ботчики таймеров ядра. Среди них вызывается обработчик таймера — функция tul i p_ti mer(), в которой выполнено разыменование указателя со значением NULL.

Можно даже воспользоваться значением смещения (числа вроде 0х128/0х1с4, кото рые указаны справа от имени функции) для точного нахождения команды, в кото рой возникла ошибка.

Содержимое регистров точно также полезно, хотя и используется не так часто.

Вместе с дизассемблированным кодом функции содержимое регистров может по мочь восстановить точную последовательность событий, которая привела к пробле ме. Если значение в некотором регистре не соответствует ожидаемому, то это может пролить некоторый свет на корень проблемы. В данном случае можно проверить, какие регистры содержат значение NULL (все разряды нулевые) и определить, какая Отладка из переменных функции содержит не то значение. В ситуациях, похожих на данную, скорее всего причина — конкуренция за ресурс (race) и скорее всего между тайме ром и другой частью сетевого адаптера. Отладка состояний конкуренции за ресур сы — всегда серьезная задача.

Утилита ksymoops Только что рассмотренное сообщение oops имеет так называемый декодированный вид, потому что адреса памяти транслированы в имена функций, которые им соот ветствуют. Не декодированный вид предыдущего сообщения выглядит следующим образом.

NIP: C013A7F0 LR: C013A7F0 SP: C0685E00 REGS: c0905dl0 TRAP: Not tainted MSR: 00089037 ЕЕ: 1 PR: 0 FP: 0 ME 1 IR/DR: TASK = c0712530[0] 'swapper' Last syscall: GPROO: C013A7CO C0295E00 C0231530 0000002F 00000001 C0380CB8 C0291B80 C02D GPR08: 000012AO 00000000 00000000 C0292AA0 4020A088 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000005 00000000 00001032 C3F7C000 00000032 FFFFFFFF C3F7C1C Call trace: [c013ab30] [c0020744] [c001b864] [c0007e80] [c00061c4] [c0007b84] [c0007bf8] [c0003ae8] Адреса обратной трассировки должны быть переведены в символические име на функций. Это можно сделать с помощью команды ksymoops при наличии файла System.map, который сгенерирован во время компиляции данного ядра. Если ис пользуются загружаемые модули ядра, то необходима также информация о модулях.

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

ksymoops saved_oops.txt Программа выводит декодированную информацию сообщения oops. Если инфор мация, которая используется по умолчанию, недоступна, или есть необходимость указать альтернативное положение соответствующих информационных файлов, то на такой случай программа принимает различные параметры. Страницы руковод ства по данной программе, которые необходимо прочитать перед использованием, содержат всю необходимую информацию.

Программа ksymoops включена в большинство поставок операционной системы Linux.

Функция kallsyms К счастью, больше нет необходимости использовать программу ksymoops. Это очень полезно, потому что, хотя, у разработчиков обычно нет проблем с ее исполь зованием, пользователи часто указывают неправильный файл System.map, или не правильно декодируют сообщение oops.

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

Эта функция включает в исполняемый образ ядра информацию для отображения адресов памяти в соответствующие имена функций ядра, что дает возможность ядру 380 Глава самостоятельно декодировать информацию обратной трассировки. Следовательно, декодирование сообщений oops больше не требует файла System.map, или утилиты kallsyms. Как недостаток такого подхода следует отметить некоторое увеличение объема памяти, используемой ядром, так как таблица перевода адресов памяти в имена функций загружается в постоянно отображаемую память ядра. На такое уве личение объемов используемой памяти стоит пойти, по крайней мере, на этапе раз работки ядра.

Конфигурационные параметры отладки ядра Существует несколько конфигурационных параметров, которые помогают в от ладке и тестировании кода ядра и которые включаются во премя компиляции. Эти параметры доступны в пункте Kernel hacking меню редактора конфигурации ядра.

Все эти параметры зависят от параметра CONFIG_DEBUG_KERNEL. Для разработки кода ядра следует включать только те параметры, которые необходимы.

Некоторые из этих параметров достаточно полезны, такие как отладка работы со слябовым распределителем памяти (slab layer debugging), отладка работы с верхней памятью (high memory debugging), отладка работы с отображаемым на память вво дом-выводом (I/O mapping debugging), отладка работы со спин-блокировками (spin lock debugging) и проверка переполнения стека (stack overflow checking). Однако, один из самых полезных параметров — это проверка перехода в состояние ожидания при захваченной спин-блокировке (sleep-inside-spinlock checking), которая на самом деле выполня ет значительно больше работы.

Отладка атомарных операций Начиная с серии 2.5 в ядре появилась отличная инфраструктура для определе ния всех типов нарушения атомарности. Вспомните из главы 8, "Введение в синхро низацию выполнения кода ядра", что атомарность означает неделимое выполнение, то есть код выполняется без перерыва до завершения, или не завершается вообще.

Код, который удерживает спин-блокировку, или выполняется при запрещенной пре емптивности ядра, является атомарным. Во время атомарного выполнения нельзя переходить в состояние ожидания. Ожидание при удерживаемой спин-блокировке — один из вариантов взаимоблокировки.

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

Следующие конфигурационные параметры позволяют полностью использовать данную возможность.

Отладка CONFIG_PREEMPT=y CONFIG_DEBUG_KERNEL=y CONFIG_KALLSYMS=y CONFIG_SPINLOCK_SLEEP=y Генерация ошибок и выдача информации Существует несколько подпрограмм ядра, которые позволяют легко сигнали зировать о наличии дефектов кода, обеспечивать объявления об ошибках и выво дить необходимую информацию. Две наиболее часто используемые — это BUG() и BUG_ON(). При вызове эти функции создают ситуацию oops, которая проявляется в выводе обратной трассировки стека ядра и сообщения об ошибке. Каким обра зом эти вызовы генерируют ситуацию oops зависит от аппаратной платформы. Для большинства аппаратных платформ вызовы BUG() и BUG_ON() определяются как некоторая недопустимая машинная команда, которая приводит к выводу желаемого сообщения oops.

Обычно эти вызовы используются в качестве объявления о наличие ошибки (assertion), чтобы сигнализировать о ситуации, которая не должна произойти.

if (bad_thing) BUG()

;

Или даже так.

BUG_ON(bad_thing)

;

О более критичной ошибке можно сигнализировать с помощью функции panic ().

Функция panic () печатает сообщение об ошибке и останавливает ядро. Ясно, что эту функцию следует использовать только в самой плохой ситуации.

if (terrible_thing) panic("foo is %ld!\n", foo)

;

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

if (!debug_check) { printk(KERN_DEBUG "выдать некоторую информацию...\n")

;

dump_stack()

;

} Магическая клавиша SysRq Использование магической клавиши SysRq, которую можно активизировать с по мощью конфигурационного параметра CONFIG_MAGIC_SYSRQ на этапе компиляции, часто позволяет значительно облегчить жизнь. Клавиша SysRq является стандарт ной на многих клавиатурах. Для аппаратных платформ i386 и РРС ей соответствует комбинация клавиш ALT-PrintScreen. Если указанный конфигурационный пара метр активизирован, то специальные комбинации клавиш позволяют взаимодейство 382 Глава вать с ядром независимо от того, чем ядро в данный момент нанимается. Это в свою очередь позволяет выполнять некоторые полезные операции даже на неработоспо собной системе.

В дополнение к конфигурационному параметру существует вызов sysct l для включения и выключения этого свойства.

echo 1 > /proc/sys/kernel/sysrq Список возможных комбинаций клавиш можно получить с консоли путем на жатия комбинации клавиш SysRq-h. Комбинация клавиш SysRq-s выполняет синхронизацию не сохраненных буферов файловых систем на диск, комбинация SysRq-u размонтирует все файлопые системы, a SysRq-b — перегружает машину.

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

Если машина заблокирована очень сильно, то она может не отвечать на магиче ские комбинации клавиш SysRq, или соответствующая операция не будет выполне на. Если же повезет, то эти комбинации клавиш смогут помочь при отладке, а также сохранить данные. В табл. 18.2 приведен список поддерживаемых команд SysRq.

Таблица 18.2. Список поддерживаемых команд SysRq Команда Описание SysRq-b Перегрузить машину (reboot) SysRq-e Послать сигнал SIGTERM всем процессам, кроме процесса i ni t SysRq-h Отобразить на консоли помощь по использованию комбинаций клавиш SysRq SysRq-i Послать сигнал SIGKILL всем процессам, кроме процесса i ni t SysRq-k Клавиша безопасного доступа: завершить все процессы, связанные с текущей консолью i SysRq-l Послать сигнал SI GKI LL всем процессам, включая процесс i ni t SysRq-m Отобразить на консоли дамп информации по использованию памяти SysRq-o Завершить работу машины (shutdown) SysRq-p Отобразить на консоли дамп регистров памяти SysRq-r Отключить прямой режим работы клавиатуры (raw mode) SysRq-s Синхронизировать данные смонтированных файловых систем с дисковыми устройствами SysRq-t Отобразить на консоли дамп информации о заданиях SysRq-u Размонтировать все смонтированные файловые системы В файле Documentation/sysrq.txt, который находится в каталоге исходных кодов ядра, приводится более полное описание. Реализация поддержки магической комбинации клавиш находится в файле drivers/char/sysrq.с. Магические ком бинации клавиш SysRq — жизненно необходимый инструмент, который помогает в отладке и сохранении "гибнущей" системы, так как предоставляет большие возмож ности для любого пользователя при работе с консолью. Тем не менее необходимо соблюдать осторожность при его использовании на критичных машинах. Если же машина используется для разработок, то польза от этих команд огромная.

Отладка Сага об отладчике ядра Многие разработчики ядра давно высказываются о необходимости встроенного в ядро отладчика. К сожалению, Линус не желает видеть отладчик ядра в своем де реве исходного кода, Он уверен, что использование программ-отладчиков приводит к плохому исправлению ошибок неправильно информированными разработчиками.

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

Перед тем, как обращаться к этим решениям, посмотрим, на сколько нам может по мочь стандартный отладчик ОС Linux - gdb.

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

gdb vmlinux /proc/kcore Файл vmlinux — это декомпрессированный исполняемый образ ядра, который хранится в корне каталога исходных кодов, где выполнялась сборка выполняющего ся ядра. Сжатые файлы zlmage, или bzlmage использовать нельзя.

Опциональный параметр /proc/kcore исполняет роль файла core, чтобы позво лить отладчику читать из памяти выполняющегося ядра. Чтобы иметь возможность читать этот файл, необходимо иметь права пользователя root.

Можно пользоваться практически всеми командами программы gdb для чтения информации. Например, чтобы напечатать значение переменной можно восполбзо ваться командой.

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

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

К сожалению, на этом заканчиваются возможности использования отладчика gdb.

С его помощью никак нельзя изменять данные ядра. Нет возможности пошагово вы полнять код ядра, или устанавливать точки остановки (breakpoint). Невозможность изменять структуры данных ядра — это большой недостаток. Хотя очень полезно 384 Глава иметь возможность дизассемблировать код функций, еще более полезной была бы возможность изменять структуры данных.

Отладчик kgdb Отладчик kgdb —это заплата ядра, которая позволяет с помощью отладчика gdb отлаживать ядро по линии последовательной передачи. Для этого требуется два ком пьютера. На перпом выполняется ядро с заплатой kgdb. Второй компьютер использу ется для отладки ядра по линии последовательной передачи (нуль-модемный кабель, соединяющий две машины) с помощью gdb. Благодаря отладчику kgdb полностью доступен весь набор функций gdb: чтение и запись любых переменных, установка точек остановки, установка точек слежения (watch points), пошаговое исполнение и др.. Специальные версии kgdb даже позволяют вызывать функции.

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

Несколько человек выполняют поддержку заплаты kgdb для различных аппарат ных платформ и версий ядра. Поиск в Интернет — наилучший способ найти необхо димую заплату для заданного ядра.

Отладчик kdb Альтернативой kgdb является отладчик kdb. В отличие от kgdb отладчик kdb — не удаленный отладчик. Отладчик kdb — это заплата, которая сильно модифициру ет ядро и позволяет выполнять отладку прямо на той же машине, где выполняется ядро. Кроме всего прочего поддерживается возможность изменения переменных, установки точек остановки и пошаговое выполнение. Выполнять отладку просто — необходимо нажать на консоли клавишу break. При выводе сообщения oops пере ход в отладчик выполняется автоматически. Более подробная документация доступ на в каталоге Documentation/kdb после применения заплаты. Заплата kdb доступна в Интернет по адресу http: //oss. sgi. com/.

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

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

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

Часто безопасным будет сохранить старый алгоритм, а новую реализацию выпол нить в другом месте. Этого можно достичь используя идентификатор пользователя (UID) в качестве условия того, какой алгоритм использовать.

if (current->uid != 7777) { /* старый алгоритм.. */ } else { /* новый алгоритм.. */ } lice пользователи, кроме того, у которого идентификатор UID равен 7777 будут использовать старый алгоритм. Для тестирования нового алгоритма можно создать нового пользователя с идентификатором 7777. Это позволяет более просто оттести ровать критические участки кода, связанные с выполнением процессов.

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

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

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

Например, допустим, что необходимо выяснить на сколько часто происходит со бытие foo и событие bar. В файле исходного кода, в идеале там, где соответствующие события возникают, вводится две глобальные переменные.

unsigned long foo_stat = 0

;

unsigned long bar_stat = 0

;

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

Следует обратить внимание, что такой подход принципиально не безопасен на SMP машине. В идеале необходимо использовать атомарные переменные. Однако, 386 Глава для временной статистики, которая необходима только для отладки, никакой защи ты обычно не требуется.

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

Для предотвращения такой проблемы существует два сравнительно простых при ема. Первый — ограничение частоты следования событий — очень полезен, когда не обходимо наблюдать, как развивается событие, но частота возникновения события очень большая. Чтобы ограничить поток отладочных сообщений, эти сообщения вы водятся только раз в несколько секунд, как это показано в следующем примере.

static unsigned long prev_jiffy = jiffies

;

/* ограничение частоты */ if (time_after (jiffies, prev_jiffy + 2*HZ)) { prev_jiffy = jiffies

;

printk (KERN_ERR "blah blah blah\n")

;

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

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

static unsigned long limit = 0

;

if (limit < 5) { limit++

;

printk(KERN_ERR "blah blah blah\n")

;

}., В этом примере количество отладочных сообщений ограничено числом пять.

После пяти сообщений условие всегда будет ложно.

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

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

Отладка Нахождение исполняемых образов с изменениями приводящими к ошибкам Обычно полезно знать, в какой версии исходных кодов ядра появился дефект.

Если известно, что дефект появился в версии 2.4.18, но его не было в версии 2.4.17, то сразу появляется ясная картина изменений, которые привели к появлению ошиб ки. Исправление ошибки сводится к обратным изменениям, или другим исправлени ям измененного кода.

Однако, чаще оказывается неизвестным в какой версии появился дефект.

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

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

Далее, необходимо ядро, в котором гарантированно есть дефект. Для облегче ния поиска следует воспользоваться наиболее ранней версией ядра, в которой есть дефект. После этого начинается поиск исполняемого образа, в котором появилась ошибка. Рассмотрим пример. Допустим, что последнее ядро, в котором не было ошибки— 2.4.11, а последнее с ошибкой— 2.4.20. Начинаем с версии ядра, которая находится посредине— 2.4.15. Проверяем версию 2.4.15 на наличие ошибки. Если версия 2.4.15 работает, значит ошибка появилась в более поздней версии. Следует попробовать версию между 2.4.15 и 2.4.20, скажем версию 2.4.17. С другой стороны, если версия 2.4.15 не работает, то тогда ясно, что ошибка появилась в более ранней версии, и следует попробовать версию, скажем 2-4.13. И так далее.

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

Такой подход избавляет от необходимости проверять ядра всех версий!

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

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

Глава 20, "Заплаты, разработка и сообщество" специально посвящена сообществу разработчиков ядра и его основному форуму — списку рассылки разработчиков ядра Linux (Linux Kernel Mail List, LKML).

388 Глава Переносимость inux — переносимая операционная система, которая поддерживает большое ко личество различных компьютерных аппаратных платформ. Переносимость— это L свойство, которое указывает, насколько легко можно перенести код, который вы полнялся на одной аппаратной платформе, для выполнения на другой аппаратной платформе (если вообще это возможно). Известно, что ОС Linux является переноси мой операционной системой, поскольку ее уже перенесли (портировали) па большое количество различных аппаратных платформ. Тем не менее переносимость не воз никает сама по себе, для выполнения она требует большого количества проектных решений. Сегодня процесс перенесения ОС Linux на другую аппаратную платформу достаточно прост (в относительном смысле, конечно). В этой главе рассказывается о том, как писать переносимый код, — вопрос, о котором всегда необходимо помнить при написании нового кода ядра или драйверов устройств.

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

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

Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.