> Скорее наоборот - conky опрашивает датчики с заданным интервалом

ВНЕЗАПНО, именно это и называется polling :D

> Большинство датчиков не активны, пока не будет к ним обращения.

Вот это совсем не факт. За все датчики расписываться как-то сильно шустро, не?

> Поэтому для них и не работает inotify.

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

Самое очевидное: free fall detector например явно работает всегда. А вот его состояние поллингом проверять - нерезультативно. Если вы будете его раз в секунду проверять, ноут за эту секунду успеет приложиться уже. С работаюшим хардом. Царапнув поверхность диска. А если его дергать часто - программа не даст процу в low power режим уйти скорее всего.

И да, а коньки как-то обрабатывают переход системы на батарею? Ну там скажем от адаптера - можно большинство датчиков 10 раз в секунду сканить, а от батареи - лучше раз в пару секунд. В то что гном с профайлами питания и d-bus так сможет - я еще поверю.

> 10-100 раз в секунду, ведь он не знает как часто они нужны приложению.

О, это идея! Внедрить kdbus в ядро и пусть ядро сразу и рассылает по kdbus, сразу по факту доступности инфы от железки :).

> Опять же, скорее всего iio-sensоrs будет отсылать одним сообщением
> все параметры датчика, даже если они не нужны для конкретного приложения.

Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие режимы сна если кто-то дергается. И когда это хренадцать программ, читающих датчики всех мастей - получаеся "не очень".

Грубо говоря, если 5 программ надо температуру проца, в обычном случае все 5 будут дергать датчик. А так один демон дернет датчие и раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.

> Я давал ссылку на лор - там все эти аспекты обсудили.

Я не посещаю LOR, увы. Посылать меня туда бесполезно.

> Какие гарантии, что все приложения обработают это сообщение корректно

Так же как и со всеми остальными программами. За системные - отвечают QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них это в общем случае скорее информативный сигнал. Ну то-есть они могут скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть пропадет. А не хотят - активность зарубится как получится. Когда системный компонент пойдет и потушит сетевой интерфейс.

Зато все это рулится одной кнопой из гуя - offline mode. Или скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо - одним действием с системой, с минимальным шансом сделать что-то не так. И минимально необходимыми знаниями - "хочу самолетный режим". Программе или скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.

> и действительно перестанут использовать радио связь?

Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся на него заранее. А получив его - пойдут да вырубят радио на "своих" железках. Отправителю сообщения вообще не надо знать кто и как это будет делать, ему надо только запросить самолетный режим. Остальное не его сложности. Элементарное разделение труда.

Обычные программы ... могут принять к сведению сообщение и что-то сделать, понимая что системные компоненты сейчас уберут сеть. А могут ничего не делать - тогда их просто обуют на сеть неожиданно для них. "Продолжить использовать" интерфейс который системные компоненты форсанули down - у программ не получится по причинческим технинам :P.

Ну то-есть зайдя как рут - можно это переиграть, ессно. Чудес не бывает: рут может всё. Но обычные юзермодовые программы в общем случае просто обломаются. Или ожидаемо для себя, если они подписались на сообщение, или ВНЕЗАПНО, если не подписались.

> Должно быть не только удобно, но и надежно.

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

И да, вы можете предложить решение лучше? Чтобы было столь же просто для инициатора?

Я вот могу: засунуть kdbus в ядро, ядро - самый ядреный компонент системы, который пишется надежными людьми :). Получив сообщение - ядро само вырубит беспроводные ифейсы. Уж у него полномочий на всех хватит, а если вы не доверяете надежности ядра - то про остальное речь вообще не идет :P.

> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,

Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен? :)

> и то если это не usb-wifi (со своей ОС) который может
> сам начать проверять обновления.

Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в виду - это извините мобильные роутеры и прочие, а не свистки. Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое межсистемное конективити по хорошему, чтобы и такие штуки были в курсе что им надо заткнуться? :) А еще в идеале неплохо бы после предупреждения снять питание с девайса. На всякий. И питание экономится, и что-то там обновлять девайс в общем случае не сможет :)