* 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 . Затем модуль удаляется из памяти со всеми функциями. Никто не проверяет(отмечает), чтобы видеть, содержит ли список задач таймера указатель на одну из тех функций, которые больше не будут доступны. Позже (с точки зрения компьютера, с точки зрения человека мгновенно: меньше чем сотая доля секунды, то есть фактически мгновенно), ядро получит прерывание от таймера и попробует вызывать функцию в списке задач. К сожалению, функции больше там нет. В большинстве случаев, страница памяти, где она была, не используется, и Вы получаете сообщение об ошибке. Но если некоторый другой код теперь хранится в том же самом месте памяти, дело плохо. К сожалению, мы не имеем простой способ удалить задачу из списка задачи.
Так как cleanup_module не может вернуть код ошибки (она имеет тип возврата void), возникает решение не позволить возвращаться вообще. Вместо завершения модуля мы вызываем sleep_on или module_sleep_on[11] чтобы отправить в спячку сам rmmod. Перед этим мы сообщаем функции, вызываемой по прерыванию таймера, чтобы она убрала себя из списка, устанавливая глобальную переменную. На следующем прерывании таймера, процесс rmmod будет пробужден, когда наша функция больше не в очереди, и безопасно удалит модуль.
/* sched.c - schedule a function to be called on
* every timer interrupt.
*/
/* Copyright (C) 1998 by Ori Pomerantz */
/* 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
/* Necessary because we use the proc fs */
#include <linux/proc_fs.h>
/* We scheduale tasks here */
#include <linux/tqueue.h>
/* We also need the ability to put ourselves to sleep
* and wake up later */
#include <linux/sched.h>
/* 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
/* The number of times the timer interrupt has been
* called so far */
static int TimerIntrpt = 0;
/* This is used by cleanup, to prevent the module from
* being unloaded while intrpt_routine is still in
* the task queue */
static struct wait_queue *WaitQ = NULL;
static void intrpt_routine(void *);
/* The task queue structure for this task, from tqueue.h */
static struct tq_struct Task = {
NULL, /* Next item in list - queue_task will do
* this for us */
0, /* A flag meaning we haven't been inserted