В каких случаях приходится писать модули ядра?

• Тебе надо предоставить доступ к девайсу через какой-нибудь стандартный интерфейс, чтобы стороннее ПО могло с ним работать (например, если девайс - камера/TV-тюнер, то ты пишешь v4l2-модуль ядра, чтобы всякими там mplayer/vlc видео смотреть можно было)
• Очень важна скорость и лишних переключений между user-space/kernel-space избежать надо

на переключения между space-ами сколько тактов тратится?

<модули не нужны, есть libusb>

ultraslim-взгляд на мир. а, там, сетевые пакеты быстро фильтровать тебе не надо? работать с ФС не отапливая комнату?

То же касается любой другой шины.

ох лол, с «любой другой шиной» тоже ни разу не все гладко — произвольный bit-banging ты тоже из userspace будешь делать?

десятки микросекунд

Понятия не имею, сколько именно тактов (тактов чего? Процессора? А какого именно? Или тактов внутреннего таймера? Непонятно, что ты спросить хотел) Но переключение контекста дорогое, да. Ну и плюс USB тут исключение, наверное - для всяких там PCI/VME библиотечки никакой нету, и надо в кернелспейсе кодить, да.

Да и про USB - вот есть у меня Ethernet-адаптер, который по USB подключается. Я, конечно, могу через libusb с ним в юзерспейсе работать, но мне все-таки стандартный ethN-интерфейс нужен, чтобы я по назначению девайс использовать мог, а тут без написание драйвера никуда.

Тоже самое для клавиатур/джойстиков - если я в userspace через libusb с ними работать буду, то я только из своего ПО с ними работать смогу, а из иксов/консольки - фиг вам - тут опять-таки /dev/input/xy нужен, опять пилим драйвер для ядра.

Я вообще только два преимущества userspace-«драйверов» вижу:

• Если драйвер покрашится - покрашится только драйвер и ПО, а баг в модуле ядра может за собой все ядро в Вальхаллу унести.
• Легкость отладки - ядренный модуль ты просто так не отладишь уже - нужна будет отдельная машинка и включенный в ядро kgdb.

десятки микросекунд

Неправда же.

стандартный интерфейс

юзерспейсную (preload) обёртку написать, драйвер не нужен

тут опять-таки /dev/input/xy

конкретно ввод из юзерспейса можно делать через uinput.

ultraslim-взгляд на мир. а, там, сетевые пакеты быстро фильтровать тебе не надо? работать с ФС не отапливая комнату?

Тут нужно отличать необходимое условие от достаточного:

Когда необходимо работать в kernel-space, а когда достаточно user-space?

В принципе, вы ответили на этот вопрос, но всевозможные драйвера различных ФС и сетевые протокола уже есть в ядре. И я как-то не страдаю синдромом «фатального недостатка», чтобы их переписывать.=)

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

Как бы да - ты же не хочешь при смене web-камеры/TV-тюнера, например, с VLC на какую-то самописную фигню переходить, из-за того, что для нее драйверов нету, и вся работа через libusb идет?

Троллейбус_из_буханки.jpg Можно то оно можно, только зачем?

Я так в теории и в v4l2-устройство могу из юзерспейса пакетиками срать, так, что тот-же vlc с этим работать сможет, только зачем этот костыль? ИМХО, тут легче драйвер написать, чем костыли городить. Из юзерспейса с девайами лучше тогда работать, когда ты точно знаешь, что никто, кроме твоего приложения, этим пользоваться не будет. Тогда да - можно и через libusb все делать. Или всякие девайсы, которые AT-командами через COM управляются - тут тоже из юзерспейса сподручнее работать.

А вызывать геморрой с пересборкой внешнего модуля при обновлении ядра и переписыванием его при изменении api ядра как у вас называется?

Он гонит какой-то тупак, для стандартного api делают библиотеку.

А вызывать геморрой с пересборкой внешнего модуля при обновлении ядра

google://DKMS, все пересобирается автоматически, если пользователь не буратино-слакварщик, который все «нинужное» выкинул, и ручками-ручками все делает.

Ну давай уж, покажи мне библиотеку, которая заместо v4l2 юзаться может, и для которой ни одно строчки в ядре писать не нужно. Или библиотечку для работы с PCI/VME-девайсами. И заодно библиотечку, которая мне предоставит возможность работать с 3G-USB-модемами, безо всяких там /dev/ttyUSBX. В смысле, чтобы сама библиотечка никакой /dev/ttyUSBX не юзала, а напрямую через libusb. И чтобы у меня NetworkManager с ней работал и любой другой рандумный софт.

А не дохрена ли ты захотел? Вполне очевидно, что если для работы с девайсом достаточно доступного из юзерспейса, можно написать библиотеку с api, аналогичным v4l2/whatever. Просто для совместимости с api модулей не нужно.

А как прогу из userspace научить загружать драйвера самой? Через вызов modprobe из обращения к шеллу? Есть менее костыльный способ?

загрузка модуля требует права CAP_SYS_MODULE, и его наличие — дыра в безопасности

Когда необходимо работать в kernel-space, а когда достаточно user-space?

Пишешь на коленке прототип, доводишь до ума, пускаешь в продакшен и всасываешь по трупуту — вот примерно тогда и пора.

трупуту?

https://en.wikipedia.org/wiki/Throughput

Драйверы устройств.

буду рад услышать правильный ответ

но всевозможные драйвера различных ФС и сетевые протокола уже есть в ядре.

ну так можно и про USB-устройства сказать, че уж.

и я имел ввиду не сетевые протоколы, а модули netfilter.

Э, там много работы ещё. Сколько у меня клав не было с дополнительными клавишами, везде находилась хоть одна, которую Linux никак не видел, ни через xev, никак в общем.

а тут без написание драйвера никуда.

Извращений ради ты можешь создать tap-интерфейс и через него действовать уже в user-space)

А вот с другими устройствами уже гемор

Откуда ты такие проблемы-то надумал?

буду рад услышать правильный ответ

Правильного ответа нет. Но можно произвести замеры. На моей системе пустой read() выполняется ≈0,2 мкс.

например если ты по (некоей)шине пристегнул блочное/сетевое устройство и хочешь из него выжать всё на что оно способно. Всякие vfs/dummy дают возможности, но недают скорость и плюшастые фичи :-)

библиотечку для работы с PCI/VME-девайсами

drivers/uio/uio_pci_generic.c

drivers/staging/vme/devices/vme_user.c

Делаешь open, а затем mmap. Библиотечку пиши сам.

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

Правильного ответа нет.
На моей системе пустой read() выполняется ≈0,2 мкс.

Понятно, чт может быть и больше, но все же стоит сделать вывод, что я наврал.

например, если поверх твоего драйвера работают другие драйвера.

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