DBUS
moonug
widget/), работающих через парсинг лога madwimax. Мне показалось это
кривым решением. Решил дописать к драйверу нормальный DBus-интерфейс.
Есть у кого предложения по "идеологически правильной" интеграции с
существующим кодом?
Моя идея сейчас такова:
Добавить код в функцию scan_loop, остальную часть кода унести в
dbus.h/.c с префиксом функций md_ (madwimax dbus).
Alexander Gordeev
moonug <moo...@gmail.com> пишет:
Было бы здорово!
Я хотел сначала перевести все на pthreads. Т.е. сделать 3 потока - на
прием данных, отправку, и для dbus и других UI. К сожалению, пока
слишком занят.
Если положить код для dbus в отдельный тред, то будет только проще его
писать скорее всего.
Я не спец по dbus, но считаю, что самым правильным будет использовать
либо напрямую libdbus, либо, если это слишком сложно, glib binding для
dbus. Это для сохранения low footprint madwimax. Это все-таки драйвер.
--
Alexander
Константин Сазонов
Рядом живет DataEngine и пара виджетов для KDE4, собственно их написание и сподвигло меня на добавление dbus, ибо решение через парсинг лога все таки кривое, хоть и работает.
И да, конечно, буду отделять в отдельный тред.
Сейчас главное определиться что рассылать сигналами, а что методами делать.
--
moonug.
Alexander Gordeev
Константин Сазонов <moo...@gmail.com> пишет:
> Я пока еще не совсем разобрался в коде драйвера, чтоб правильно
> вписаться, но кодить уже начал. Пока живет тут:
> http://bitbucket.org/moonug/madwimax-dbus/. Через low-level dbus API,
> естественно, ибо смысла использовать биндинги к glib я особо не вижу.
Прекрасно!
> Рядом живет DataEngine и пара виджетов для KDE4, собственно их
> написание и сподвигло меня на добавление dbus, ибо решение через
> парсинг лога все таки кривое, хоть и работает.
Согласен, это путь неправильный.
> И да, конечно, буду отделять в отдельный тред.
Пожалуй, это даже не потребует значительного переделывания madwimax
прямо сейчас. Постараюсь выкроить для этого время.
> Сейчас главное определиться что рассылать сигналами, а что методами
> делать.
Пока подсказать не могу, я не очень знаком с dbus. Но постараюсь
ответить на любые ваши вопросы.
--
Alexander
Alexander Gordeev
Кстати, думаю, имеет смысл вернуться в список рассылки.
On Sat, 23 Jan 2010 22:55:43 +0300
Константин Сазонов <moo...@gmail.com> wrote:
> 2010/1/23 Alexander Gordeev <las...@lvk.cs.msu.su>
>
> > В Sat, 23 Jan 2010 16:48:36 +0300
> > Константин Сазонов <moo...@gmail.com> пишет:
> >
> > > Я пока еще не совсем разобрался в коде драйвера, чтоб правильно
> > > вписаться, но кодить уже начал. Пока живет тут:
> > > http://bitbucket.org/moonug/madwimax-dbus/. Через low-level dbus
> > > API, естественно, ибо смысла использовать биндинги к glib я особо
> > > не вижу.
> >
> > Прекрасно!
> >
> > > Рядом живет DataEngine и пара виджетов для KDE4, собственно их
> > > написание и сподвигло меня на добавление dbus, ибо решение через
> > > парсинг лога все таки кривое, хоть и работает.
> >
> > Согласен, это путь неправильный.
> >
> > > И да, конечно, буду отделять в отдельный тред.
> >
> > Пожалуй, это даже не потребует значительного переделывания madwimax
> > прямо сейчас. Постараюсь выкроить для этого время.
> >
>
> Я пока сделал новую опцию при запуске, по ней просто pthread_create().
Я думаю, эта штука будет включена по умолчанию, если вкомпилирована.
Т.е. нужно будет добавить опцию --with-dbus для configure. Если
configure найдет хедеры libdbus, то вкомпилирует поддержку dbus. А в
madwimax тогда можно сделать опцию --no-dbus, правда не уверен, что
это нужно, т.к. все равно потребуется библиотека libdbus просто чтобы
запустить madwimax. С динамической загрузкой врядли будем иметь дело
ради этого :)
> >
> > > Сейчас главное определиться что рассылать сигналами, а что
> > > методами делать.
> >
> > Пока подсказать не могу, я не очень знаком с dbus. Но постараюсь
> > ответить на любые ваши вопросы.
> >
>
> По поводу тредов есть вопрос:
> Понятно, что надо делать блокировки, что выбрать мьютексы или
> семафоры? Я склоняюсь к семафорам ибо они гибче, да и из dbus'а
> врядли будет много записи. Точнее сейчас ее совсем не будет.
Запись будет: как минимум, включить/выключить светодиод,
подключиться/отключиться, включить/выключить автоподключение.
Пока не понимаю, зачем там могут понадобиться семафоры. Думаю, лучше
использовать мьютексы, возможно рекурсивные. Эту часть я постараюсь
взять на себя.
--
Alexander
Константин Сазонов
Извиняюсь за молчание...
Кстати, думаю, имеет смысл вернуться в список рассылки.
Все в порядке, вряд ли у всех много свободно времени на fun :)
Хорошо, тогда переделаю.
Запись будет: как минимум, включить/выключить светодиод,
> >
> > > Сейчас главное определиться что рассылать сигналами, а что
> > > методами делать.
> >
> > Пока подсказать не могу, я не очень знаком с dbus. Но постараюсь
> > ответить на любые ваши вопросы.
> >
>
> По поводу тредов есть вопрос:
> Понятно, что надо делать блокировки, что выбрать мьютексы или
> семафоры? Я склоняюсь к семафорам ибо они гибче, да и из dbus'а
> врядли будет много записи. Точнее сейчас ее совсем не будет.
подключиться/отключиться, включить/выключить автоподключение.
Пока не понимаю, зачем там могут понадобиться семафоры. Думаю, лучше
использовать мьютексы, возможно рекурсивные. Эту часть я постараюсь
взять на себя.
Тогда действительно проще мьютексами (и, кстати, вариант с мьютексами вроде на FreeBSD проще портировать).
Значит пока у нас получается:
Сигналы:
- Линк
- Если линк есть то CINR/RSSI, tx power и т.д.
- Переключение состояния светодиода
- вкл/выкл
- настройка автоподключения.
Состояние соответственно будет запоминать уже софт с "той" стороны. Драверу хранить конфиги неприлично :).
--
moonug.
Alexander Gordeev
Константин Сазонов <moo...@gmail.com> wrote:
> 2010/1/27 Alexander Gordeev <las...@lvk.cs.msu.su>
>
> > Извиняюсь за молчание...
> > Кстати, думаю, имеет смысл вернуться в список рассылки.
> >
> >
> Все в порядке, вряд ли у всех много свободно времени на fun :)
Верно :)
Спасибо!
> >
> > > >
> > > > > Сейчас главное определиться что рассылать сигналами, а что
> > > > > методами делать.
> > > >
> > > > Пока подсказать не могу, я не очень знаком с dbus. Но постараюсь
> > > > ответить на любые ваши вопросы.
> > > >
> > >
> > > По поводу тредов есть вопрос:
> > > Понятно, что надо делать блокировки, что выбрать мьютексы или
> > > семафоры? Я склоняюсь к семафорам ибо они гибче, да и из dbus'а
> > > врядли будет много записи. Точнее сейчас ее совсем не будет.
> >
> > Запись будет: как минимум, включить/выключить светодиод,
> > подключиться/отключиться, включить/выключить автоподключение.
> > Пока не понимаю, зачем там могут понадобиться семафоры. Думаю, лучше
> > использовать мьютексы, возможно рекурсивные. Эту часть я постараюсь
> > взять на себя.
> >
>
> Тогда действительно проще мьютексами (и, кстати, вариант с мьютексами
> вроде на FreeBSD проще портировать).
>
> Значит пока у нас получается:
> Сигналы:
>
> - Линк
> - Если линк есть то CINR/RSSI, tx power и т.д.
>
> Методы:
>
> - Переключение состояния светодиода
> - вкл/выкл
> - настройка автоподключения.
>
> Я все правильно помню?
Не знаю, что это будет в терминологии dbus, но вообще хотелось бы,
чтобы можно было от драйвера получить всю информацию из структуры
wimax_dev_status (src/wimax.h) в любой момент времени. Эту структуру я
буду переделывать еще, видимо, чтобы ее же использовать при
взаимодействии потоков, но вся нужные поля там уже, по сути, содержатся.
Если я правильно понимаю, сигналы позволяют рассылать свежую информацию
всем заинтересованным. Это прекрасно, но можно ли просто получить
последнее значение нужного поля?
> Состояние соответственно будет запоминать уже софт с "той" стороны.
> Драверу хранить конфиги неприлично :).
Я, в принципе, согласен :). Но тогда уж надо хранить на "той" стороне и
остальные параметры, например, ssid. Меня в этом случае беспокоит, что
без dbus ничего работать не будет. Это неприемлемо.
Боюсь, что madwimax и так уже объединяет функции драйвера и
управляющего ПО.
--
Alexander
Константин Сазонов
Сигналы просто рассылаются всем подписанным на них на системной (в данном случае) шине. Метод может возвращать данные.
Можно просто сделать один метод, который будет возвращать все поля структуры.
Последнее значение можно получить либо сигналом, либо в качестве ответа от метода.
> Состояние соответственно будет запоминать уже софт с "той" стороны.Я, в принципе, согласен :). Но тогда уж надо хранить на "той" стороне и
> Драверу хранить конфиги неприлично :).
остальные параметры, например, ssid. Меня в этом случае беспокоит, что
без dbus ничего работать не будет. Это неприемлемо.
Боюсь, что madwimax и так уже объединяет функции драйвера и
управляющего ПО.
Так сейчас же работает и данные не хранит? Значит можно такое поведение и оставить для случая, когда dbus не включен.
D-Bus добавляет плюшек, но, мне кажется, не надо прям так уж совсем на него завязываться, надо просто дать возможность переопределить все, что хочется, через него.
И, кстати, есть такая проблема, что при засыпании/просыпании madwimax не переподключается, с этим тоже надо как-то решить будет.
--
moonug.