LINUX.ORG.RU

usb_register_dev, владелец и права на создаваемый в /dev файл


0

0

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

Проблема состоит в следующем: модуль одного устройства (ПЗС-камеры) при подключении этого устройства создает в директории /dev/ соответствующий файл (fliusbX). Однако, права на этот файл - 0660, а uid и gid - root.

В старых версиях ядра в структуре usb_class_driver было поле mode, в котором задавался режим доступа к файлу. Сейчас такого нет.

Вопрос: как мне задать, скажем, режим доступа 0666 к создаваемому файлу устройства, или (что еще лучше) - задать uid файла на, скажем, video.

☆☆☆☆☆

Правила udev покатят?

nnz ★★★★
()

udev же

> как мне задать, скажем, режим доступа 0666 к создаваемому файлу устройства

KERNEL=="fliusb*", MODE="0666"

> или (что еще лучше) - задать uid файла на, скажем, video.

KERNEL=="fliusb*", GROUP="video"
arsi ★★★★★
()
Ответ на: udev же от arsi

Про udev я слышал, но это, по-моему, уж совсем чересчур. По-другому точно нельзя (по-человечески, через сам модуль ядра - ведь он же файл создает)? Или я чего-то не понимаю?

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от arsi

Не так страшен черт, как его малютки

Спасибо! Разобрался. Когда udev'а не было, было поле прав доступа для создаваемого файла. Сейчас они заменяются правилами udev'а.

Создал правило /etc/udev/rules.d/99-fliusb.rules с всего одной строкой

KERNEL=="fliusb*", GROUP="video"
и заработало!

Теперь вопрос чуть в сторону: можно ли добавить ioctl, который будет включать фоновый мониторинг устройства (нужно следить, чтобы оно не перегрелось) или же проще написать отдельный демон и повесить его на RUN в udev?

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: Не так страшен черт, как его малютки от Eddy_Em

> Теперь вопрос чуть в сторону: можно ли добавить ioctl, который будет включать фоновый мониторинг устройства (нужно следить, чтобы оно не перегрелось) или же проще написать отдельный демон и повесить его на RUN в udev?

в каком смысле «добавить ioctl»? добавить в драйвер или в правила udev? если он уже есть в драйвере и просто включает фоновый мониторинг, который будет осуществляться драйвером или устройством, то можно написать маленькую программу на си, которая будет устанавливать необходимый режим при добавлении устройства. если же необходимо через ioctl периодически узнавать состояние и мониторить демоном, то без последнего тут уже не обойтись…

KERNEL=="fliusb*", ACTION=="add", RUN+="/usr/local/bin/my_daemon --start %k"
KERNEL=="fliusb*", ACTION=="remove", RUN+="/usr/local/bin/my_daemon --stop %k"
arsi ★★★★★
()
Ответ на: комментарий от arsi

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

Добавить хочу в сам модуль.

Просто на данный момент весь модуль состоит из 8 сотен строк, и весь его функционал - зарегистрировать устройство, выделить буфер в памяти ядра и определить несколько простых функций ввода-вывода (всем остальным занимается уже библиотека для работы с этим устройством).

В общем, думаю, все-таки проще всего будет реализовать наблюдение через демон.

Eddy_Em ☆☆☆☆☆
() автор топика

Что бы почитать

по поводу написания модулей ядра для работы с USB-устройствами?

Нашел только это, но как-то маловато, поверхностно... Да и «Kernel module programming guide» всего на 82-х страницах.

А нет ли какого-нибудь K&R в мире разработки модулей ядра? Чтобы подробно, разжевано и без «для примеров см. исходники модулей ядра»?

// не хотелось из-за такого пустяка отдельную тему создавать

Eddy_Em ☆☆☆☆☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.