Linux Device Drivers 3 / Драйверы устройств Линукс (третье издание): 2.3. Модули ядра в сравнении с приложениями

Модули ядра в сравнении с приложениями

hardorsoft 23.10.10 в 07:58

Прежде чем двигаться дальше, необходимо понять различия между модулями ядра и
приложениями.

hardorsoft 23.10.10 в 08:50

В то время как большинство приложений выполняют одну задачу от начала до конца, каждый модуль просто регистрирует себя в порядке выполнения будущего запроса и инициируют функции которые непосредственно завершают его (запрос). Другими словами, задачу функции инициализации модулей — которая подготовляет более поздний вызов функций модулей, можно объяснить так: модуль говорит «Привет, я здесь, вот что я могу делать.» Функция выхода модуля (hello_exit в примере), вызывается только для того чтобы выгрузить модуль. Она говорит ядру: «Меня здесь больше нет, не больше не просите меня ни о чем.» Этот вид подхода в программировании похож на программирование «случайного управления», но пока не все приложения «случайного управления», как все и каждый модуль ядра. Другое важное отличие между приложениями «случайного управления» и кодом ядра это функция выхода: пока приложение, которое завершает свою работу лениво высвобождает ресурсы или избегает отключать все сразу, функция выхода (exit function) модуля должна внимательно отменить все что создала функция инициализации (init fuction) иначе куски кода будут оставаться в ядре до тех пор пока система не перегрузится.

hardorsoft 23.10.10 в 08:28

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

ximen 22.10.10 в 13:34

Как программист вы знаете, что приложения могут вызывать функции, не определяя их: связанная стадия вызова внешних ссылок использует соответствующую библиотеку функций. printf -- одна из таких вызываемых функций, она определена в libc. Модуль, с другой стороны, связан только с ядром, и может вызывать только те функции, которые экспортируются ядром. Функция printk, которую мы использовали ранее в файле hello.c., для примера, является версией printf, определенной внутри ядра и экспортируемой в модули. Она ведет себя подобно оригинальной функции с некоторыми маловажными различиями. Основной её недостаток заключается в том, что она не поддерживает числа с плавающей точкой.

galleyworm 12.04.12 в 06:12

Рисунок 2-1 показывает как вызовы функции и указатели используются в модулях и добавляют новую функциональность работающему ядру.

hardorsoft 23.10.10 в 10:42

Рисунок 2-1. Связь модулей в ядре

hardorsoft 23.10.10 в 10:42

Так как нет библиотек связанных с модулями, исходные файлы как правило ни когда не включают заголовки файлов, и в очень редких случаях в качестве исключения. Только функции которые в настоящее время являются частью ядра могут быть использованы в модулях ядра. Все что вы брали и сконфигурировали связанно с ядром и определено в заголовке который можно найти в исходном дереве ядра, большинство относящихся к делу заголовков находятся в директориях include/linux и include/asm, но другие поддиректории директории include добавлены в содержании материала связанны с особенными подсистемами ядра.

hardorsoft 23.10.10 в 10:42

Роль каждого отдельного заголовка ядра которые объясняются на протяжении всей книги тогда когда это необходимо.

hardorsoft 23.10.10 в 11:05

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

hardorsoft 23.10.10 в 11:05

2.3.1. Пространство пользователя и пространство ядра.

hardorsoft 23.10.10 в 11:05

Модуль работает в пространстве ядра, в то время как приложение в пространстве пользователя.

hardorsoft 23.10.10 в 11:18

Роль операционной системы на практике — предоставить программам согласующийся вид аппаратного обеспечения компьютера. В дополнение, операционная система должна считать независимые операции программ и защищать от несанкционированного доступа к ресурсам. Эта не очевидная задача возможна только если ЦрУ навязывает защиту программного обеспечения системы от приложений.

hardorsoft 23.10.10 в 11:17

Каждый современный процессор позволяет навязывать такой режим работы. Избранный подход осуществляет различные операционные модальности (или уровни) внутри ЦрУ. Уровни играют разную роль и некоторые операции не разрешены более низким уровням, код программы может переключаться с одного уровня на другой только через ограниченное число входов. Юникс системы разработаны таким образом, чтобы дать расширение этих возможностей аппаратного обеспечения, используя два таких уровня. В настоящее время все процессоры поддерживают два уровня защиты а некоторые такие как семейство х86, имеют в распоряжении ещё больше уровней, когда отдельные уровни отсутствуют, тогда используются более высокие и более низкие уровни. В Юниксах ядро выполняется на самом высоком уровне (оно называется ещё режим суперпользователя), на этом уровне разрешено все, пока приложения выполняются на самом низком уровне ( также называется режим пользователя), процессор регулирует прямой доступ к аппаратному обеспечению и несанкционированный доступ к памяти.

hardorsoft 23.10.10 в 11:59

Обычно мы обращаемся за выполнением режима как пользовательского пространства, так и пространства пользователя. Эти термины окружены не только различными привилегированными уровнями, свойственный двум режимам, но также факт то что каждый режим, также может иметь в распределении собственной памяти собственное пространство адресов

hardorsoft 23.10.10 в 22:44

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

hardorsoft 23.10.10 в 22:44

Роль модулей — расширение функциональности ядра, с модулированный код работающий в пространстве ядра. Обычно драйвер выполняет обе задачи определенные заранее: несколько функций в модуле выполнены как часть системных вызовов и некоторые заведуют управлением прерываний.

hardorsoft 23.10.10 в 22:44

2.3.2 Параллелизм ядра

hardorsoft 23.10.10 в 23:07

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

hardorsoft 23.10.10 в 23:07

Вот несколько источников параллелизма в программировании ядра. Конечно, система Линукс работает с многочисленными процессами, более чем одним которые могут попытаться использовать драйвер один момент времени. Большинство устройств допускают прерывание процессора, управление прерываниями запускается асинхронно и могут быть вызваны в тот момент когда драйвер пытается сделать что-то ещё. Несколько программных абстракций (такие как таймер ядра, о них мы поговорим в главе 7) также запускаются асинхронно. Кроме того, Линукс может запускаться на симметричных многопроцессорных системах (SMP), в результате драйвер может выполняться параллельно более чем на одном процессоре. И наконец, в код ядра версии 2.6 сделан вытесняемым, это изменение причина того что даже однапроцессорные системы имеют много таких же подходов параллелизма как и многопроцессорные системы.

hardorsoft 24.10.10 в 00:13

В результате, код ядра Линукс, включает код драйвера, должен быть входящим должен быть запустить больше чем один контекст в один момент. Структура данных должна быть внимательно спроектирована содержать в себе многочисленные самостоятельно отделяемые нити и код должен брать попечение о доступе к распределяемым данным в направлении котором предотвращается порча (искажение) данных. Написанный код который управляет параллелизмом и избегает условий гонки (??? race conditions) (ситуация в которой неудачный порядок выполнения причина неудобный режим работы) требующие размышлений и могут быть сложными. Правильное управление параллелизма требует писать корректный код ядра, по этой причине, каждый пример драйвера в этой книге был написан с учетом параллелизма. Используемые техники объясняются по мере приближения к ним; Глава 5 посвящена этому подходу и примитивы ядра доступны для управления параллелизма.

hardorsoft 24.10.10 в 00:14

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

hardorsoft 24.10.10 в 00:36

2.3.3. Текущий процесс

ximen 22.10.10 в 13:29

Хотя модули ядра не выполняются последовательно как приложения, большинство действий выполняемых ядром действуют от имени отдельного процесса. Код ядра может отправлять поток процесса допуская глобальный поток сообщений, определенный в файле current.h, который производит указатель на stuct (структуру) task_struct, определенную в файле sched.h. Указатель потока отправляет процессору что теперь идет выполнение. Во время выполнения системного вызова, такого как методы open и read, поток процесса то что инициировало вызов. Код ядра может использовать информация характерную для процесса используя поток, если ему это необходимо. Пример этой техники приводится в главе 6.

hardorsoft 24.10.10 в 05:47

На самом деле current не является по-настоящему глобальной переменной. Необходимость поддержки SMP заставила разработчиков ядра создать механизм, находящий текущий процесс на соответствующем процессоре. Этому механизму было также необходимо быть быстрым, поскольку ссылки на current возникают часто. В результате появился архитекурно-зависимый механизм, который обычно скрывает указатель на структуру task_struct в стеке ядра. Детали этой реализации остаются скрытыми даже от других подсистем ядра и в драйверы устройств можно просто включить sched.h> и ссылаться на текущий процесс. Например, следующий оператор выводит идентификатор и имя команды текущего процесса, беря их из соответствующих полей структуры task_struct:

allez 24.10.10 в 06:50

<code>printk(KERN_INFO "The process is \"%s\" (pid %i)\n", current->comm, current->pid);</code>

ximen 22.10.10 в 13:34

Имя команды, хранящееся в <code>current-&gt;comm</code>, представляет собой базовое имя файла программы (при необходимости урезанное до 15 символов), которая выполняется текущим процессом.

ximen 22.10.10 в 13:36

2.3.4 Ещё несколько подробностей

ximen 22.10.10 в 13:29

Программирование ядра во многом отличается от программирования в пространстве пользователя. Мы будем указывать на эти различия по мере того, как будем с ними встречаться, но есть несколько принципиальных вопросов, не требующих отдельного раздела, которые стоит упомянуть. По мере углубления в ядро, следующие моменты нужно иметь в виду.

ximen 25.10.10 в 05:52

Приложения полагаются на виртуальную память с очень большой областью для стека. Стек используется для хранения истории вызовов функций и всех автоматических переменных, созданных текущей функцией. У ядра же, наоборот, стек очень маленький и может иметь размер одной 4096-байтной страницы. Функции делят этот стек со всей цепочкой вызовов в пространстве ядра. Поэтому создание больших автоматических переменных является плохой идеей -- если вам нужны большие структуры, следует выделять для них память динамически во время вызова.

ximen 25.10.10 в 06:00

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

ximen 25.10.10 в 06:05

Код ядра не может выполнять операций с плавающей точкой. Для этого ядру было бы нужно сохранять и восстанавливать состояние математического со-процессора при каждом входе в пространство ядра и выходе из него, как минимум на некоторых архитектурах. С учётом того, что, на самом деле, в коде ядра нет необходимости в операциях с плавающей точкой, дополнительные накладные расходы не оправданы.

ximen 25.10.10 в 06:11