Добрый день, господа!

Понадобилось мне тут сделать загружаемый модуль ядра. С этим проблем не возникло. Но вот делема, нужно октрыть "/dev/ttyUSB0". Т.е. в хост втыкают переходник USB<->serial port. Мой модуль должен для этого порта предоставить некий протокол, так, чтобы можно было записывать данные и читать через порт, не заботясь о контрольной сумме, фреймах и т.п. Разогнавшись бодро, я понял, что ядро не позволяет оперировать с файлами как из user space. Вот и вопрос: как это сделать наиболее красиво? Не предлагать править драйвер ttyUSB, это просто исключено. Параллельно ищу сам инфу, но вдруг здесь кто-нибудь сталкивался с подобной проблемой...
Заранее спасибо!!! Ваш Фокс

Вопрос, зачем из модуля открывать /dev/ttyUSB0? 1 модуль - 1 задача. А для вывода/ввода есть потоки и ядро само решает в какую консоль это должно идти.

Простите, что?
Мне кажется, что я вас не понял. Либо вы не поняли меня.
Консоль тут не причём. Открывать нужно именно /dev/ttyUSB0. И именно из модуля. Другие варианты рассматриваются, но цель одна: модуль оборачивает данные, которые ему скармливает клиентская программа, в сетевой пакет. Который передаётся по сети RS-485. Также, модуль принимает пакеты, декодирует их, проверяет контрольную сумму, и клиентской программе возвращает тоже данные. Цель модуля: изолировать формирование и парсинг пакетов от проги юзера. Под прогой юзера я поинимаю не одну, а, допустим пачку echo, которые вызываются кроном по расписанию, а в фоне ещё и процесс какой-нить висит, который через этот же модуль мониторит сеть...

может имеет смысл написать демона, который будет мостиком между драйвером и устройством в /dev?
демон будет тягать данные из модуля и сливать в найденный ttyUSBx.
усилий минимум, в ядро лазить не надо

Может быть! Вот только про демонов ничего не знаю( Буду копать! Спасибо!!!

Теперь понятнее, но всё же зачем /dev/ttyUSB0?

Модуль ядра
Это не цель модуля, а демона, и не нужно это смешивать.

haker_fox
вам правильно советуют.
вам надо не модуль ядра писать, а демона.
с одной стороны ваш демон открывает сокет в файловой системе, к которому будет подключаться user, и слушает его, а с другой стороны ваш демон открывает /dev/ttyUSBx и работает с ним.

с другой стороны, а висеть в виде демона действительно нужно? у вас планируется несколько клиентских программ, которые одновременно подключаются к вашей "прокладке"?
если клиент один, то возможно проще было бы сделать API, выделить его в shared library в виде .so-шника, а разработчикам клиента отдать заголовочный .h и пример применения в виде main.c ?

Я уже тоже прихожу к этому

Клиентов несколько в том-то и дело


Шнурок преобразователя USB-to-serial port вставляется в разъём USB Host на плате, где крутится линукс. Шнурок другой стороной смотрит в сеть RS-485.

Собственно говоря, из определения модуля не следует, что он не может выполнять данную работу. И пока я не столкнулся с тем, что открыть из модуля другой модуль (драйвер) весьма проблематично, всё было ок.

Да конечно это возможно, но это нарушение концепции. Вы еще несколько раз нарушите концепцию и уже никогда монстра, который получится в результате, не сможете отладить.