Ори Померанц - Энциклопедия разработчика модулей ядра Linux

* (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 c %d \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);

}

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

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

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

В Linux имеется дополнительный механизм для ядра и ядерных модулей, чтобы они могли послать информацию процессам: файловая система /proc. Первоначально разработанная для свободного доступа к информации относительно процессов, она теперь используется каждым кусочком ядра, который может что-либо сообщить, например, /proc/modules, который имеет список модулей и /proc/meminfo, который имеет статистику использования памяти.

Метод использования файловой системы /proc очень похож на работу с драйверами устройства: Вы создаете структуру со всей информацией, необходимой для /proc файла, включая указатели на любые функции драйвера (в нашем случае имеется только один, вызываемый когда кто-то пытается читать из /proc файла). Затем init_module регистрирует структуру и cleanup_module отменяет регистрацию.

Причина по которой мы используем proc_register_dynamic [2] В версии 2.0, в версии 2.2 это выполняется для нас автоматически, если мы устанавливаем inode в ноль. в том, что мы не хотим определять inode номер, используемый для нашего файла заранее, но позволяем ядру определять его, чтобы предотвратить столкновения. В нормальных файловых системах размещенных на диске, а не только в памяти (как /proc) inode является указателем на то место, в котором на диске размещен индексный узел файла (кратко, inode). Inode содержит информацию относительно файла, например разрешения файла, вместе с указателем на то место, где могут быть найдены данные файла.