Унифицированная модель представления устройств — это существенно новая особенность, которая появилась в ядрах серии 2.6. Модель устройств — это единый механизм для представления устройств и описания их топологии в системе. Использование единого представления устройств позволяет получить следующие преимущества.
• Уменьшается дублирование кода.
• Используется механизм для выполнения общих, часто встречающихся функций, таких как счетчики использования.
• Появляется возможность систематизации всех устройств в системе, возможность просмотра состояний устройств и определения, к какой шине то или другое устройство подключено.
• Появляется возможность генерации полной и корректной информации о древовидной структуре всех устройств в системе, включая все шины и соединения.
• Обеспечивается возможность связывания устройств с их драйверами и наоборот.
• Появляется возможность разделения устройств на категории в соответствии с различными классификациями, таких как устройства ввода, без знания физической топологии устройств.
• Обеспечивается возможность просмотра иерархии устройств от листьев к корню и выключения питания устройств в правильном порядке.
Последний пункт был самой первой мотивацией необходимости создания общей модели представления устройств. Для того чтобы реализовать интеллектуальное управление электропитанием в ядре, необходимо построить дерево, которое представляет топологию устройств в системе. Для выключения питания устройств, которые организованы в виде древовидной топологии, ориентированной сверху вниз, ядро должно выключить питание нижних узлов (листьев) перед выключением питания верхних узлов. Например, ядро должно выключить питание USB-мыши перед тем, как выключать питание контроллера шины USB, а питание контроллера шины USB должно быть выключено перед выключением питания шины PCI. Чтобы делать это эффективно и правильно для всей системы, ядру необходимо отслеживать топологию дерева всех устройств в системе.
Объекты
kobject
Сердцем модели представления устройств являются объекты kobject, которые представляются с помощью структуры struct kobject, определенной в файле
Структура, с помощью которой реализованы объекты 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.
/* структура 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 указывает на массив структур attribute. Эти структуры определяют атрибуты, которые связаны с объектом kobject и используются но умолчанию. Атрибуты соответствуют свойствам данного объекта. Если некоторый объект kobject экспортируется через файловую систему sysfs, то атрибуты экспортируются как отдельные файлы. Последний элемент этого массива должен содержать значению NULL.
Множества объектов
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, которая определяет тип всех объектов данного множества, поле list — список всех объектов kobject данного множества, поле kobj — объект kobject, который представляет базовый класс для всех объектов данного множества, а поле hotplug_ops указывает на структуру, которая определяет поведение объектов kobject при горячем подключении устройств, связанных с данным множеством.
Наконец, поле subsys указывает на структуру struct subsystem, которая связана с данным множеством kset.
Подсистемы
Подсистемы используются для представления высокоуровневых концепций ядра и являются коллекцией одного или нескольких множеств kset. Множества kset содержат объекты kobject, подсистемы — множества kset, но связь между множествами в подсистеме значительно более слабая, чем связь между объектами kobject в множестве. Множества kset одной подсистемы могут иметь только наиболее общие объединяющие факторы.
Несмотря на их важную роль, подсистемы представляются с помощью очень простой структуры данных — struct subsystem.
struct subsystem {
struct kset kset;
struct rw_semaphore rwsem;
};
Структура subsystem содержит только одно множество kset, тем не менее несколько множеств kset могут указывать на общую структуру subsystem с помощью поля subsys. Такие однонаправленные взаимоотношения означают, что нет возможности определить все множества подсистемы, только имея ее структуру subsystem.
Поле kset, которое содержится в структуре subsystem, — это множество kset подсистемы, которое используется по умолчанию, чтобы зафиксировать положение этой подсистемы в иерархии объектов.
Поле rwsem структуры subsystem — это семафор чтения-записи (см. главу 9, "Средства синхронизации в ядре"), который используется для защиты подсистемы и ее множеств kset от конкурентного доступа. Все множества kset должны принадлежать какой-нибудь подсистеме, поскольку они используют семафор подсистемы для защиты своих данных от конкурентного доступа.
Путаница со структурами
Те несколько структур, которые только что были описаны, приводят к путанице не потому, что их много (только четыре) или они сложные (все они достаточно просты), а потому что они сильно друг с другом переплетаются. При использовании объектов kobject достаточно сложно рассказать об одной структуре, не упоминая другие. Тем не менее, на основании рассмотренных особенностей этих структур можно построить прочное понимание их взаимоотношений.
Самым важным является объект kobject, который представляется с помощью структуры struct kobject. Структура kobject используется для представления наиболее общих объектных свойств структур данных ядра, таких как счетчик ссылок, взаимоотношения родитель-порожденный и имя объекта. С помощью структуры kobject эти свойства можно обеспечить одинаковым для всех стандартным способом. Сами по себе структуры kobject не очень полезны, они обычно встраиваются в другие структуры данных.
С каждым объектом kobject связан один определенный тип данных — ktype, который представляется с помощью структуры struct kobj_type. На экземпляр такой структуры указывает поле ktype каждого объекта kobject. С помощью типов ktype определяются некоторые общие свойства объектов: поведение при удалении объекта, поведение, связанное с файловой системой sysfs, а также атрибуты объекта.
Объекты kobject группируются в множества, которые называются kset. Множества kset представляются с помощью структур данных struct kset. Эти множества предназначены для двух целей. Во-первых, они позволяют использовать встроенный в них объект kobject в качестве базового класса для группы других объектов kobject. Во-вторых, они позволяют объединять вместе несколько связанных между собой объектов kobject. На файловой системе sysfs объекты kobject представляются отдельными каталогами файловой системы. Связанные между собой каталоги, например все подкаталоги одного каталога, могут быть включены в одно множество kset.
Подсистемы соответствуют большим участкам ядра и являются набором множеств kset. Подсистемы представляются с помощью структур struct subsystem. Все каталоги, которые находятся в корне файловой системы sysfs, соответствуют подсистемам ядра.
На рис. 17.1 показаны взаимоотношения между этими структурами данных.
Рис. 17.1. Взаимоотношения между объектами kobject, множествами kset и подсистемами
Управление и манипуляции с объектами
kobject
Теперь, когда у нас уже есть представление о внутреннем устройстве объектов 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, как показано в следующем примере.
kobj = kmalloc(sizeof(*kobj), GFP_KERNEL);
if (!kobj)
return -ENOMEM;
memset(kobj, 0, sizeof(*kobj));
kobj->kset = kset;
kobj->parent = parent_kobj;
kobject_init(kobj);
После инициализации необходимо установить имя объекта с помощью функции kobject_set_name(), которая имеет следующий прототип.
int kobject_set_name(struct kobject* kobj,
const char* fmt, ...);
Эта функция принимает переменное количество параметров, по аналогии с функциями printf() и printk(). Как уже было сказано, на имя объекта указывает поле 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);
Если значение счетчика ссылок объекта, который передается в качестве параметра, становится равным нулю, то вызывается функция, на которую указывает указатель release поля ktype этого объекта.
Структуры
kref
Внутреннее представление счетчика ссылок выполнено с помощью структуры kref, которая определена в файле
struct kref {
atomic_t refcount;
};
Единственное поле этой структуры — атомарная переменная, в которой хранится значение счетчика ссылок. Структура используется просто для того, чтобы выполнять проверку типов. Чтобы воспользоваться структурой kref, необходимо ее инициализировать с помощью функции kref_init().
void kref_init(struct kref *kref) {
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);
}
Эта функция уменьшает значение счетчика ссылок на единицу и вызывает функцию release(), которая передастся ей в качестве параметра, когда значение счетчика ссылок становится равным нулю. Как видно из использованного выражения WARN_ON(), функция release() не может просто совпадать с функцией kfrее(), а должна быть специальной функцией, которая принимает указатель на структуру struct kref в качестве своего единственного параметра и не возвращает никаких значений.
Вместо того чтобы разрабатывать свои функции управления счетчиками ссылок на основании типа данных atomic_t, настоятельно рекомендуется использовать тип данных kref и соответствующие функции, которые обеспечивают общий и правильно работающий механизм поддержки счетчиков ссылок в ядре.
Все эти функции определены в файле lib/kref.c и объявлены в файле
Файловая система sysfs
Файловая система sysfs — это виртуальная файловая система, которая существует только в оперативной памяти и позволяет просматривать иерархию объектов kobject. Она позволяет пользователям просматривать топологию устройств операционной системы в виде простой файловой системы. Атрибуты объектов kobject могут экспортироваться в виде файлов, которые позволяют считывать значения переменных ядра, а также опционально записывать их.
Хотя изначально целью создания модели представления устройств было описание топологии устройств системы для управления электропитанием, файловая система sysfs стала удачным продолжением этой идеи. Для того чтобы упростить отладку, разработчик унифицированной модели устройств решил экспортировать дерево устройств в виде файловой системы. Такое решение показало свою полезность вначале в качестве замены файлов, связанных с устройствами, которые раньше экспортировались через файловую систему /proc, а позже в качестве мощного инструмента просмотра информации о системной иерархии объектов. Вначале, до появления объектов kobject, файловая система sysfs называлась driverfs. Позже стало ясно — новая объектная модель была бы очень кстати, и в результате этого появилась концепция объектов kobject. Сегодня каждая система, на которой работает ядро 2.6, имеет поддержку файловой системы sysfs, и практически во всех случаях эта файловая система монтируется.
Основная идея работы файловой системы sysfs — это привязка объектов kobject к структуре каталогов с помощью поля dentry, которое есть в структуре kobject. Вспомните из материала главы 12, "Виртуальная файловая система", что структура dentry используется для представления элементов каталогов. Связывание объектов с элементами каталогов проявляется в том, что каждый объект просто видится как каталог файловой системы. Экспортирование объектов kobject в виде файловой системы выполняется путем построения дерева элементов каталогов в оперативной памяти. Но обратите внимание, объекты kobject уже образуют древовидную структуру — нашу модель устройств! Поэтому простое назначение каждому объекту иерархии, которые уже образуют дерево в памяти, соответствующего элемента каталога позволяет легко построить файловую систему sysfs.
На рис. 17.2 показан частичный вид файловой системы sysfs, которая смонтирована на каталог /sys.
Рис. 17.2. Содержимое части каталога /sys
Корневой каталог файловой системы sysfs содержит семь подкаталогов: block, bus, class, devices, firmware, module и power. В каталоге block содержатся каталоги для каждого зарегистрированного в системе устройства блочного ввода-вывода.
Каждый из каталогов в свою очередь содержит подкаталоги, соответствующие разделам блочного устройства. Каталог 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.
Вместо того чтобы последовательно вызывать функции kobject_init() и kobject_add(), можно вызвать функцию kobject_register().
int kobject_register(struct kobject *kobj);
Удаление объекта из файловой системы sysfs выполняется с помощью функции kobject_del().
void kobject_del(struct kobject *kobj);
Функция kobject_unregister() сочетает в себе выполнение функций kobject_del() и kobject_put().
void kobject_unregister(struct kobject* kobj);
Все эти четыре функции определены в файле lib/kobject.c и объявлены в файле
Добавление файлов на файловой системе 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 принадлежат пользователю с идентификаторами пользователя и группы равными нулю.
Структура attribute используется для представления атрибутов, а структура 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);
};
Метод show() вызывается при чтении файла. Он должен выполнить копирование значения атрибута, который передается в качестве параметра attr, в буфер, на который указывает параметр buffer. Размер буфера равен PAGE_SIZE байт. Для аппаратной платформы значение PAGE_SIZE равно 4096 байтов. Функция должна возвратить количество байтов данных, которые записаны в буфер в случае успешного завершения, и отрицательный код ошибки, если такая ошибка возникает.
Метод store() вызывается при записи. Он должен скопировать size байт данных из буфера buffer в атрибут attr. Размер буфера всегда равен PAGE_SIZE или меньше. Функция должна возвратить количество байтов данных, которые прочитаны из буфера при успешном выполнении, и отрицательный код ошибки в случае неудачного завершения.
Так как этот набор функций должен выполнять операции ввода-вывода для всех атрибутов, то необходимо выполнить некоторые дополнительные действия, чтобы вызвать обработчик, специфичный для каждого атрибута.
Создание нового атрибута
Обычно атрибутов, которые используются по умолчанию и предоставляются типом ktype, связанным с объектом kobject, оказывается достаточно. Действительно, все объекты kobject одного типа должны быть чём-то похожи друг на друга или даже быть идентичными по своей природе. Например, для всех разделов жестких дисков один и тот же набор атрибутов должен подходить для всех объектов kobject. Это не просто упрощает жизнь, но и позволяет упорядочить код и получить одинаковый способ доступа ко всем каталогам файловой системы sysfs, связанным с родственными объектами.
Тем не менее иногда требуется, чтобы определенный экземпляр объекта kobject имел некоторые специфические свойства. Для таких объектов может оказаться желательным (или необходимым) создать атрибут, которого нет у общего типа данного объекта. Для такого случая ядро предоставляет функцию sysfs_create_file() для добавления атрибута к существующему объекту.
int sysfs_create_file(struct kobject *kobj, const struct attribute *attr);
Эта функция позволяет привязать структуру attribute, на которую указывает параметр attr, к объекту kobject, на который указывает параметр kobj. Перед тем как вызвать эту функцию, необходимо установить значение атрибута (заполнить поля структуры). Эта функция возвращает значение нуль в случае успеха и отрицательное значение в случае ошибки.
Обратите внимание, что для обработки указанного атрибута используется структура sysfs_ops, соответствующая типу ktype объекта. Иными словами, существующие функции show() и store(), которые используются для объекта по умолчанию, должны иметь возможность обработать вновь созданный атрибут.
Кроме того, существует возможность создавать символьные ссылки. Создать символьную ссылку на файловой системе sysfs можно с помощью вызова следующей функции.
int sysfs_create_link(struct kobject *kobj,
struct kobject *target, char *name);
Эта функция создает символьную ссылку с именем name в каталоге объекта, соответствующего параметру kobj, на каталог, соответствующий параметру target. Эта функция возвращает нулевое значение в случае успеха и отрицательный код ошибки в противном случае.
Удаление созданного атрибута
Удаляется атрибут с помощью вызова функции sysfs_remove_file().
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
Файловая система sysfs — это место, где должна реализовываться функциональность, для которой раньше использовался системный вызов ioctl() для специальных файлов устройств, или файловая система procfs. Сегодня модно выполнять такие вещи через атрибуты файловой системы sysfs в соответствующем каталоге. Например, вместо того чтобы реализовать новую директиву ioctl() для специального файла устройства, лучше добавить соответствующий атрибут в каталоге файловой системы sysfs, который относится к этому устройству. Такой подход позволяет избежать использования небезопасных, из-за отсутствия проверки типов аргументов, директив ioctl(), а также файловой системы /proc с ее бессистемным расположением файлов и каталогов.
Однако чтобы файловая система sysfs оставалась четко организованной и интуитивно понятной, разработчики должны придерживаться определенных соглашений.
Во-первых, каждый атрибут sysfs должен экспортировать значение одной переменной на файл. Значения должны быть в текстовом формате и соответствовать простым типам языка программирования С. Целью такого представления является необходимость избежать чрезвычайно запутанного и плохо структурированного представления информации, которое мы сегодня имеем на файловой системе /proc. Использование одной переменной на файл позволяет легко считывать и записывать данные из командной строки, а также просто работать через файловую систему sysfs с данными ядра в программах, написанных на языке С. В случаях, когда одно значение на файл приводит к неэффективному представлению информации, допустимо использование файлов, в которых хранится несколько значений одного типа. Эти данные необходимо четко разделять. Наиболее предпочтительным разделителем является символ пробела. При разработке кода ядра необходимо всегда помнить, что файлы файловой системы sysfs являются представлениями переменных ядра, и ориентироваться на доступ к ним из пространства пользователя, в частности из командной строки.
Во-вторых, данные файловой системы sysfs должны быть организованы в виде четкой иерархии. Для этого необходимо правильно разрабатывать связи "родитель- потомок" объектов kobject. Связывать атрибуты с объектами kobject необходимо с учетом того, что эта иерархия объектов существует не только в ядре, но и экспортируется в пространство пользователя. Структуру файловой системы sysfs необходимо поддерживать в четком виде!
Наконец, необходимо помнить, что файловая система sysfs является службой ядра и в некотором роде интерфейсом ядра к прикладным программам (Application Binary Interface, ABT). Пользовательские программы должны разрабатываться в соответствии с наличием, положением, содержимым и поведением каталогов и файлов на файловой системе sysfs. Изменение положения существующих файлов крайне не рекомендуется, а изменение поведения атрибутов, без изменения их имени или положения, может привести к серьезным проблемам.
Эти простые соглашения позволяют с помощью файловой системы sysfs обеспечить в пространстве пользователя интерфейс ядра с широкими возможностями. При правильном использовании файловой системы sysfs разработчики прикладных программ не будут вас ругать и будут вам благодарны за хороший код.
Уровень событий ядра
Уровень событий ядра (kernel event layer) — это подсистема, которая позволяет передавать информацию о различных событиях из ядра в пространство пользователя и реализована, как вы уже, наверное, догадываетесь, на базе объектов kobject. После выпуска ядра версии 2.6.0 стало ясно, что необходим механизм для отправления сообщений из ядра в пространство пользователя, в частности для настольных рабочих компьютеров, что позволит сделать такие системы более функциональными, а также лучше использовать асинхронную обработку. Идея состояла в том, что ядро будет помещать возникающие события в стек. Например, "Жесткий диск переполнен!", "Процессор перегрелся!", "Раздел диска смонтирован!", "На горизонте появился пиратский корабль!" (последнее, конечно, шутка).
Первые реализации подсистемы событий ядра появились незадолго до того, как эта подсистема стала тесно связанной с объектами kobject и файловой системой sysfs. В результате такой связи реализация получилась достаточно красивой. В модели уровня событий ядра, события представляются в виде сигналов, которые посылаются объектами, в частности объектами типа kobject. Так как объекты отображаются на элементы каталогов файловой системы sysfs, то источниками событий являются определенные элементы пути на файловой системе sysfs. Например, если поступившее событие связано с первым жестким диском, то адресом источника события является каталог /sys/block/hda. Внутри же ядра источником события является соответствующий объект kobject.
Каждому событию присваивается определенная строка символов, которая представляет сигнал и называется командой (verb) или действием (action). Эта строка символов содержит в себе информацию о том, что именно произошло, например изменение (modified) или размонтирование (unmounted).
Каждое событие может нести в себе некоторую дополнительную информацию (дополнительную нагрузку, payload). Вместо того чтобы передавать в пространство пользователя строку, которая содержит эту полезную информацию, данная дополнительная информация представляется с помощью атрибутов, отображаемых на файловой системе sysfs.
События ядра поступают из пространства ядра в пространство пользователя через интерфейс netlink. Интерфейс netlink — это специальный тип высокоскоростного сетевого сокета групповой передачи (multicast), который используется для передачи сообщений, связанных с сетевой подсистемой. Использование интерфейса netlink позволяет выполнить обработку событий ядра с помощью простых блокирующих вызовов функций для чтения информации из сокетов. Задача пространства пользователя — реализовать системный процесс-демон, который выполняет прослушивание сокета, считывает информацию о всех приходящих событиях, обрабатывает их и отправляет полученные сообщения в системный стек пространства пользователя. Одна из возможных реализаций такого демона, работающего в пространстве пользователя, — это D-BUS. который также реализует и системную шину сообщений. Таким образом, ядро может подавать сигналы так же, как это делают все остальные компоненты системы.
Для отправки события в пространство пользователя код ядра должен вызвать функцию kobject_uevent().
int kobject_uevent(struct kobject *kobj,
enum kobject_action action, struct attribute *attr);
Первый параметр указывает объект kobject, который является источником сигнала. Соответствующее событие ядра будет содержать элемент пути на файловой системе sysfs, связанный с объектом, сгенерировавшим сигнал.
Второй параметр позволяет указать команду или событие, которое описывает сигнал. Сгенерированное событие ядра будет содержать строку, которая соответствует номеру, передаваемому в качестве значения параметра enum kobject_action. Вместо того чтобы непосредственно передать строку, здесь используется ее номер, который имеет тип перечисления (enum). Это дает возможность более строго выполнить проверку типов, изменить соответствие между номером строки и самой строкой в будущем, а также уменьшить количество ошибок и опечаток. Перечисления определены в файле
Последний параметр — опциональный указатель на структуру attribute. Этот параметр можно трактовать как дополнительную информацию (payload) о событии. Если только одного значения события недостаточно, то событие может предоставить информацию о том, в каком файле файловой системы sysfs содержатся дополнительные данные.
Рассмотренная функция использует динамическое выделение памяти и поэтому может переходить в состояние ожидания. Существует атомарная версия рассмотренной функции, которая идентична ей по всем, кроме того что при выделении использует флаг GFP_ATOMIC.
int kobject_uevent_atomic(struct kobject *kobj,
enum kobject_action action, struct attribute *attr);
По возможности необходимо использовать стандартный интерфейс без атомарного выделения памяти. Параметры этих функций и их смысл — идентичны.
Использование объектов kobject и их атрибутов не только дают возможность описать события в терминах файловой системы sysfs, но и стимулируют создание новых объектов и их атрибутов, которые еще не представлены через файловую систему sysfs.
Обе рассмотренные функции определены в файле lib/kobject_uevent.c и объявлены в файле
Кратко об объектах
kobject
и файловой системе sysfs
В этой главе рассматривается модель представления устройств, файловая система sysfs, объекты kobject и уровень событий ядра. Описание материала главы было бы невозможно без рассмотрения родственных вещей: были также описаны множества kset, подсистемы, атрибуты, типы ktype и счетчики ссылок kref. Эти структуры предназначены для использования разными людьми в разных местах. Разработчикам драйверов необходимо только ознакомление с внешними интерфейсами. Большинство подсистем драйверов эффективно скрывают внутренние механизмы использования объектов kobject и других, близких к ним структур. Понимание основных принципов работы и знание основного назначения интерфейсов, таких как sysfs_create_file(), является достаточным для разработчиков драйверов. Однако для разработчиков, которые занимаются разработкой основного кода ядра, может потребоваться более детальное понимание принципов функционирования объектов kobject. Объекты kobject могут оказаться еще более важными, так как их могут использовать и те разработчики, которые вообще не занимаются разработкой подсистем драйверов!!!
Эта глава — последняя из тех, которые посвящены подсистемам ядра. В следующих главах будут рассмотрены некоторые общие вопросы, которые также могут оказаться важными для разработчиков ядра. Например, основные рекомендации по отладке кода!