LINUX.ORG.RU

Bluetooth стек без свистелок


0

2

Народ, а кроме умершего affix есть ещё открытые реализации BT системы? Ну или может форк bluez в человеческом виде есть?

А то этот долбаный bluez оказывается без dbus и glib не собирается. Нахера они там нужны даже на десктопе - представить себе не могу никак.

Сходу нашёл в архивах девелоперских листов только вопли «Вы опупели? Ну и нахера вы намертво bluez к dbus приколотили? Как его в embedded теперь запиливать?» и ответы Марселя Холтмана в путинообразном стиле типа «Современный этап развития софта на десктопах ставит массу интересных задач перед разработчиками, более глубокая интергация в bluez новейших технологий одна из таких, и вам следует более лучше изучать современные тенденции, овощи там, рожь и всё такоэ».

Собственно, глянул сырцы - отпилить можно, но может кто уже отпилил, а я просто не в курсе?

Вообще смех, конечно - захотел в TP-Link WR703N сунуть Handsfree Profile. Ну чтобы коробочка с USB звуковухой и голубозубой затычкой могла хендсфрёй для телефона работать. Сначала оказалось что всякие ofono не только тот же dbus тащут, но ещё и не работают. А чтоб работали, надо вынь да положь уродский pulseaudio к ним или какой gstreamer. Это в 32Мб памяти и 4Мб флеша. Ага. В общем не обсуждается - dbus и тем более pulseaudio в коробочку не нужно.

Ну написал за день свой демон HFP. 30 килобайт. Работает, требует только libpthread, libbluetooth и ещё libasound, если с ALSA собрать. Можно и через OSS звук гнать, но оно много потоков не умеет, музыку выключать придётся.

Ну, думаю, ща его и bluez в коробку кроссом соберу, воткну голубозубую затычку и будет щастье. А вот хрен там, bluez тащит dbus и glib. Г-н Холтман всё за всех решил.

Такими темпами скоро и ping без glib,pulseaudio,polkit,gconf и ещё какой-нибудь новомодной дряни c xml-ем не соберёшь. Посылаю множество лучей кровавого поноса тем гадам, которые всё хорошее стремятся намертво приколотить к нахер не нужным новомодным свистоперделкам и вопрошаю о свободной от этого ..... реализации такой низкоуровневой и никак ни с какими десктопами не связанной реализации BT стека.

★★★★★

новомодной дряни c xml-ем

только plain text! только грайндкор!

anonymous_sapiens ★★★★★
()

кстати да, много раз сталкивался с этой фигней.

очень много хороших вещей скатываются в говно.

гугли на тему «Embedded Bluetooth stack» возможно есть не только платные решения :)

ktk ★★★★
()

мы уже писали этим уродам. Таки да, они уроды. Есть стэк из BSD, из коробки на лялихе он не заработает. Смотри сам что проще.

anonymous
()

D-Bus и glib - мелкие либы. В свое время в такой же ситуации обратил их использование в преимущество. Но да, плохо что безальтернативно приколотили гвоздями.

slapin ★★★★★
()
Ответ на: комментарий от slapin

хренасе маленькие! glib2 весит 11 метров, dbus - ещё мегабайта 4. Как-то дофига, если расчитывать на маленькие железки.

anonymous
()
Ответ на: комментарий от ktk

гугли на тему «Embedded Bluetooth stack» возможно есть не только платные решения :)

Кроме affix - ничего. А affix в ядро не пошёл, и к bluez-овым дровам не подходит. Переписывать affix под bluez-овые дрова - гораздо геморнее чем отпилить dbus у bluez-utils.

Кстати, интересно - bluez дрова в ядре написаны вполне прилично. Макс Краснянский и т.п. А над userspace поглумились изрядно, в основном компашка во главе с Холтманном.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

хм, что-то я правда погорячился. показалось что btware доступны.

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

ktk ★★★★
()
Ответ на: комментарий от iBliss

Насколько такой форк будет востребован? Где его держать и какими силами пилить чтоб оно было up-to-date? Логично было бы ветку на bluez.org делать, но Холтман уже послал с этим нахрен многих.

Нормально форкнуть и кое-как для себя перепилить - несколько разные вещи.

Ну и для форка потребуется некоторая тактическая поддержка от сведущих в BT.

Например, никак не могу найти толком какие компоненты из userspace bluez реально необходимы для работы BT, ибо документации на bluez (опять же стараниями того же Холтмана, кстати) нету.

Понятно, что нужен SDP сервер - чтобы отвечать на запросы всяких девайсов и держать текущую базу service records.

Функционал профиля легко реализуется отдельной соответствующей софтиной - с этим я при написании HFP разобрался - всё достаточно просто и весьма юниксвейно, мало чем отличается от классического TCP/IP сервера - тупо сокеты и всё такое.

А вот что нужно от той части, что раньше называлась hcid - пока не очень понятно. Всякий pairing и прочая, плюс оно должно при входящих коннектах от девайсов вызывать соответствующую софтину?

В принципе удалось собрать bluetoothd в варианте hcid + sdpd, отключив всю ботву которая должна быть отдельными от bluez сторонними серваками/клиентами реализована - получилось в итоге не сильно много сырцов и небольшой бинарь.

Но какого-то более-менее вменяемого описания структуры bluez (конкретнее - hcid) найти не могу. А из-за того, что в код густо намешаны glib и dbus разобраться в сырцах и понять логику работы hcid весьма проблематично.

Вообще - userspace bluez в теперешнем виде - решение, конечно, совершенно дебильное, маразматическое тупое и абсолютно неюниксвейное. Это как если бы в inetd ( его функции, насколько я понимаю выполняет hcid ) стали запихивать apache, exim, mysql, proftpd и вообще все возможные сервисы которые могут работать по IP вплоть до броузеров, чья гуёвая морда просто общалась бы со своей сетевой половинкой через dbus.

В общем, где найти тех, с кем можно пообщаться на эту тему?

Stanson ★★★★★
() автор топика
Ответ на: комментарий от ktk

Да там вообще пипец, в bluez этом.

Собственно bletooth сам по себе не сложен.

Очень похоже на IP, только с добавлением такой штуки как sdpd - это сервачок, который выдаёт удалённым девайсам список поддерживаемых сервисов. Ну типа «на этом компе работают http на TCP порту 123, ssh на TCP порту 345 и snmp на UDP порту 234».

Чтобы разбираться с коннектами и адаптерами есть hcid. Аналог inetd или xinetd

Ничего необычного или сложного.

И вот представьте, что маинтейнер какого-нибудь xinetd внезапно стал запихивать в него поддержку всех возможных протоколов. Ну то есть абсолютно всех - от http до nfs включая всякие раритеты и курьёзы. И получилось так, что невозможно запустить apache, а надо писать какую-то фигню которая будет сидеть на dbus, принимать некие запросы от dbus и через dbus-же отдавать контент, или, в лучшем случае, получать от dbus некий файлодескриптор через который и работать (это если маинтайнер ещё не добрался до http - как в случае с bluez и HandsFree Profile).

Такие вот пироги с котятами.

Stanson ★★★★★
() автор топика

Bluetooth стек src/sys/netgraph/bluetooth в ядре и утилиты src/usr.sbin/bluetooth FreeBSD пишет, судя по имени-фамилии, вроде наш соотечественник Maksim Yevmenkin <m_evmenkin@yahoo.com>. Исходники программного обеспечение для поддержки Bluetooth во FreeBSD суммарно имеют объём около 2 МБ и распространяются под «двухпунктовой» лицензией BSD.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Bluetooth стек src/sys/netgraph/bluetooth в ядре и утилиты src/usr.sbin/bluetooth FreeBSD пишет, судя по имени-фамилии, вроде наш соотечественник Maksim Yevmenkin <m_evmenkin@yahoo.com>. Исходники программного обеспечение для поддержки Bluetooth во FreeBSD суммарно имеют объём около 2 МБ и распространяются под «двухпунктовой» лицензией BSD.

Только вот они абсолютно несовместимы с линуксячьей сетевой подсистемой. Проще affix ковырять на предмет совместимости с существующим ядром. Так что оставим BSDшное BSDшникам.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Ну как раз dbus для embedded не так уж бесполезно. Вместо CORBA.

Фанат Холтмана? Нахер не нужно это раздутое, таскающее за собой кучу барахла в виде expat, glib и прочей пакости тормозное и неудобное г. Особенно оно не нужно в embedded.

По секрету, могу сказать что самое обычное ядро предоставляет несколько прекрасных, быстрых и ничего не весящих способов IPC, от unix sockets до shm.

Я понимаю, когда тот же glib пользуют на десктопе, потому что один хрен gtk уже есть - чего добру пропадать. Но когда это прикручивают к базовой системе - это тупость и дебилизм. Базовые системы типа bluetooth должны в даже в самом худшем случае зависеть только от libc.

Сетевому стеку и его юзерспейсным тулзам (или USB стеку и тулзам ) почему-то нафиг не нужны ни dbus, ни CORBA, ни всякие xmlи c glib'ами. Bluetooth ничем по сути не отличается от IP или USB. Возникает законный вопрос - какого, едрить, хрена всякие Холтманы откровенно засирают всякой дрянью отличную и продуманную систему?

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Всякий pairing и прочая, плюс оно должно при входящих коннектах от девайсов вызывать соответствующую софтину?

Точнее создавать устройство и дёргать софтину. В принципе всё верно inetd для синезуба.

В общем, где найти тех, с кем можно пообщаться на эту тему?

Как уже iZEN отметил с автором BT-стека под FreeBSD. Ну и со спекой по hci.

iBliss
()
Ответ на: комментарий от Stanson

glib засунут потому что кто то не осилил написать аналог libevent
вооще код http://www.kernel.org/pub/linux/bluetooth/bluez-4.98.tar.gz
легко портируется, glib покрайней мере отрезается запросто
насчет xml не всматривался но можно tinyxml прикрутить если надо

anonymous
()
Ответ на: комментарий от iBliss

BSD не катит, спеки читал, интересует как это сделано именно в bluez. В частности - интересно можно ли вообще не использовать hcid, конфигурируя единственный и неотключаемый hci0 вручную с помощью hciconfig, например. Удастся ли прописать pairing для заведомо известного удалённого девайса и пр? Тогда можно было бы ограничится выдёргиванием из bluez только sdpd-server и libbluetooth что сильно упростило бы задачу.

Stanson ★★★★★
() автор топика

Кстати, кому интересно - сырцы HFP - http://stanson.ch/files/AutomotivePC/hfp-mini-0.1.tar.gz

Оно только на воспроизведение, не дописаны всякие ответы на звонки, и пр. (это лишь дело техники - проблем дописать эту логику никаких, и я это сделаю легко), но работает - ищет телефон, коннектится и успешно воспроизводит звук с телефона. Можно музыку вопроизводить, например. Правда 8к 16бит моно для музыки не очень, но оно и не для этого.

Работает «искаропки», никаких колдунств с системой устраивать не надо. Никакие конфиги кроме собственного прогиного править не надо.

Телефон предварительно нужно спарить и прописать его BDADDR в конфиг или указать в параметрах проги.

Собственно исходников там 30 кил, написано всё очень просто и прозрачно. И вот сколько не думаю - понять не могу, КУДА там можно сунуть dbus, glib и прочее, не говоря уже о вопросе ЗАЧЕМ.

Чтобы сделать такое «штатными» средствами нужны будут зачем-то ofono, python и pulseaudio. Плюс гимор с настройками bluez, dbus и pulseaudio о которых толком никакой документации нету.

Доделаю до конца - будет валяться новая версия там же.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от anonymous

glib засунут потому что кто то не осилил написать аналог libevent

вооще код http://www.kernel.org/pub/linux/bluetooth/bluez-4.98.tar.gz легко портируется, glib покрайней мере отрезается запросто насчет xml не всматривался но можно tinyxml прикрутить если надо

Да, ничего сложного нету, просто объём немаленький и надо чётко понимать, что можно выкидывать, а что нет, поэтому требуются консультации со сведующими людьми.

xml парсер тащит за собой dbus собственно.

Ну и нафиг там ни xml, ни dbus, ни glib не нужны ни для чего. ifconfig и inetd ведь обходятся без этого и всё с ними просто отлично.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от anonymous

-rw-r--r-- 1 slapin slapin 247572 Дек 7 03:08 dbus-1_1.4.16-r0_armv5te.ipk -rw-r--r-- 1 slapin slapin 838452 Дек 6 17:53 libglib-2.0-0_2.30.0-r4_armv5te.ipk

Вполне даже маленькие. На железке с 16MB RAM весело крутятся, на пару с gstreamer и telepathy.

slapin ★★★★★
()
Ответ на: комментарий от Stanson

ну, запрос PIN при связывании девайсов использует dbus.

slapin ★★★★★
()
Ответ на: комментарий от Stanson

С парингом проблемы в основном с другой стороной = как ты организуешь PIN ы. остальное все настраивается руками. Разрешения на своей стороне - тоже.

slapin ★★★★★
()
Ответ на: комментарий от slapin

Вполне даже маленькие. На железке с 16MB RAM весело крутятся, на пару с gstreamer и telepathy.

Ну если там больше ничего нет и флеш большой - то да. Ну и новый bluez хочет glib2, а оно уже побольше. -rw-r--r-- 1 stanson stanson 298917 Feb 10 09:12 dbus_1.4.14-2_ar71xx.ipk -rw-r--r-- 1 stanson stanson 722807 Feb 5 00:21 glib2_2.26.1-2_ar71xx.ipk

Но это неважно - каков их размер. Главное что они не нужны вообще.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от slapin

ну, запрос PIN при связывании девайсов использует dbus.

Можно подумать что для реализации этого (особенно в случае такой базовой вещи как сетевой стек) действительно нужен именно dbus.

С парингом проблемы в основном с другой стороной = как ты организуешь PIN ы. остальное все настраивается руками. Разрешения на своей стороне - тоже.

А можно поподробнее?

PIN я организую - это не проблема. SDP сервер - тоже.

Остальное гораздо больше интересует - вот загрузились ядрёные драйвера. Дальше что? Что надо сказать в консоли, чтобы вручную привести систему в рабочее состояние в котором можно запустить SDP сервер и всё остальное?

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

Stanson ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.