> обоих случаях udev должен подгрузить модуль

Откуда это? Модули подгружала devfs в свое время, udev же ничего не грузит, он просто дает имена существующим устройствам.

>udev должен подгрузить модуль - выполнить modprobe

только если это записано в правиле udev для конкретного специфичного устройства

А кто тогда загружает модули?

А кто тогда грузит модули? Devfs уже умерло, от hotplug тоже отказываются. Где-то нашел, что на основе vendor id, device id и других полей в /sys /.../somedevice/ генерится modalias, который и служит для поиска по базе модулей, но кто тогда модуль загружает? В /lib/modules/2.6.23.9-default/modules.alias лежит эта самая база, кто ее читает, если не modprobe?

Фраза "Automatic kernel module loading" из конфига ядра о чём-нибудь говорит? ;)

Говорит. И включена. Вот и хочу понять суть ее работы. Насколько я понял, она только uevent-ы рассылает, а сами модули грузит userspace-приложение, которое и слушает эти эвенты.

Ну не верю я в то, что kernel будет шарится по диску в поисках модулей...

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

"тесно работать" с ядром может любое user-space-приложение, чудес не бывает. Я хочу понять механизм работы, как они это делают. Что именно из modutils грузит модули? modprobe? А откуда ядро знает путь к нему? И зачем тогда uevents, когда все можно повесить на модпроб?

Еще момент: можно ли сделать так, что будет существовать /dev/sda1, но в памяти не будет модулей sata-дисков, что они подгрузятся только в момент обращения к нему? Например, при попытке монтирования? Ведь для определения существования диска уже нужен модуль...

> Если я правильно понимаю механизм udev, то: 1. При старте оно сканит весь /sys и выискивает все устройства 2. Потом вешается на сокет и ждет uevent

Если _я_ правильно понимаю работу udev, то оно при uevent смотрит, где именно в /sys живет новое устройство, берет оттуда атрибуты, и ищет соответствующие правила. То есть udev вступает в работу только после загрузки (и даже успешной инициализации) драйвера.

> можно ли сделать так, что будет существовать /dev/sda1, но в памяти не будет модулей sata-дисков, что они подгрузятся только в момент обращения к нему? Например, при попытке монтирования?

AFAIK, да. man modprobe.conf, ls /etc/modprobe.d

> Ведь для определения существования диска уже нужен модуль...

Смотря что понимать под "определением существования".

> Ну не верю я в то, что kernel будет шарится по диску в поисках модулей...

Этим занимается программа, прописанная в /proc/sys/kernel/modprobe

> То есть udev вступает в работу только после загрузки (и даже успешной инициализации) драйвера.

Но в /sys есть записи для тех устройств, модулей которых нет. И не просто не загружены, а вообще не скомпилированы (оно конечно не работает, но вендорИД / девайсИД / модАлиас есть). Т.е. 2 состояния - с драйвером и без.

> AFAIK, да. man modprobe.conf

В какую сторону смотреть:
alias wildcard modulename
options modulename option...
install modulename command...
remove modulename command...
include filename
blacklist modulename
?
А то нашел решение через tmpfs и обработку несуществующих файлов... Это как-то странно...

> Смотря что понимать под "определением существования".

Ну, как минимум надо узнать размер устройства. А его не считать, пока нет драйвера. Причем загрузив драйвер можно узнать о наличии /dev/sda, а ведь еще надо распарсить таблицу разделов, а это опять модули.

> Этим занимается программа, прописанная в /proc/sys/kernel/modprobe

Так просто? А в качестве опций дает ему modalias? И udev не нужен (если файлы устройств можно через mknode создать статично)?

> в /sys есть записи для тех устройств, модулей которых нет. И не просто не загружены, а вообще не скомпилированы

Примеры?

> В какую сторону смотреть:

У меня в FC4 есть файл /etc/modprobe.d/modprobe.conf.dist. Если у тебя такое есть, загляни туда.

>> Этим занимается программа, прописанная в /proc/sys/kernel/modprobe

> Так просто?

Да

> А в качестве опций дает ему modalias?

Не совсем понял. Если ты о директиве alias из modprobe.conf, то она для перевода имени некого абстрактного модуля, который запрашивает ядро, в имя файла *.ko, который и загружается в ответ на этот запрос.

> И udev не нужен (если файлы устройств можно через mknode создать статично)?

Да. udev - это система присвоения имен устройствам.

> Примеры?

Например, у меня есть тюнер, lspci говорит:
01:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01)

Ядро у меня 2.6.13 (SuSE 10.0), поддержка чипа 7134 была добавлена позже. Соответственно, тюнер не работает. Но в /sys/bus/pci/devices/0000:00:08.0/0000:01:09.0 лежат:

/..
│~bus
│/power
│ class
│ config
│ device - идентификатор девайса
│ irq
│ local_cpus
│ modalias - модалиас, который скорее всего и скармливается modprobe
│ resource
│ resource0
│ subsystem_device
│ subsystem_vendor
│ vendor - идентификатор вендора

А если взять, например, usb контроллер, то:

/..
│~bus
│~driver - драйвер загружен!!! Внутри может быть dev с номерами major/minor
│/power
│/usb1
│ class
│ config
│ device
│ irq
│ local_cpus
│ modalias
│ pools
│ resource
│ resource0
│ subsystem_device
│ subsystem_vendor
│ vendor


> меня в FC4 есть файл /etc/modprobe.d/modprobe.conf.dist. Если у тебя такое есть, загляни туда.

В SuSE10.0 такого нет, а файлы-конфигураций выглядят так:

blacklist prism2_cs
blacklist prism2_pci
alias pci:v000010B7d00007770sv*sd*bc*sc*i* hostap_plx
alias pci:v0000111Ad00001023sv*sd*bc*sc*i* hostap_plx
alias pci:v00001260d00003872sv*sd*bc*sc*i* hostap_pci

Все вышеуказанные команды. Какой рулить?

>> Так просто?
>Да

Ты спас мой мозг от рекурсии =)
Завтра попробую. Пойду спать со спокойной душой :)

> Не совсем понял. Если ты о директиве alias из modprobe.conf

Нет, о файлике modalias, что в /sys обитает. Например, для моего тюнера это:
pci:v00004444d00000016sv000012ABsd00000600bc04sc00i00
Если ядро стартует тупо аналог:
`cat /proc/sys/kernel/modprobe` `cat/sys/bus/pci/devices/0000:00:08.0/0000:01:09.0/modalias`

То все становится на свои места. Так?

> Например, у меня есть тюнер, lspci говорит:

Это идентификаторы устройства прямиком с шины PCI, для их получения вообще не нужны никакие модули, кроме поддержки PCI в ядре.

> Какой рулить?

А куда тебе нужно попасть? 8)

>`cat /proc/sys/kernel/modprobe` `cat/sys/bus/pci/devices/0000:00:08.0/0000:01:09.0/modalias`

> То все становится на свои места. Так?

По работе не сталкивался с этим, но могу потеоретизировать 8) грузить драйверы по идентификаторам устройств - выглядит вполне логично на первый взгляд, но остается небольшой вопрос: в ответ на какой запрос пользовательской программы система грузит эти драйверы? В случае с /dev/hda - при запросе на открытие устройства major 3, minor 0; а в ответ на что грузится драйвер твоего тюнера? Надо перечитать LDD3 8)

> для их получения вообще не нужны никакие модули, кроме поддержки PCI в ядре

Это понятно, просто как факт того, что устройства в /sys рождаются еще _до_ загрузки модуля ;) Это и вгоняло меня в рекурсию :)


> А куда тебе нужно попасть? 8)

Я же говорил - дабы в памяти не висело, но было доступно при первом обращении. Через ненайденные файлы tmpfs - как-то извращенно. А держать все в памяти - дорого (ибо девайсов бывает много). Или не заморачиваться и написать на сплеше "минимум 500мб оперативки"? (в итоге должен быть livecd)


> а в ответ на что грузится драйвер твоего тюнера?

Логично, что на открытие /dev/video0, который создаст udev, который прочитает файл dev в /sys после загрузки модуля. Например, в /sys/block/hda/dev лежит 3:0, наверное, после загрузки модуля будет соответсвующий файлик и в директории тюнера. Я надеюсь.

7.4.2.4. Module Loading

Device drivers compiled as modules may have aliases built into them. Aliases are visible in the output of the modinfo program and are usually related to the bus-specific identifiers of devices supported by a module. For example, the snd-fm801 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, and has an alias of “pci:v00001319d00000801sv*sd*bc04sc01i*”. For most devices, the bus driver exports the alias of the driver that would handle the device via sysfs. E.g., the /sys/bus/pci/devices/0000:00:0d.0/modalias file might contain the string “pci:v00001319d00000801sv00001319sd00001319bc04sc01i00”. The rules that LFS installs will cause udevd to call out to /sbin/modprobe with the contents of the MODALIAS uevent environment variable (that should be the same as the contents of the modalias file in sysfs), thus loading all modules whose aliases match this string after wildcard expansion.

In this example, this means that, in addition to snd-fm801, the obsolete (and unwanted) forte driver will be loaded if it is available. See below for ways in which the loading of unwanted drivers can be prevented.

The kernel itself is also able to load modules for network protocols, filesystems and NLS support on demand.