Linux kernel 2.6: первые шаги к sysfs

Активные разработки в направлении совершенствования ядра Linux привели к появлению большого количества нововведений, полезных и удобных не только пользователю, но и многочисленной армии программистов. Одним из таких нововведений является Unified Device Model Of Kernel (далее UDM). Речь идет о некоей обобщенной модели взаимодействия устройств и драйверов в ядре линукс, абстрактном механизме взаимодействия между ядром, устройствами, драйверами и пользовательским уровнем. Использование этой модели тесно связано с новой файловой системой - sysfs, которая также появилась в новом ядре с целью частично вытеснить файловую систему /proc.

В этой статье я хотел рассказать о своих первых впечатлениях от работы с UDM & Sysfs. Суть UDM состоит в том, что в ядре объявляется несколько объектов (device, device_driver, bus_type, etc..) и набор функций для работы с ними. С их помощью разработчик модулей ядра (драйверов устройств) может построить взаимосвязанную, масштабируемую систему. Среди преимуществ UDM можно выделить следующие:

• поддержка горячего подключения устройств
• отображение взаимосвязей "устройств" и "драйверов" в sysfs
• отслеживание жизненного цикла объектов модели

Каждый объект в UDM представляет собой структуру (struct). Взаимосвязь объектов происходит через связные списки. Но от программиста это тщательно скрывается (до разумных пределов, ведь все ядро есть в исходном коде), то есть напрямую работать с объектами UDM как с элементами связного списка не приходится. Каждый объект UDM, попадающий в список, отображается в виртуальной файловой системе sysfs. И это - как оказалось - действительно удобно. Поскольку алгоритмы создания файлов и директорий в sysfs неразрывно следуют за созданием древовидной структуры и также хорошо скрыты от программиста. Я хорошо это ощутил, так как раньше разрабатывал модули под linux 2.4 и использовал procfs для взаимодействия пользователького уровня с уровнем ядра. Так вот в linux 2.4 все приходилось делать самому - создание файлов и директорий было специальной задачей.

Основные объекты UDM:

1. device - устройство
2. device_driver - драйвер устройства
3. bus_type - шина взаимодействия устройства и драйвера
4. device_attribute, driver_attribute, bus_attribute - соответствующие атрибуты

Рассмотрим их подробнее.

bus_type. Хранит в себе список всех устройств и драйверов, "подключенных" к ней. Основная задача - определять, какому драйверу соответствует подключаемое к системе устройство (callback match). При регистрации шины в linux директория с ее названием автоматически появляется в sysfs : /sys/bus/my_bus

device_driver. Некая абстракция драйвера устройства. Драйвер регистрируется в шине. Освновная задача - выполнить необходимые действия при подключении устройства (probe) и его отключении (remove). После подключения к шине создаются директории /sys/bus/drivers/my_driver, /sys/drivers/my_driver.

device. Структура, характеризующая подключаемое устройство. После подключения создаются директории /sys/bus/devices/my_device, /sys/devices/my_device

device_attribute, driver_attribute, bus_attribute. Это структуры, содержащие callback'и read & write. Каждый атрибут представляет собой файл в sysfs. В зависимости от типа атрибута (bus_, device_, driver_), файл будет находиться либо в каталоге для устройства, либо в каталоге для драйвера, либо - для шины. Основное назначение атрибутов - обеспечение взаимодействия ядра и пользовательского уровня. С помощью них пользователь или пользовательская программа может настраивать параметры устройства, драйвера, и т.п.

Алгоритмически взаимодействие вышеописанных объектов (структур) выглядит так:

1. Во время загрузки модуля ядра происходит заполнение структуры bus_type и регистрация ее в системе (bus_register). Результат: в директории /sys/bus/ появится новый каталог с названием bus_type->name. В этом каталоге автоматически появятся директории drivers/, devices/.
2. Далее, в этом или уже в другом модуле, заполняется структура device_driver. У этой структуры необходимо заполнить поле bus - только тогда в каталоге my_bus/drivers/ появится новый драйвер. Она регистрируется функцией driver_register. Зарегистрировано может быть несколько драйверов. Результат: в каталоге /sys/bus/my_bus/drivers появляется каталог с именем драйвера (driver->name)
3. Некий модуль определяет, что устройство подключено к системе (по прерываниям или методом опроса). Он создает и заполняет структуру device и регистрирует устройство в системе - device_register. Что происходит при регистрации устройства: 1) для каждого драйвера из связного списка bus вызывается функция match, которой передаются указатели на драйвер и новое устройство, до тех пор пока не будет найден соответствующий драйвер 2) у найденного драйвера вызывается функция probe, которой передается указатель на подключенный device. Далее драйвер инициализирует подключенное устройство по своему усмотрению. Данные, специфичные для данного устройства, можно хранить по указателю device->driver_data. Результат: в sysfs появляется директория с названием устройства: /sys/bus/my_bus/devices/my_device

После регистрации любого объекта можно создать для него атрибут (файл в sysfs). Для этого используются функции (device_/bus_/driver_)create_file и (device_/bus_/driver_)_remove_file. Структура атрибута содержит два callback'а - store и show. Store вызывается, когда в файл (например /sys/bus/my_bus/devices/my_device/some_attr ) записывается информация пользователем. Show - когда считывается.

Процедура отключения устройства имеет обратный порядок. Сначала вызывается device_unregister(). После этого ядро автоматически вызывает driver->remove(device) и из sysfs удаляется соответствующий каталог.

Ко всему сказано необходимо добавить, что:

• вышеописанные действия не только создают систему директорий и файлов в sysfs, но и устанавливают взаимосвязь между драйверами, устройствами. Например структура device хранит в себе указатель на driver, который соответствует данному устройству.
• при помощи итераторов можно "пробежаться" по всем драйверам и устройствам, подключенным к какой-либо шине.
• при помощи итераторов можно "пробежаться" по всем устройствам, подключенным к какому-либо драйверу.

То, как все вышеописанное происходит в ядре, можно прочитать в исходных текстах ядра:

• drivers/base/core.c
• drivers/base/bus.c
• include/linux/device.h
• include/linux/kobject.h

Ссылки по теме: http://www-128.ibm.com/developerworks/linux/library/l-inside.html

-- PavelKurochkin - 03 Mar 2006