@Vorb18 апр 2011 в 18:45

Работаем с модулями ядра в Linux

7 мин

279K

*nix *

+106

Комментарии 51

@Lerg 18 апр 2011 в 19:03

Очень хорошо изложено. На мой взгляд ещё стоит добавить про modprobe.d/*.conf — автоматическое конфигурирование модулей при загрузке. Полезно в частности для видео устройств.

@Vorb 18 апр 2011 в 19:18

Спасибо, добавил!

@Andrewww 18 апр 2011 в 19:25

Большое спасибо, очень доступный и информативный материал, однозначно в избранное.
Некоторые подробности загрузки/выгрузки стали более ясны и прозрачны

@SergMarkov 18 апр 2011 в 19:49

Хорошо изложено, спасибо.

@googol 18 апр 2011 в 21:19

Пользуясь случаем хочу порекомендовать две просто великолепные книги по ядру Linux
— The Linux Programming Interface by Michael Kerrisk
— Linux Kernel Development by Robert Love

@Vorb 18 апр 2011 в 21:22

О да! По Роберту Лаву я учился писать модули ядра. Автор не только рассказывает как писать модули, но и передает некую философию, руководствуясь которой можно избежать многих ошибок проектирования и правильно программировать в условиях пространства ядра.

@p_a 18 апр 2011 в 21:53

В этот же список можно добавить
Understanding the Linux Kernel by Daniel P. Bovet (Author) & Marco Cesati (Author)

@Evengard 18 апр 2011 в 21:58

Интересно было бы узнать ппро конфигурирование udev — например, загрузка своего модуля при появлении устройства с особыми свойствами.

@davinchi 18 апр 2011 в 22:06

$ man udev

@Evengard 21 апр 2011 в 17:43

Ну извините конечно, но по этой статье можно с таким же успехом дать ссылку на man modprobe, man insmod, man lsmod, man rmmod, man modinfo и man modprobe.conf

@davinchi 18 апр 2011 в 22:02

> В Linux ядро монолитное, т.е. все его драйвера и подсистемы работают в своем адресном пространстве, отделенном от пользовательского.

Монолитное — значит что ядро не поделено на части, а не то что вы тут написали. Монолитное ядро противопоставляется микроядерным — Minix и HURD, где каждый отдельный сервис — это отдельный процесс а «истинное» микроядро лишь занимается обменом между информации между ними.

> rmmod
rmmod -> modprobe -r

> Эти зависимости просчитываются автоматически, и будут описаны ниже.

Я не совсем понял, что здесь значил слово «автоматически»?

@Vorb 19 апр 2011 в 06:04

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

@muromec 19 апр 2011 в 08:57

Это не один процесс, это одно адресное пространство. Процессов много, но память общая и все могут друг-друга уронить или иметь общие данные без копирования.

@Xarakternik 18 апр 2011 в 22:27

Скрипты загрузки и выгрузки модулей, это, пока, единственный способ бороться с отваливанием вай-фая после суспенда или хибернейта. За статью спасибо, ее бы месяц назад.

зы. Регулярка find /lib/modules/`uname -r` -name ‘*.ko’ почему-то не срабатывает на убунту 10.10.

@googol 18 апр 2011 в 23:08

Подозреваю, что не работает из-за кавычек (хабр их заменяет на свои). Попробуйте использовать символ ' вокруг *.ko

@Xarakternik 19 апр 2011 в 06:00

подставлял свои — не срабатывает

@Vorb 19 апр 2011 в 06:07

uname -r — это подстановка. Пишется в кавычках, которые находятся на русской букве «ё». А '*.ko' пишется в обычных одинарных кавычках. Подстановку можно, кстати, написать по другому:
find /lib/modules/$(uname -r) -name '*.ko'

@muromec 19 апр 2011 в 08:55

а еще бывает .ko.gz

>filename: /lib/modules/2.6.38-ARCH/kernel/drivers/net/wireless/rt2x00/rt73usb.ko.gz

@muromec 19 апр 2011 в 06:56

>Необходимость в файле микропрограммы появилась в связи с тем, что интерфейс взаимодействия с устройством закрыт, и эти функции возложены на файл прошивки (firmware).

разве фирмварь не грузится в само устройство, а не драйвер?

@Vorb 19 апр 2011 в 08:29

В этом случае нет. Судя по документации, этот файл грузится непосредственно в память ядра.

@merlin-vrn 19 апр 2011 в 11:49

Вот вообще тему фирмвари бы поподробнее раскрыть -_-

@muromec 19 апр 2011 в 14:00

обычно фирмваря — бинарный блоб, который драйвер читает из /lib/firmware/ и заливает в сустройство.

в этом конкретном — надо смотреть сорц. как-то странно было бы держать в памяти ядро непонятно что и не тэйнтить его, как в случае с проприетарными драйверами.

@greynix 19 апр 2011 в 07:52

Большое спасибо за статью. Интересует такой вопрос — Есть ли смысл вкомпиливать модули в ядро, интересно узнать в каких случаях это может потребоваться и будет ли влиять на производительность или надежность?

@kovyrlo 19 апр 2011 в 08:08

Чем больше вкомпилено в ядро, тем ядро медленнее загружается (может и работает), но так безопаснее — вам не надо думать о том, что какой-то модуль мог не подгрузится, когда он нужен.
А если выбрать модульную структуру, то все наоборот)

@muromec 19 апр 2011 в 08:39

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

@Vorb 19 апр 2011 в 08:38

Бывают ситуации, когда все нужные модули вкомпилируются в ядро и функция подгрузки модулей отключается. Это делают на тех системах, на которых не будут менять ни конфигурацию оборудования, ни файловые системы. Создается что-то типа бастиона, невозможно ничего не загрузить, ни выгрузить. Согласно этой политике повышается безопасность, т.к. невозможно загрузить какой либо вредоносный код в ядро. Но я с таким встречался только один раз, когда знакомый админ таким образом настроил внутренний шлюз. Он работал отлично, маршрутизировал довольно много трафика и держал аптаймы до нескольких лет. Но когда на маме сдохли конденсаторы и пришлось ее заменить — пришлось пересобирать ядро, т.к. таких матерей уже в продаже давно нет.
Смысл вкомпилировать только некоторые модули есть тогда, когда вы уверены, что это оборудование или файловая система будет у вас всегда, но опять же прироста в производительности это не даст. Я так поступаю чисто для удобства на домашней системе: вкомпилирую модули поддержки корневой файловой системы и контроллера жесткого диска в ядро, чтобы не использовать initrd. Других преимуществ я не вижу. Может быть кто нибудь еще просветит.

@muromec 19 апр 2011 в 08:40

>Согласно этой политике повышается безопасность, т.к. невозможно загрузить какой либо вредоносный код в ядро

Глупости и наивняк. Если рут уже получен, то в ядро можно насрать и без красивой подгрузки модуля.

@Vorb 19 апр 2011 в 08:46

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

@muromec 19 апр 2011 в 08:52

«незаметная» резидентная гадость, которую видно в списке модулей — это как-то глупо.

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

@Vorb 19 апр 2011 в 08:56

Ну никто же не назовет модуль «resident evil»? ) Он заныкается и попробуй его найти.
А по поводу руткитов да… надо почитать.

@muromec 19 апр 2011 в 08:53

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

@greynix 19 апр 2011 в 08:54

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

@muromec 19 апр 2011 в 09:00

>Сомневаюсь что такая ситуация может часто встречаться, тем более что модули часто зависят от версии ядра.

На девелоперской машине такое бывает по несколько раз на день.

В дистрибутивах конечно после одного патча чего угодно будет выпущен новый пакет с новыми версиями.

>модули часто зависят от версии ядра.

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

Поле vermagic в том же modinfo.

@muromec 19 апр 2011 в 08:50

Если вкомпилить в ядро модули, нужные для монтирования рутфс, то можно выкинуть initrd/initramfs и сэкономить несколько секунд на загрузке.

Я так на нетбуке делаю.

После загрузки уже неважно, что откуда взялось.

@muromec 19 апр 2011 в 08:36

>Для автоматической загрузки модулей в разных дистрибутивах предусмотрены разные механизмы.

Это какие еще? Механизм один — ядро пинает юзерспейсу id устройства, modprobe по табличке алиасов находит нужный модуль. Все.

В том же выхлопе modinfo rt73usb табличка есть.

@Vorb 19 апр 2011 в 08:42

Я немного некорректно выразился, имел ввиду автозагрузку модуля при запуске системы. Например, чтобы грузится cryptoloop и blowfish на домашней генту я прописываю их в /etc/modules.autoload.d/kernel-2.6, а в тех же redhat системах механизм другой. Я подправлю вечером, спасибо.

@Sergey78 19 апр 2011 в 11:20

А как ядро определяет, для какого устройства какой модуль грузить?
Есть устройство которое работает через COM-USB переходник (он внутри устройства стоит). Случайным образом при загрузке системы для устройства может быть загружен модуль pl2303 и соответственно оно станет /dev/ttyUSB*, а может загрузиться cdc_acm и оно станет /dev/ttyACM*

Внести один из этих модулей в blacklist я не могу, т.к. есть другие устройства, которые их используют. Как заставить ядро для USB устройства с конкретным ID грузить конкретный драйвер?

@muromec 19 апр 2011 в 11:46

>как ядро определяет, для какого устройства какой модуль грузить?

habrahabr.ru/blogs/linux/112527/

>Случайным образом при загрузке системы

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

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

еще можно разрулить на уровне имени устройства, написав хитрое правило udev.

@WiseLord 19 апр 2011 в 18:40

lsmod покажет список загруженных модулей, modinfo — возможные опции загрузки конкретного модуля.

А вот есть ли способ узнать, с какими опциями загружен модуль? Это, пожалуй, даже чаще востребовано, чем modinfo, особенно с ноутбуками с snd-hda-intel с их вечными проблемами с входом для наушников.

А также интересно, можно ли «на лету» изменить параметры загрузки модуля без его выгрузки (иногда зависимости не дают выгрузить) и повторной загрузки.

Если эти два вопроса имеют решение, хорошо было бы его увидеть в самой статье для полноты картины — к остальному содержимому претензий нет.

@Vorb 19 апр 2011 в 19:04

Довольно интересные вопросы… так чтобы списком получать я даже не знаю. Можно проверять значение параметра через файловую систему /sys: в каталоге "/sys/modules/<module_name>/parameters" сидят файлы, названные по имени параметра, данные в них — значения параметра.
А по поводу изменения параметров на лету никогда не сталкивался с проблемой, но поищу информацию. Спасибо за интересные вопросы.

@Narical 21 апр 2011 в 13:32

echo $VALUE >/sys/modules/<module_name>/parameters/$PARAMETER не проканает?

@Vorb 21 апр 2011 в 17:11

Не, уже попробовал) Permission Denied говорит…

@Narical 20 апр 2011 в 18:18

Я всегда считал что некоторые вещи очень желательно делать модульными при сборке ядра, например — модуль wifi-карты и bluetooth. Все ради того, чтобы выгружать модуль ненужного в данный момент устройства и, типа, экономить электричество. Раскройте же глаза на правду, о линукс-гуру!)