Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Программирование под Unix/Linux > Модуль ядра для USB


Автор: DrHex 27.10.2009, 16:24
Написал драйвер для Windows для работы с USB устройством, теперь будет портация на Linux.
Где и что можно почитать(посмотреть исходинки) для создание модуля ядра???

Очень интересует AIO операции для обращания к модулю ядра. Так же резистрация и поиск устройств(inf файлы для windows а как для Linux???) 

Переход в режим сна.....

Автор: niXman 27.10.2009, 20:41
Цитата(DrHex @  27.10.2009,  14:24 Найти цитируемый пост)
(inf файлы для windows а как для Linux???)

Где-то в /etc положи файл конфигурации.
Цитата(DrHex @  27.10.2009,  14:24 Найти цитируемый пост)
Где и что можно почитать(посмотреть исходинки) для создание модуля ядра???

http://www.google.ru/#hl=ru&source=hp&q=linux+kernel+module+programming+guide&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=&aq=1&oq=linux+kernel+module&fp=be4313e544833b95

Автор: MAKCim 27.10.2009, 21:40
DrHex
1. почитать http://lwn.net/Kernel/LDD3/
2. что касается регистрации устройств
в linux реестра в принципе нет, поэтому нигде в общем то регистрировать ничего не надо
модули могут загружаться вручную (через insmod/modprobe), ядром (тогда через MODULE_ALIAS должен быть определен псевдоним модуля, используюший некоторые уникальные атрибуты типа minor/major номера регистрируемого в нем устройства)
после компиляции модуля стОит выполнить depmod для создания дерева зависимостей, чтобы при загрузке модуля через modpobe последний выполнил загрузку всех модулей, от которых зависит загружаемый
3. теперь по операциям ввода-вывода
обычно взаимодействие user <-> kernel происходит посредством /proc файлов, устройств в /dev и объектов kobject в /sys
при регистрации устройства в /dev, создании файла в /proc или kobject'а в /sys с их inode'ами связываются файловые операции-обработчики, которые вызываются при выполнении операций ввода-вывода с соответствующими файловыми дескриптором
мы устанавливаем эти обработчики и тем самым реализуем нужное поведение

Автор: niXman 27.10.2009, 22:40
Цитата(MAKCim @  27.10.2009,  19:40 Найти цитируемый пост)
3. теперь по операциям ввода-вывода
обычно взаимодействие user <-> kernel происходит посредством /proc файлов, устройств в /dev и объектов kobject в /sys
при регистрации устройства в /dev, создании файла в /proc или kobject'а в /sys с их inode'ами связываются файловые операции-обработчики, которые вызываются при выполнении операций ввода-вывода с соответствующими файловыми дескриптором
мы устанавливаем эти обработчики и тем самым реализуем нужное поведение 

Огого smile 
Это стандартный принцип?

Автор: MAKCim 27.10.2009, 23:29
рекомендуемый
примеры: /dev/ppp, /dev/net/tun, /dev/kvm

Автор: niXman 28.10.2009, 00:37
MAKCim, Так а если мне просто нужно чтоб моя программа могла общаться с неким USB девайсом, я же просто могу написать модуль ядра, или использовать libusb.

Выше, то все относится к "настоящему" драйверу?

Автор: DrHex 28.10.2009, 11:58
MAKCim  спасибо за регистрацию модуля...

Вот только вопрос как сделать асинхронный ioctl на модуль ядра?? (в идеале кросс платформленый может boost(write/read точно есть))

В винде я делал DeviceIoControl(SomeParam, SomeParam, SomeParam, SomeParam, SomeParam, SomeParam, SomeParam , Ovellaped)

А вот в Ovellaped хранился callback как это сделатль в Линуксе???(Или такого в Линуксе нет??? Я не знаток в *nix, но хоть использую это слово...)

Автор: MAKCim 28.10.2009, 12:05
DrHex
тебе грубо говоря нельзя блокироваться на ioctl()?
тогда тупо сделай очередь в девайсе, куда через ioctl() будут класться сообщения
создай процесс ядра, который будет при наличии необработанных сообщений в очереди их обрабатывать
т. е. алгоритм такой: юзер вызывает ioctl(), данные помещаются в очередь, осуществляется вызов try_to_wake_up() для процесса ядра

Добавлено через 5 минут и 36 секунд
niXman
libusb работает с файлами устройств /dev/usbdev*
грубо говоря когда устройство подключается к USB шине, для него ищется драйвер
драйвер проводит инициализацию устройства и его регистрацию в иерархии объектов kobject ядра
при регистрации генерируется KOBJECT_ADD событие и соответствующее ему сообщение с описаним общих и специфичных параметров регистрируемого устройства
демон udev через netlink сокет получает пакет с этим сообщением и через вызов mknod() создает файл устройства в /dev
(major и minor номера беоет из данных полученного пакета)
libusb находит нужное устройство в /dev и через обычные файловые операции ioctl()/read()/write()/... работает с ним

Автор: niXman 28.10.2009, 12:14
MAKCim, Понял. Спасибо.

Автор: DrHex 28.10.2009, 12:27
Цитата

тебе грубо говоря нельзя блокироваться на ioctl()?
тогда тупо сделай очередь в девайсе, куда через ioctl() будут класться сообщения
создай процесс ядра, который будет при наличии необработанных сообщений в очереди их обрабатывать
т. е. алгоритм такой: юзер вызывает ioctl(), данные помещаются в очередь, осуществляется вызов try_to_wake_up() для процесса ядра

Идея такая была вот только обращений в 100 милисекунд может быть 1000(В винде добился в 15 милисекунд 1000 запросов).... и конец асинхронных ответов (1000 ответов) около 63 милисекунд. Но вот когда була очередь то скорость отправки и приема (асинхронного конечно)
выходила около 250 милисек.(Начальника ругаться начинал.... )) )


Цитата

libusb работает с файлами устройств /dev/usbdev*
грубо говоря когда устройство подключается к USB шине, для него ищется драйвер
драйвер проводит инициализацию устройства и его регистрацию в иерархии объектов kobject ядра
при регистрации генерируется KOBJECT_ADD событие и соответствующее ему сообщение с описаним общих и специфичных параметров регистрируемого устройства
демон udev через netlink сокет получает пакет с этим сообщением и через вызов mknod() создает файл устройства в /dev
(major и minor номера беоет из данных полученного пакета)
libusb находит нужное устройство в /dev и через обычные файловые операции ioctl()/read()/write()/... работает с ним 

А извезщению модулю приходят?? Если да то какие???

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)