Файлы символьных устройств

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

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

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

Например, если Вы даете команду ls -l /dev/hd[ab]*, вы увидите все IDE разделы жесткого диска, которые могли бы быть связаны с машиной. Обратите внимание, что все из них используют тот же самый главный номер, 3, но малые номера у каждого свои! Оговорка: Считается, что вы используете архитектуру PC. Я не знаю ничего относительно файлов устройств Linux на других архитектурах.

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

Устройства разделены на два типа: символьные и блочные. Различие в том, что блочные имеют буфер для запросов, так что они могут выбирать в каком порядке им отвечать. Это важно в случае устройств памяти, где скорее понадобится читать или писать сектора, которые ближе друг к другу, чем те, которые находятся далеко. Другое различие: блочные устройства могут принимать ввод и возвращать вывод только в блоках (чей размер может измениться согласно устройству), в то время как символьные устройства могут использовать столько байтов, сколько нужно. Большинство устройств в мире символьно, потому что они не нуждаются в этом типе буферизации и не работают с фиксированным размером блока. Вы можете узнать, является ли устройство блочным или символьным, рассматривая первый символ в выводе ls -l. Если это "b", значит устройство блочное, а если "c", то символьное.

Этот модуль разделен на две отдельных части: часть модуля, которая регистрирует устройство и часть драйвера устройства. init_module вызывает module_register_chrdev, чтобы добавить драйвер устройства к символьной таблице драйверов устройств ядра. Этот вызов также возвращает главный номер, который нужно использовать для драйвера. Функция cleanup_module вычеркивает из списка устройство.

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

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

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

Обычно, когда Вы не хотите выполнять что-либо, Вы возвращаете код ошибки (отрицательное число) из функции, которая делает данное действие. С cleanup_module такой фокус не пройдет: если cleanup_module вызван, модуль завершился. Однако, имеется счетчик использований, который считает, сколько других модулей используют этот модуль, названный номером ссылки (последний номер строки в /proc/modules). Если это число не нулевое, rmmod будет терпеть неудачу. Счетчик модульных ссылок доступен в переменной mod_use_count_. Так как имеются макрокоманды, определенные для обработки этой переменной (MOD_INC_USE_COUNT и MOD_DEC_USE_COUNT), мы предпочитаем использовать их, а не mod_use_count_ непосредственно, так что мы будем в безопасности, если реализация изменится в будущем.

chardev.c

/* chardev.c

* Copyright (C) 1998-1999 by Ori Pomerantz

*

* Create a character device (read only)

*/

/* The necessary header files */

/* Standard in kernel modules */

#include <linux/kernel.h> /* We're doing kernel work */

#include <linux/module.h> /* Specifically, a module */

/* Deal with CONFIG_MODVERSIONS */

#if CONFIG_MODVERSIONS==1

#define MODVERSIONS

#include <linux/modversions.h>

#endif

/* For character devices */

#include <linux/fs.h> /* The character device definitions are here */

#include <linux/wrapper.h> /* A wrapper which does next to nothing at present, but may help for compatibility with future versions of Linux */

/* In 2.2.3 /usr/include/linux/version.h includes a macro for this, but 2.0.35 doesn't - so I add it here if necessary. */

#ifndef KERNEL_VERSION

#define KERNEL_VERSION(a,b,c)

((a)*65536+(b)*256+(c))

#endif

/* Conditional compilation. LINUX_VERSION_CODE is the code (as per KERNEL_VERSION) of this version. */

#if LINUX_VERSION_CODE > KERNEL_VERSION(2,2,0)

#include <asm/uaccess.h> /* for put_user */

#endif

#define SUCCESS 0

/* Device Declarations **************************** */

/* The name for our device, as it will appear in /proc/devices */

#define DEVICE_NAME "char_dev"

/* The maximum length of the message from the device */

#define BUF_LEN 80

/* Is the device open right now? Used to prevent concurent access into the same device */

static int Device_Open = 0;

/* The message the device will give when asked */

static char Message[BUF_LEN];

/* How far did the process reading the message get? Useful if the message is larger than the size of the buffer we get to fill in device_read. */

static char *Message_Ptr;

/* This function is called whenever a process attempts to open the device file */

static int device_open(struct inode *inode, struct file *file) {

static int counter = 0;

#ifdef DEBUG

printk("device_open(%p,%p)\n", inode, file);

#endif

/* This is how you get the minor device number in case you have more than one physical device using the driver. */

printk("Device: %d.%d\n", inode->i_rdev >> 8, inode->i_rdev & 0xFF);

/* We don't want to talk to two processes at the same time */

if (Device_Open) return -EBUSY;

/* If this was a process, we would have had to be

* more careful here.

*

* In the case of processes, the danger would be

* that one process might have check Device_Open

* and then be replaced by the schedualer by another

* process which runs this function. Then, when the

* first process was back on the CPU, it would assume

* the device is still not open.

*

* However, Linux guarantees that a process won't be

* replaced while it is running in kernel context.

*

* In the case of SMP, one CPU might increment

* Device_Open while another CPU is here, right after

* the check. However, in version 2.0 of the

* kernel this is not a problem because there's a lock

* to guarantee only one CPU will be kernel module at

* the same time. This is bad in terms of

* performance, so version 2.2 changed it.

* Unfortunately, I don't have access to an SMP box

* to check how it works with SMP. */

Device_Open++;

/* Initialize the message. */

sprintf(Message, "If I told you once, I told you %d times - %s", counter++, "Hello, world\n");

/* The only reason we're allowed to do this sprintf

* is because the maximum length of the message

* (assuming 32 bit integers - up to 10 digits

* with the minus sign) is less than BUF_LEN, which

* is 80. BE CAREFUL NOT TO OVERFLOW BUFFERS,

* ESPECIALLY IN THE KERNEL!!! */

Message_Ptr = Message;

/* Make sure that the module isn't removed while

* the file is open by incrementing the usage count

* (the number of opened references to the module, if

* it's not zero rmmod will fail)

*/

MOD_INC_USE_COUNT;

return SUCCESS;

}

/* This function is called when a process closes the

* device file. It doesn't have a return value in

* version 2.0.x because it can't fail (you must ALWAYS

* be able to close a device). In version 2.2.x it is

* allowed to fail - but we won't let it. */

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

static int device_release(struct inode *inode, struct file *file)

#else

static void device_release(struct inode *inode, struct file *file)

#endif

{

#ifdef DEBUG

printk("device_release(%p,%p)\n", inode, file);

#endif

/* We're now ready for our next caller */

Device_Open--;

/* Decrement the usage count, otherwise once you opened the file you'll never get rid of the module. */

MOD_DEC_USE_COUNT;

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

return 0;

#endif

}

/* This function is called whenever a process which

* have already opened the device file attempts to

* read from it. */

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

static ssize_t device_read(struct file *file,

char *buffer, /* The buffer to fill with data */

size_t length, /* The length of the buffer */

loff_t *offset) /* Our offset in the file */

#else

static int device_read(struct inode *inode, struct file *file,

char *buffer, /* The buffer to fill with the data */

int length) /* The length of the buffer (mustn't write beyond that!) */

#endif

{

/* Number of bytes actually written to the buffer */

int bytes_read = 0;

/* If we're at the end of the message, return 0 (which signifies end of file) */

if (*Message_Ptr == 0) return 0;

/* Actually put the data into the buffer */

while (length && *Message_Ptr) {

/* Because the buffer is in the user data segment,

* not the kernel data segment, assignment wouldn't

* work. Instead, we have to use put_user which

* copies data from the kernel data segment to the

* user data segment. */

put_user(*(Message_Ptr++), buffer++);

length--;

bytes_read++;

}

#ifdef DEBUG

printk("Read %d bytes, %d left\n", bytes_read, length);

#endif

/* Read functions are supposed to return the number of bytes actually inserted into the buffer */

return bytes_read;

}

/* This function is called when somebody tries to write

* into our device file - unsupported in this example. */

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

static ssize_t device_write(struct file *file,

const char *buffer, /* The buffer */

size_t length, /* The length of the buffer */

loff_t *offset) /* Our offset in the file */

#else

static int device_write(struct inode *inode, struct file *file, const char *buffer, int length)

#endif

{

return -EINVAL;

}

/* Module Declarations ***************************** */

/* The major device number for the device. This is

* global (well, static, which in this context is global

* within this file) because it has to be accessible * both for registration and for release. */

static int Major;

/* This structure will hold the functions to be

* called when a process does something to the device

* we created. Since a pointer to this structure is

* kept in the devices table, it can't be local to

* init_module. NULL is for unimplemented functions. */

struct file_operations Fops = {

NULL, /* seek */

device_read, device_write,

NULL, /* readdir */

NULL, /* select */

NULL, /* ioctl */

NULL, /* mmap */

device_open,

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

NULL, /* flush */

#endif

device_release /* a.k.a. close */

};

/* Initialize the module - Register the character device */

int init_module() {

/* Register the character device (atleast try) */

Major = module_register_chrdev(0, DEVICE_NAME, &Fops);

/* Negative values signify an error */

if (Major < 0) {

printk("%s device failed with %d\n", "Sorry, registering the character", Major);

return Major;

}

printk("%s The major device number is %d.\n", "Registeration is a success.", Major);

printk("If you want to talk to the device driver,\n");

printk("you'll have to create a device file. \n");

printk("We suggest you use:\n");

printk("mknod <name> c %d <minor>\n", Major);

printk("You can try different minor numbers %s", "and see what happens.\n");

return 0;

}

/* Cleanup - unregister the appropriate file from /proc */

void cleanup_module() {

int ret;

/* Unregister the device */

ret = module_unregister_chrdev(Major, DEVICE_NAME);

/* If there's an error, report it */

if (ret < 0) printk("Error in unregister_chrdev: %d\n", ret);

}

Исходники для разных версий ядра Files

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

Версии ядра Linux разделены между устойчивыми версиями (n.<Четное число>.m) и версии разработки (n.<Нечетное число>.m). Версии разработки включают все новые идеи, включая те, которые будут считаться ошибкой или повторно выполнены в следующей версии. В результате Вы не можете доверять интерфейсу в том плане, что он останется тем же самым в версиях разработки. В устойчивых версиях мы можем ожидать, что интерфейс останется тем же самым независимо от версии исправления ошибок (число m).

Эта версия MPG включает поддержку для версии 2.0.x и версии ядра Linux. Так как имеются различия между ними, требуется условная трансляция в зависимости от версии. Способ сделать это сводится к тому, чтобы использовать макрокоманду LINUX_VERSION_CODE. В версии a.b.c ядра значение этой макрокоманды было бы 2¹⁶a+2⁸b+c. Чтобы получать значение для конкретной версии, мы можем использовать макрокоманду KERNEL_VERSION. Так как этот макрос не определен в 2.0.35, мы определяем его сами в случае необходимости.

Оглавление