Перенос Win WDM драйвера на Linux…

[sabbatazh]

Здравствуйте Уважаемые Знатоки!
Кто-то занимался безболезненным переносом драйвера из  под Win на Linux???
Я просто не знаю с чего начать … как осуществить поставленную задачу? С чего начать, только путного?!
Есть драйвер WDM PCI, соответственно под Win… как его перекрутить под Linux???
Спасибо!

[Ochkarik]

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

все что я слышал о линуксе, это то что там вроде для обмена есть ioctl и read|write. мельком читал какую то статью по написанию драйвера под линукс, но задача отпала, чему я был несказанно рад, честно говоря.
думаю основная проблема будет не в поиске "аналогов" функций win (там они все должны быть) а в попытке разделить код драйвера на OC-зависимую часть, и независимую. в идеале - первого должно быть мало, а второго - много)

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

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

[RXL]

Все, что могу предложить: почитать Linux Device Drivers.

read, write, ioctl - эти системные вызовы применимы только к файлам, но не к самим драйверам. Например, драйвер регистрирует в системе файл устройства - есть такая категория файлов в среде Unix вообще, не только Linux. Они идентифицируются тремя компонентами: числами uint8 - major и minor, и типом (символьное или блочное устройство). Через такой файл можно общаться с драйвером через стандартные системные вызовы, применимые к файлам. Специфичное общение организуют через ioctl.

Есть и другие механизмы общения с драйверами из user space. Например, создание файлов в "/proc" (procfs).

Ochkarik, права на файл разве имеют отношение к драйверу? Это уровень файловой системы.


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

[sabbatazh]

Ochkarik, RXL, Спосибо!
Вот теперь как у разбитого корыта… читало про создание файлов в "/proc" и обмен данными через них… а разобрался с ioctl по винду… и то не полностью… и драйвер под винду использует технологию обмена ioctl…

[Ochkarik]

RXL, ну.. в винде когда создается объект устройства... доступ к нему из User - теми же API функциями что и к фалу: Create/Read/Write. и для специфических операций - IOCTL) и для взаимодействия между драйверами - Internal IOCTL.
но чтобы приложение могло обращаться к созданному объекту через IOCTL - ему повыше права нужны.
в драйвер эти запросы доходят в виде IRP с разными IRP_MJ_XXX кодами.
насколько я понимаю в Linux - идея та же?

[RXL]

В Линуксе разделение прав I/O и ioctl не делается. Файл открыть удалось - значит удастся выполнить и другие операции на этом дескрипторе. Правда, есть такая супернавороченная штука - SELinux: управление доступом вплоть до системного вызова, номера TCP порта или конкретной операции на конкретном файле, но этим пользоваться очень сложно и зачастую SElinux административно отключают.

[darkelf]

в драйвер эти запросы доходят в виде IRP с разными IRP_MJ_XXX кодами.
насколько я понимаю в Linux - идея та же?

В Linux нет IRP, просто можно зарегистрировать свой обработчик ioctl(), и если будет вызван системный вызов ioctl() с дескриптором файла, относящегося к драйверу - будет вызвана функция этого драйвера. Аналогично и другие функции.

[Ochkarik]

я имел в виду не IRP а набор функций для общения с драйвером со стороны приложения)

[darkelf]

я имел в виду не IRP а набор функций для общения с драйвером со стороны приложения)

такое - есть, но так практически в любой системе. Просто, насколько я знаю, в win - можно хоть одну функцию написать - у всех функций прототип один и тот-же - указатель на объект устройства и указатель на пакет IRP, а в linux - свои прототипы для функций чтения/записи, свои для открытия/закрытия и свои для ioctl()

[Ochkarik]

то что свои обработчики - не принципиально) принципиально - привести оба интерфейса к общему знаменателю, чтоб не тянуть два, одинаковых по сути, но разошедшихся по реализации проекта, под обе ОС.
один интерфейс со стороны приложения, второй со стороны HAL ОС.

[sabbatazh]

Так Ребята, Вы меня запутали!)

[Ochkarik]

да неее... короче, что Windows что Linux - все едино по большому счету)))
начинай писать - оно само все перенесется)))

[darkelf]

sabbatazh, для того, чтобы портировать драйвер с Windows на Linux надо более-менее представлять как оно устроено и там и там, и, при наличии соответствующих знаний и опыта, попытаться выделить часть, независящую от окружения (например протокол работы с устройством), чтобы сделать её максимально общей, а уже обвязку (например пользовательский интерфейс с драйвером и функции работы с портами) делать зависящую от ОС.

[oleshii]

Любой системный модуль под Linux, регистрирующий свои обработчики read/write/ioctl, становится доступен через данный интрефейс.
Кроме того, имеются procFS и VirtualFS, являющийеся kernel mode layers, облегчающие и стандартизирующие работу system modules и
user applications. Рекомендую почитать что нибудь на эту тему Сержа Яковлева (в поисковик забивать латиницей). Сам пользовался его
выкладками. но пока это не "покопаешь" в течении полугода, ничего ясно не будет.

[sabbatazh]

Ochkarik, oleshii, darkelf, Спасибо! разбираюсь... (не мог раньше ответить - болел...((( )
может подскажите среду разработки подобную Visual Studio + DDK + VisualDDK, или может подобие VisualDDK встречалось...
Спасибо!

[Finch]

sabbatazh, Под Linux? (Если да, то зачем тут DDK?)

[sabbatazh]

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

[Ochkarik]

под какую ОС?

[oleshii]

sabbatazh,
Под Linux при наличии 2 хостов и соединительного "шланга" (COM or USB) можно использовать gdb для отадки,
KDE или CodeBlocks for development. Для "выброса" сообщений из модуля, "поднятого" на post-boot-stages
существует функция printk (Print Kernel) Прототип ее - как у обычной printf. Для early-boot-stages существует earlyprintk с ОБЯЗАТЕЛЬНЫМ
redirect output в tty№ in the kernel start command line. А вообще то еще "папа" Линус Торвальдс говаривал (c кавказским акцентом):
"Дядя sabbatazh, debugger - не нужен !" Вот линк на сайт Сержа Яковлева: http://www.iakovlev.org/

[sabbatazh]

Ochkarik, Linux....
oleshii, )))) Спасибо!))) со "шлангом" работал - а ля терминал...
Ребята, Огромное Спасибо, за истолкование!!!! Лед тронулся!