> Еще раз "Поэтому для них и не работает inotify.", для тех
> что обновляются сами можно получить событие через inotify.А откуда такие сведения взяты? И для начала: а что вами подразумевается под "активностью датчика"?
Я вижу тут как минимум 2 разные сущности:
- Датчик где-то там внутри себя что-то делает (e.g. производит замеры).
- Датчик принимает участие в той или иной активности на шине (e.g. отгружает эти замеры хосту).
Это 2 разные вещи и как они связаны в конкретном случае - весьма зависит от.
> Значит и inotify для него работает.
Хз, я бы это за данность не считал без проверки.
Если что - я достаточно активно интересовался как это работает и имею заметить что сделать энумерацию доступных показометров энного типа через sysfs - то еще приключение. Обход большой иерархии с кучей симлинков, половина которых имеют свойство указывать друг на друга - те еще грабли. А еще и на inotify там потом подписываться... выглядит как куча головняка на ровном месте. На мой взгляд, такой интерфейс к показометрам - не предел мечтаний для апликушников, мягко говоря.
> Все зависит от вашей фантазии - вплоть до перехода на другой конфиг
> с отключением лишних показаний.
Знаете, теоретически я себе и операционку целиком мог бы написать, ограничиваясь только моей фантазией. А практически - я не горю желанием изобретать велики из чугуниевых труб, обнаруживая потом что нормальные люди из алюминия и карбона делают их в 20 раз лучше и с меньшими мучениями. Поэтому если кто хочет запилить более-менее простой в использовании и общеупотребительный интерфейс - я только за.
А чего такого в том чтобы sysfs остался low-level уровнем, а эта штука через dbus - более high-level, где можно как-то по простому запросить у системы нечто типа "а какие градусники есть и что показывают?"
> А если запущен только один conky и читает он датчики очень выборочно
> и не все параметры?
Ну я бы на месте упомянутой штуки тоже читал только датчики, на инфо от которых кто-то подписался.
> же придется рассчитывать на худшее и дергать 10-100 раз в секунду
> и все параметры.
По хорошему - программы могли бы при подписке указывать свой аппетит aka требования к тому как они это хотели бы. А в ответ можно было бы еще и по хорошему сообщить что по факту светит с учетом умений железа и софта. Ну и с учетом аппетитов потребителей показаний дергать. А сейчас в sysfs btw вообще IIRC для датчиков нет никаких данных о скорости с которой датчики могут поставлять инфо, о разрешении и прочем. Подобные данные сейчас можно вообще получить только или экспериментально или после чтения на даташита и/или кода драйвера. Догадайся сам, дорогой апликушник, что этот датчик может. Удобно :)
> Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один
> из профилей настройки сети.
Как вариант - почему бы и нет? Ну и выставлять сие по свистку от D-bus со стороны того кто эти профили применяет. Да, вы знаете, программа которая просит самолетный режим - совершенно не обязана быть моим менеджером сети! Виджет с кнопочкой или там какой-то обработчик нажатия аппаратной кнопки - совсем не обязан быть менеджером сети или что-то там знать о том какие у меня профайлы, настройки и-фейсов, список этих и-фейсов и прочая.
Есть желание: "не излучать в эфир". Когда юзер нажал вот эту кнопку. В контексте этого желания знания о том что там является сетевым менеджером, какие у него вообше есть профили, сколько и каких и-фейсов и прочая - элементарно лишние. Логичнее всего если обработчик кнопки запулит сообщение в шину, а остальные кому это интересно пусть уже разбираются как это обеспечить. Нормальное иерархическое построение абстракций, с откидыванием явно лишних знаний и действий там где это даром не упало.
> Вот именно - это должно быть в сетевом конфигураторе. А не в
> каждом сетевом приложении.
Нет, вот извините. Сетевой конфигуратор не должен быть всеми мыслимыми вариантами виджетов. И все мыслимые комбо аппаратных кнопок он обрабатывать он не должен. Он - конфигуратор сети, а не куча виджетов. И не мега-обработчик кнопок. Этим пусть занимается кто-нибудь другой. А вот потом этот другой по логике вещей должен пульнуть сообщение в шину. А сетевой конфигуратор и прочие причастные пусть там уже дальше разбираются, получив его.
> Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный.
Простите, а с фуя ли сетевой бэкэнд должен заниматься юзеринтерфейсом с пользователями? И почему мне не должно быть можно порулить как из гуя так и из консоли? А то и с хардварной кнопки какой-нибудь, или их комбо.
В этом плане тот же NM например вполне себе разнесен на бэкэнд (собссно network-manager), а консольный клиент и гуйные клиенты разных DE к этому интерфейсятся. И d-bus оно использует. Нокия просто это сделала легеньким, хорошо работающим и доведенным до ума. Так что юзеру не приходится вбивать 20 костылей и подпорок.
> И можно обойтись без сообщений, их обработки и демонов.
Да в принципе можно и без компьютеров обойтись. Считать на счетах и в тетрадках. Но вот боюсь я не хочу чтобы сетевой конфигуратор был единственным UI к себе, напрочь лишенным возможности взаимодействия с остальным софтом.
> У программы под рутом и так хватит привилегий для этого.
У программ под рутом хватит прав чтобы записать нули в /dev/sda, или что там у вас :). Поэтому под рутом пускаются только сильно некоторые программы, по сильно некоторым случаям.
> ХЗ все виданные мной huawei за последние лет пять именно такие. Даже
> если прикидываются обычным ppp.
А, если вы про 3G свисток, внутри любого сотового девайса есть как минимум неслабая фирмварь с протокольным стеком и каким-то юзеринтерфейсом к нему. Этот стек - большой и сложный и фирмварь весит минимум несколько мегабайтов, вполне себе будучи чем-то типа RTOS. И процов там может быть несколько. Как минимум - их там обычно два: "управляюший", с которым вы общаетесь, и "сигнальный", который делает heavy lifting. А иногда процов и больше - скажем для юзеринтерфейса бывает отдельный проц. Если к нему экран прицепить, выходит смартфон.
Вайфая это в основном не касается. Ну то-есть там чаще всего лишь небольшой сервисный процик, который сугубо гоняет данные из usb в радио и операционкой сие называть больно жирно. Свежий пример - ath9k_htc и фирмварь, недавно открытая квалкоммом на 9271 и 7010.
С сотовыми сетями все сложнее: там очень кастомный протокол, подразумевающий дофига сервисных операций всех мастей. А если юзер хочет линух пускать - его на отдельный проц только пускают, дать доступ на проц который протокольный стек крутит все сцут и не то чтобы без причин - все это многомегабайтное глюкало очень даже может околеть от тыкания палочкой, в хучшем случае с завалом неслабого куска сети :)
> Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.
Ну тогда получит ВНЕЗАПНЫЙ power gating или сброс. Если его угораздило что-то обновлять, производитель получит не менее ВНЕЗАПНЫЙ возврат по гарантии от обозленного юзверя.
> Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
Да это вроде в стандарте даже заложено. И да, позвольте все-таки не рассматривать откровенно бажные, а то и просто malicious железки: в таких допущениях вы вообще не можете надеяться на сколь-нибудь корректную работу системы. А так вон наиболее прошаренные люди делают сотовому модулю power gating отдельным полевиком, через GPIO системного проца. Как в NEO900. Снятие питания - оспорить можно только в спортлото. Тут даже бажная и вредная железка обломится.
