> Из гугла по "sysfs inotify".Ну если вы такой джедай - может подскажете где посмотреть на не очень жуткий кусок кода обхода sysfs на си, где всякие грабли - обпрыганы? Ну вот допустим я хочу найти все градусники в системе. Желательно - поняв что это за градусники и например какие у них возможные диапазоны значений. Еще лучше если оно нормально обрабатывает все ошибки всех операций.
> для в таком случае работает.
...
> делает запрос. а ответ в этом случае получат все. Частота запросов
> будет определяться самой нетерпеливой программой.
А, вот оно что. Так понятнее что вы имели в виду, спасибо.
//кстати еще спасибы за сватание мне udev, это кажется вы были. Я через него научился делать некоторые вещи относительно безграбельно и не очень криво.
> Согласен, sysfs далек от совершенства. Но его нужно улучшать, а не пытаться
> прятать его проблемы.
Не имею ничего против улучшения sysfs. Заметьте, ни я, ни гномеры не предлагали его выпилить и заменить. Они как я понимаю предлагали прослойку для апликушников пишущих десктопные программы, которым не в кассу делать кучу (около)файловых операций, проверяя^W забивая на пару десятков потенциальных ошибок в самых разных местах.
> Как она определит что градусник, а что нет?
Градусник - это то что показывает температуру, очевидно. А вот как определить - было бы неплохо если бы гномеры сделали какие-то фильтры, или типа того, чтобы каждый первый апликушник не ломал над этим голову сам.
> Выше человек еще упоминал fan и pwm, а они очень разные бывают.
Во первых, они - не градусники. Во вторых, я немного поинтересовался вопросом, когда АМДшники запиливали управление вентилем. Ну и насколько я понял - некий "стандарт" поведения там устаканился. Сам по себе PWM вполне однозначно характеризуется коэффициентом заполнения. Тут правда возможны варианты кто его меняет: железка со своей стороны, софт со своей, и как это происходит. АМДшники по этому поводу там довесок вывесили, позволяющий как уповать на авторегулирование набортным сервисным процом (по дефолту) так и самому порулить. Сам по себе коэффициент заполнения - во всех PWMах более-менее однозначная штука и как он может быть сильно по разному - ну хз.
> И станет еще сложнее - а нужно было всего-то один раз консольное
> программе температуру глянуть.
Где-то сложнее. Где-то проще. Апликушнику имхо было бы проще сделать полтора обращения к гномерской приблуде чем ...цать операций с ФС и файлами, каждая из которых потенциально может обломаться.
> датчик бессмысленно, то драйвер просто будет отдавать последнее
> значение, пока оно не устареет.
И все бы замечательно. Вот только неплохо бы в принципе знать динамику и диапазоны датчика, а также что это вообще такое. Ну например чтобы понять с какой скоростью имеет смысл перерисовывать показометр. А то глупо перерисовывать 5 раз в секунду для датчика который оказывается обновляется не чаще чем 1 раз в секунду.
> Я понял вашу позицию. Не нравится мне в ней то, что поверх
> конфигуратора сети появляется еще один конфигуратор (виджет).
А я считаю что плохо когда программы - вещь в себе и не могут взаимодействовать с другими программами. Одна из сильных сторон unix way - возможность собирать систему из кубиков, соединяя их между собой. Но как видим, практика показала что не все то что люди хотят от компьютеров сейчас хорошо делается как именно файловые операции.
Собственно какой-то зачаточный IPC был много лет. Просто он был сделан в виде в котором у него сравнительно мало применений. Ну как у отсылки RAW фреймов эзернета применений здорово меньше чем скажем программ уповающих на работу с HTTP. Имхо было бы неплохо взаимодействие между программами неплохо бы расширить еще и шиной. Модель pub/sub имеет свои плюсы, а некоторые вещи так выглядят наиболее логично и позволяют стыковку самых разных программ по самым разным поводам. В несколько более структурированном виде чем остальные варианты.
> Нужно вводить дополнительный согласованный формат/протокол между этими
> конфигураторами. Геморроя много,
В случае шины это как раз получается относительно логично и относительно просто. Пример N900 тому подтверждением.
> а смысла мало.
Не согласен. Возможность воздействовать между программами, делая те или иные действия из той программы удобна мне - это хорошо и правильно. А вот прибивать все гвоздями к 1-2 программам - гм, ну мы вроде не в винде, чтобы столь глупые ограничения на использование системы вводить.
> И что это реально дает? Возможность навоять свою кнопку, как в андройде?
> Ради одной кнопки весь этот огород?
В локально этом примере - да, это дает мне возможность нажать именно ту кнопку именно так как мне будет удобно. Без залета апликушника на выписывание полновесной морды к сетевому бэкэнду.
В более глобальном масштабе это дает возможность взаимодействия между программами aka IPC в структурированном формате. Когда можно попросить кого-то сделать что-то в каком-то структурированном виде, так что это даже еще и сможет работать между несколькими разными программами.
> Есть варианты попроще.
Например?
> Да не нужно ничего некуда пулять - делим конфигуратор на frontend и
> backend. Frontend'ов может быть куча - от простых однокнопочных, до навороченных.
А как насчет возможности использовать и полноценный конфигуратор для настройки сети в разных позах, но при этом получив и удобную кнопку для того чтобы быстро заткнуть wireless? Копаться в навороченном конфигураторе для срубания wireless - очень так себе идея. Получается что нужен некий co-existence минимум 2 разных программ воздействующих на бэкэнд. А это опять же какой-то арбитраж, информирование всех причастных что конфигурация изменилась, чтобы они не глючили в поведении и отображении статусов. Ну то-есть начинается переизобретение шины...
> Не понял, а предложенный вами kdbus значит под guest'ом работает ? :)
А kdbus как таковой - самая низкоуровневая часть шины. Он сетевые интерфейсы сам по себе не дергает by design. И в /dev/sda нули не пишет. Он сообщения между программами гоняет. Само по себе это "относительно безвредная активность". Единственное что возможно, пользуясь случаем, стоило бы устроить некий редизайн dbus, раз уж есть мысль в кернел "увековечить".
> не отдельные порты. Но у меня и этого не получилось.
Сколько я себя помню - с этим всегда были какие-то непонятки. Стандарт вроде как прописывает это, но реально имеет свойство не работать. В ряде железяк вроде как Vbus просто прицеплен на +5V, спасибо если через предохранитель. Ну и отключить оно это не сможет ну хоть там что. Вообще, в usb довольно много костылей и бестолковостей, вплоть до состояния когда все начинают забивать на стандарт "потому что так удобнее". Характерный пример - удлинители USB. Стандарт вроде запрещает, но всем вроде как пофиг. Или usb-otg, который часто делается через жо...хм, обычный micro-B порт вместо эзотеричного micro-A, который никто в глаза не видел. Хоть host через micro-B вроде как и не по спекам, но кабели micro-B -> AF как бы есть.
