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

#endif

 mark_bh(IMMEDIATE_BH);

}

/* Initialize the module - register the IRQ handler */

int init_module() {

 /* Since the keyboard handler won't co-exist with

 * another handler, such as us, we have to disable

 * it (free its IRQ) before we do anything. Since we

 * don't know where it is, there's no way to

 * reinstate it later - so the computer will have to

 * be rebooted when we're done.  */

 free_irq(1, NULL);

 /* Request IRQ 1, the keyboard IRQ, to go to our irq_handler. */

 return request_irq(

  1,  /* The number of the keyboard IRQ on PCs */

  irq_handler,  /* our handler */

  SA_SHIRQ,

  /* SA_SHIRQ means we're willing to have othe

  * handlers on this IRQ.

  *

  * SA_INTERRUPT can be used to make the

  * handler into a fast interrupt. */

  "test_keyboard_irq_handler", NULL);

}

/* Cleanup */

void cleanup_module() {

 /* This is only here for completeness. It's totally

 * irrelevant, since we don't have a way to restore

 * the normal keyboard interrupt so the computer

 * is completely useless and has to be rebooted. */

 free_irq(1, NULL);

}

Симметричная многопроцессорность

Один из самых простых (самый дешевый) способ улучшить аппаратную эффективность: поместить больше чем один CPU на плате. Когда такое сделано, могут быть два варианта: либо CPU берут различные работы (асимметричная многопроцессорная обработка) или они все работают параллельно, делая ту же самую работу (симметрическая многопроцессорная обработка, a.k.a. SMP). Выполнение асимметричной многопроцессорной обработки действительно требует специализированного знания относительно задач, которые компьютер должен делать. Такое знание является недоступным в универсальной операционной системе типа Linux. С другой стороны, симметрическая многопроцессорная обработка относительно проста в реализации.

В симметрической многопроцессорной среде CPU совместно используют ту же самую память, и в результате код, работающий на одном CPU может воздействовать на память используемую другим. Вы больше не можете быть уверены, что переменная, которую вы установили в некоторое значение на предыдущей строке все еще имеет то же самое значение: другой CPU может его поменять, в то время как Вы не смотрели.

В случае программирования процесса это обычно не проблема, потому что процесс будет обычно выполняться только на одном CPU сразу[14]. Ядро, с другой стороны, может быть вызвано различными процессами, работающими на различных CPU.

В версии 2.0.x, это не проблема, потому что все ядро находится в одном большом spinlock. Это означает что, если один CPU работает с ядром, и другой CPU хочет обратиться к ядру, например из-за системного вызова, он должно ждать, до тех пор пока первый CPU завершит работу с ядром. Это делает Linux SMP безопасным[15], но неэффективным.

В версии 2.2.x, несколько CPU могут работать с ядром одновременно. Это авторы модуля должны знать. Я надеюсь, что смогу получить доступ к машине с несколькими процессорами, и следующая версия этой книги будет включать большее количество информации.

Общие ловушки

Прежде чем писать ядерные модули, надо учесть несколько важных моментов.

1. Использование стандартных библиотек. Вы не можете делать этого. В модуле, Вы можете использовать только функции, которые Вы можете увидеть в /proc/ksyms.

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

Различия между версиями 2.0 и 2.2

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