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

* get dangerous if there are still processes waiting in
* WaitQ, because they are inside our open function,
* which will get unloaded. I'll explain how to avoid
* removal of a kernel module in such a case in chapter 10. */
void cleanup_module() {
 proc_unregister(&proc_root, Our_Proc_File.low_ino);
}

Замена для printk

В начале (глава1), я сказал, что X и программирование модулей ядра не совместимы. Это истинно при разработке модуля, но в фактическом использовании, Вы должны быть способны послать сообщениям любому tty[10]. Это важно для идентификации ошибок после того, как модуль выпущен, потому что он будет использоваться через любой из терминалов.

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

printk.c

/* printk.c - send textual output to the tty you're
* running on, regardless of whether it's passed
* through X11, telnet, etc.
*/
/* Copyright (C) 1998 by Ori Pomerantz */

/* The necessary header files */
/* Standard in kernel modules */
#include  /* We're doing kernel work */
#include  /* Specifically, a module */

/* Deal with CONFIG_MODVERSIONS */
#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include
#endif

/* Necessary here */
#include  /* For current */
#include  /* For the tty declarations */

/* Print the string to the appropriate tty, the one
* the current task uses */
void print_string(char *str) {
 struct tty_struct *my_tty;
 /* The tty for the current task */
 my_tty = current->tty;
 /* If my_tty is NULL, it means that the current task
 * has no tty you can print to (this is possible, for
 * example, if it's a daemon). In this case, there's
 * nothing we can do. */
 if (my_tty != NULL) {
  /* my_tty->driver is a struct which holds the tty's
  * functions, one of which (write) is used to
  * write strings to the tty. It can be used to take
  * a string either from the user's memory segment
  * or the kernel's memory segment.
  *
  * The function's first parameter is the tty to
  * write to, because the same function would
  * normally be used for all tty's of a certain type.
  * The second parameter controls whether the
  * function receives a string from kernel memory
  * (false, 0) or from user memory (true, non zero).
  * The third parameter is a pointer to a string,
  * and the fourth parameter is the length of
  * the string. */
  (*(my_tty->driver).write)(
   my_tty, /* The tty itself */
   0, /* We don't take the string from user space */
   str, /* String */
   strlen(str)); /* Length */
  /* ttys were originally hardware devices, which
  * (usually) adhered strictly to the ASCII standard.
  * According to ASCII, to move to a new line you
  * need two characters, a carriage return and a
  * line feed. In Unix, on the other hand, the
  * ASCII line feed is used for both purposes - so
  * we can't just use \n, because it wouldn't have
  * a carriage return and the next line will
  * start at the column right after the line feed.
  *
  * BTW, this is the reason why the text file
  * is different between Unix and Windows.
  * In CP/M and its derivatives, such as MS-DOS and
  * Windows, the ASCII standard was strictly
  * adhered to, and therefore a new line requires
  * both a line feed and a carriage return. */
  (*(my_tty->driver).write)(my_tty, 0, "\015\012", 2);
 }
}

/* Module initialization and cleanup ****************** */

/* Initialize the module - register the proc file */
int init_module() {
 print_string("Module Inserted");
 return 0;
}

/* Cleanup - unregister our file from /proc */
 void cleanup_module() {
 print_string("Module Removed");
}

Планирование задач

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

Вместо того, чтобы делать это, мы можем создавать функцию, которая будет вызвана прерыванием таймера. Таким путем мы создаем запись, хранимую в struct tq_struct, которая хранит указатель на функцию. Затем мы используем queue_task, чтобы поместить эту задачу в список задач, tq_timer, который является списком задач, которые будут выполнены на следующем прерывании таймера. Поскольку мы хотим, чтобы функция продолжила выполнение, мы должны поместить ее обратно в tq_timer всякий раз, когда она вызвана для следующего прерывания таймера.

Имеется еще одна хитрость. Когда модуль удален rmmod, сначала проверяется счетчик ссылок. Если он нулевой, вызывается module_cleanup . Затем модуль удаляется из памяти со всеми функциями. Никто не проверяет(отмечает), чтобы видеть, содержит ли список задач таймера указатель на одну из тех функций, которые больше не будут доступны. Позже (с точки зрения компьютера, с точки зрения человека мгновенно: меньше чем сотая доля секунды, то есть фактически мгновенно), ядро получит прерывание от таймера и попробует вызывать функцию в списке задач. К сожалению, функции больше там нет. В большинстве случаев, страница памяти, где она была, не используется, и Вы получаете сообщение об ошибке. Но если некоторый другой код теперь хранится в том же самом месте памяти, дело