sabbatazh
Помогающий |
Здравствуйте Уважаемые Знатоки! |
||
|
Ochkarik
|
начинать, наверное, с разработки интерфейса между драйвером и приложениями… особенно если требуется поддержать хоть какое то подобие работы. все что я слышал о линуксе, это то что там вроде для обмена есть ioctl и read|write. мельком читал какую то статью по написанию драйвера под линукс, но задача отпала, чему я был несказанно рад, честно говоря. опять же, если стоит не разовая задача, а с дальнейшей поддержкой кросплатформенного проекта.. PS может быть при разработке интерфейса, стоит обратить внимание на права пользователей… я, например, на ioctl в винде основывал, потом наткнулся на грабли доступа. |
||
RTFM уже хоть раз наконец! |
RXL
Технический
|
Все, что могу предложить: почитать Linux Device Drivers. read, write, ioctl — эти системные вызовы применимы только к файлам, но не к самим драйверам. Например, драйвер регистрирует в системе файл устройства — есть такая категория файлов в среде Unix вообще, не только Linux. Они идентифицируются тремя компонентами: числами uint8 — major и minor, и типом (символьное или блочное устройство). Через такой файл можно общаться с драйвером через стандартные системные вызовы, применимые к файлам. Специфичное общение организуют через ioctl. Есть и другие механизмы общения с драйверами из user space. Например, создание файлов в «/proc» (procfs). Ochkarik, права на файл разве имеют отношение к драйверу? Это уровень файловой системы. Ну и нужно помнить, что kernel space драйвер критичен к ошибкам и может завалить всю систему. |
||
… мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С. |
sabbatazh
Помогающий |
Ochkarik, RXL, Спосибо! |
||
|
Ochkarik
|
RXL, ну.. в винде когда создается объект устройства… доступ к нему из User — теми же API функциями что и к фалу: Create/Read/Write. и для специфических операций — IOCTL) и для взаимодействия между драйверами — Internal IOCTL. |
||
RTFM уже хоть раз наконец! |
RXL
Технический
|
В Линуксе разделение прав I/O и ioctl не делается. Файл открыть удалось — значит удастся выполнить и другие операции на этом дескрипторе. Правда, есть такая супернавороченная штука — SELinux: управление доступом вплоть до системного вызова, номера TCP порта или конкретной операции на конкретном файле, но этим пользоваться очень сложно и зачастую SElinux административно отключают. |
||
… мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С. |
darkelf
Молодой специалист |
в драйвер эти запросы доходят в виде IRP с разными IRP_MJ_XXX кодами. В Linux нет IRP, просто можно зарегистрировать свой обработчик ioctl(), и если будет вызван системный вызов ioctl() с дескриптором файла, относящегося к драйверу — будет вызвана функция этого драйвера. Аналогично и другие функции. |
||
|
Ochkarik |
я имел в виду не IRP а набор функций для общения с драйвером со стороны приложения) |
||
RTFM уже хоть раз наконец! |
darkelf
Молодой специалист |
я имел в виду не IRP а набор функций для общения с драйвером со стороны приложения) такое — есть, но так практически в любой системе. Просто, насколько я знаю, в win — можно хоть одну функцию написать — у всех функций прототип один и тот-же — указатель на объект устройства и указатель на пакет IRP, а в linux — свои прототипы для функций чтения/записи, свои для открытия/закрытия и свои для ioctl() |
||
|
Ochkarik |
то что свои обработчики — не принципиально) принципиально — привести оба интерфейса к общему знаменателю, чтоб не тянуть два, одинаковых по сути, но разошедшихся по реализации проекта, под обе ОС. |
||
RTFM уже хоть раз наконец! |
sabbatazh
Помогающий |
Так Ребята, Вы меня запутали!) |
||
|
Ochkarik |
да неее… короче, что Windows что Linux — все едино по большому счету))) |
||
RTFM уже хоть раз наконец! |
darkelf
Молодой специалист |
sabbatazh, для того, чтобы портировать драйвер с Windows на Linux надо более-менее представлять как оно устроено и там и там, и, при наличии соответствующих знаний и опыта, попытаться выделить часть, независящую от окружения (например протокол работы с устройством), чтобы сделать её максимально общей, а уже обвязку (например пользовательский интерфейс с драйвером и функции работы с портами) делать зависящую от ОС. |
||
|
oleshii
Участник |
Любой системный модуль под Linux, регистрирующий свои обработчики read/write/ioctl, становится доступен через данный интрефейс. |
||
|
sabbatazh
Помогающий |
Ochkarik, oleshii, darkelf, Спасибо! разбираюсь… (не мог раньше ответить — болел…((( ) |
||
|
Finch
Спокойный Пролетал мимо |
sabbatazh, Под Linux? (Если да, то зачем тут DDK?) |
||
Не будите спашяго дракона. |
sabbatazh
Помогающий |
Finch, я имел в виду в какой среде лучше разрабатывать модули; отлавливать сообщения, ошибки модуля; дебаггер и т.п…. |
||
|
Ochkarik |
под какую ОС? |
||
RTFM уже хоть раз наконец! |
oleshii
Участник |
sabbatazh, |
||
|
sabbatazh
Помогающий |
Ochkarik, Linux…. |
||
|
Answering the question in the title: Is is possible to copy a driver from Windows to Linux?
No, not without (quite a lot of) extra work.
A driver hooks into the kernel of the operating system, allowing it to «drive» some hardware.
The Linux kernel and the Windows kernel are understandably very different (or they would both be called «Windows» or «Linux»). So one can’t expect to be able to simply take a driver, even if it was available in source form, from Windows and make it link with the Linux kernel, or even compile it reasonably cleanly on a Linux system (or on any system which is not the specific version(s) of Windows that it was written for).
You can’t even take a driver from OSes that are superficially similar, such as the BSD systems, and just import it into another Unix system without some delicate coding. Having said that, code sharing on the «device level» do happen from time to time between free Unix systems, but not without the extra effort of fitting the code into a new kernel infrastructure.
I do believe that there are instances where people have written kernel code for accessing reverse engineered binary blobs of drivers. This obviously requires someone to sit down to look at the binary driver, figure out what it’s doing, and write the appropriate bits of Linux kernel code to hook into it, so it’s still not just a matter of copying the driver.
Answering the question in the title: Is is possible to copy a driver from Windows to Linux?
No, not without (quite a lot of) extra work.
A driver hooks into the kernel of the operating system, allowing it to «drive» some hardware.
The Linux kernel and the Windows kernel are understandably very different (or they would both be called «Windows» or «Linux»). So one can’t expect to be able to simply take a driver, even if it was available in source form, from Windows and make it link with the Linux kernel, or even compile it reasonably cleanly on a Linux system (or on any system which is not the specific version(s) of Windows that it was written for).
You can’t even take a driver from OSes that are superficially similar, such as the BSD systems, and just import it into another Unix system without some delicate coding. Having said that, code sharing on the «device level» do happen from time to time between free Unix systems, but not without the extra effort of fitting the code into a new kernel infrastructure.
I do believe that there are instances where people have written kernel code for accessing reverse engineered binary blobs of drivers. This obviously requires someone to sit down to look at the binary driver, figure out what it’s doing, and write the appropriate bits of Linux kernel code to hook into it, so it’s still not just a matter of copying the driver.