Python, обслуживание ноды устройства

http://docs.python.org/2/library/functions.html#open

http://docs.python.org/2/library/struct.html

Ты, наверное, этого не осилишь, но для таких вещей есть CUSE: http://lwn.net/Articles/308445/

Помоему это невозможно. Если еще можно как-то организовать драйвер файловой системы на python, используя fuse python bindings, то реализовать character device driver нет.

Если реальное устройство управляется через COM-порт (или USB, или что-то похожее), то можно. Другое дело, что смысла мало.

Каким образом? Через CUSE?

Python-драйвер будет получать запросы к char device node через CUSE, да.

И биндинги для питона там тоже есть готовые?

Есть какие-то, но я не пользовался.

я ничерта не понимаю в ведре, можешь парой слов сказать, почему не выйдет написать на сях в ведре небольшой адаптер который будет делать нужное извращение, на педоне в юзерспейсе логику, и потом объединить их любым способом типа сокета или файла?

Всё зависит от того, что такое «нужное извращение».

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

Я не понял ни того, что ты понял, ни того, что ты предлагал.

Я понял вот это:

1) у афтара есть устройство
2) он хочет написать к нему драйвер на педоне
3) но так, чтобы в системе оно выглядело как чардевайс

соответсвенно
1) пишем чардевайс (туториал)
2) где-нибудь внутри вкорячиваем, чтобы всё полученное он фигачил в сокет или файл
3) и этот сокет или файл уже окучиваем педонной программой хоть с другого конца мира

1) пишем чардевайс (туториал)

Уже неверно. В туториале драйвер на Си, ТС хочет на Python.

2) где-нибудь внутри вкорячиваем, чтобы всё полученное он фигачил в сокет или файл

Что «всё»? Если, условно говоря, коды и аргументы запросов пользовательской программы, то это CUSE.

Если, условно говоря, коды и аргументы запросов пользовательской программы, то это CUSE.

но есть профит — можно не читать, что такое CUSE (там столько умных буков и все по-английски), а чардевайс написать копипастом с опеннета )))

но есть профит — можно не читать, что такое CUSE

Если мерять временем, то профит будет отрицательный. В любом случае, по условию задачи - только Python.

Интересно все таки узнать, почему драйвер должен быть именно на питоне? Может быть мы смогли бы предложить другую архитектуру. Например, зачем взаимодействовать через char device, если можно взаимодействовать через pipe, fifo?

Драйвер на питоне по причине того, что уже написана большая прога, которая работает с устройствами подключенными на GPIO порты arm проца по различным импульсным протоколам. Устройств много, переписывать всё на сях некогда, да и знание си у меня не супер.

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