Sysfs - poll, inotify, select... Крик души

стоит сделать шаг влево и попробовать мониторить состояние, например, sysfs или procfs, то выясняется, что линуховое Everything is a file - это, мягко говоря, не истина.

А ничего, что это виртуальные фс? И файлы там тоже довольно виртуальны.
sysfs - это лишь предоставление внутренних ресурсов ядра в виде FS.

то пот отловить изменения температуры уже низя

libsensors.

В чем проблема вычитывать по таймеру? Например, читать в одном потоке по таймеру, во второй кидать ивент через socketpair.

И-таки под «все файл» имеется в виду вроде бы то, что всему можно сделать cat и тому подобные вещи.

А ничего, что это виртуальные фс? И файлы там тоже довольно виртуальны.

sysfs - это лишь предоставление внутренних ресурсов ядра в виде FS. Спасибо про ядро я в курсе. А как же /dev? А как же Everything is a file? Ведь логично иметь унифицированное поведение любого объекта файловой системы?

libsensors

Это мимо - там можно все здорово читать, но вот с событиями никак. - Но все равно спасибо за отклик

вычитывать по таймеру

Так и приходится делать - но неужели вы считаете это метод элегантным и гармоничным?

и тому подобные вещи

Здорово бы увидеть список подобных вещей, а то грабли бьют больно)

Так вычитка конкретных значений сенсора или какого-то другого параметра может производится непосредственно в процессе вызовы read из userspace.

Оно конечно не очень красиво, но многие драйверы этим не заморачиваются.

Поэтому, в общем случае только переодический полинг вас спасет.

линуховое Everything is a file

это не линуховое, и в линухе оно соблюдается по остаточному принципу

Может попробовать добавить в ядро функциональность по унификации событий от виртуальных фс? А там глядишь и в мейнлайн попадешь))

Линукс не сразу строился, все когда-то было кем-то написано.

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

А, то есть нужно добавить туеву хучу гемора всем драйверам, предоставляющим тот же proc или sysfs - чтобы они не только динамически генерили контент, а еще и сообщали, как он изменится? Ты хорошо представляешь, 1. сколько это работы 2. какая будет в результате у системы производительность, когда каждый драйвер начнет САМ поллить состояние (т.к. далеко не всё событийное).

Если с помощью poll() удается словить изменение на sysfs/gpio, то пот отловить изменения температуры уже низя, ибо на sysfs/i2c файлы уже не являются interruptable

прерывания от gpio аппаратные и ничего не стоит пробросить событие из обработчика. Чтобы отловить изменение температуры сенсора на i2c нужно постоянно его опрашивать и занимать и без того медленную шину, так что про долбоящера ты верно подметил. Для устройств где это действительно нужно (АЦП например) есть специальные фреймворки - см. например IIO.

Никаких событий там нет. Данные формируются только при запросе, более того, само измерение может происходить только при запросе. Устройство может сменить миллионы состояний в секунду, можно натурально обмазаться бесполезными событиями. Так что все верно: хочешь данные датчиков — запрашивай, нужно мониторить — мониторь с заданной частотой. В ядре это не нужно, можно запилить либой.

Самый надежный и кривой способ: while (..) { stat(file) }.

Фу

libsensors

угадай, как она работает

включать поллинг по inotify_add_watch

Усложнение драйвера + проблемы энергосбережения. Если одному приложению достаточно раз в секунду, а второму - 50 раз в секунду, то драйверу придется давать все 50 всегда, даже если только первое запущено. Короче всё равно УГ.

прерывания от gpio аппаратные

Не всегда.

Сделать поллинг в драйвере не сильно сложно, колбек написал и готово, только как ты себе представляешь поллинг /proc/meminfo например? Или зачем поллинг /proc/cmdline вообще например?

Не всегда

похер, нет прерываний от gpio - нет и поллинга

http://lxr.free-electrons.com/source/Documentation/gpio/sysfs.txt#L76

i2c разве поддерживает прерывания?

это же вам не smbus

может твой пин прерывания от сенсора куда-нить на gpio скомутирован.

А как же Everything is a file?

А то, что существуют разные типы файлов(symbolic links, hard links, block devices) благородного дона не смущает?

Ведь логично иметь унифицированное поведение любого объекта файловой системы?

Ты можешь прочитать файл, записать файл, узнать его атрибуты. Можешь сделать это с любым файлом, если хватит правишек конечно. Это унифицировано, хотя опять же - с блочными устройствами всё веселее - 1 байт там прочитать не так просто :-). Далее идут ACL, которые есть не везде(да и не везде нужны) и прочее. Твоя хотелка - как раз из таких.

В «похожих» прикольная подборка получилась)

в сисфс и прокфс не файлы, а пайпы. Данные туда поступают лишь в случае их чтения, в остальное время там пусто, и размер этих файлов 0.

см. например IIO.

квадрирую