Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider using zbus instead of dbus for easy cross compliation #7

Open
sinhpham opened this issue Jul 21, 2021 · 26 comments
Open

Consider using zbus instead of dbus for easy cross compliation #7

sinhpham opened this issue Jul 21, 2021 · 26 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@sinhpham
Copy link

sinhpham commented Jul 21, 2021 •
edited
Loading

bluer currently depends on dbus, which in turn depends on libdbus, a C library. As a result, cross compiling bluer is hard.

Please consider using a pure Rust alternative to dbus, zbus perhaps? https://crates.io/crates/zbus

See a related issue in a similar crate using dbus: hoodie/notify-rust#85
@laszlourszuly
Copy link

laszlourszuly commented Jul 22, 2021 •
edited
Loading

What do you mean by "cross compiling bluer is hard"? Cross compiling to different platforms (win, mac linux etc)?

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

@sinhpham
Copy link
Author

No not different platforms but different architectures. In our case they're various Raspberry Pi devices (RPi 3, 4, Zero), so armv7-unknown-linux-gnueabihf, armv5te-unknown-linux-gnueabi, maybe more.

  • For building/CI: you need correct linkers (plural, one with the host architecture for building crates with custom build.rs, one for the target architecture for libdbus), correct linker settings (don't forget the host & target linkers), correct libdbus version & architecture, correct paths, etc...
  • At runtime: sometimes we really want statically linked binary, similar to Support for musl hoodie/notify-rust#85. And libdbus is a deal breaker in those scenarios.

Would you be open to accepting PRs to switch dbus to zbus?

@laszlourszuly
Copy link

Thanks for clarifying! I'm just an eager follower of bluer project and can't answer your practical questions regarding PR's and such. Sorry.

@sinhpham
Copy link
Author

Haha no worries, I guess it's a question for @surban

@surban
Copy link
Collaborator

surban commented Jul 27, 2021

Yes, generally I am open for it, provided that no functionality is lost. I've successfully cross-compiled BlueR myself, but reducing C dependencies is a good idea in my opinion.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

@surban surban added the enhancement New feature or request label Jul 27, 2021
@surban surban added the help wanted Extra attention is needed label Oct 20, 2021
@zeenix
Copy link

zeenix commented Feb 2, 2022

Hi there, zbus developer here.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

This was added some months back in 2.0 beta and last month we had 2.0 stable release (finally). :) To be clear, that was the high-level API that was missing.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

However, I just checked and you're right that we don't support returning errors from property getters in dbus_interface currently. Nobody reported this or asked for this before today (when I just happen to stumble on this issue) so that's the only reason we missed out on this.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

@zeenix
Copy link

zeenix commented Feb 2, 2022

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

Now unix-specific but I'm about to merge the PR for windows support and CI. So the coming release should be quite portable in terms of OS.

@surban
Copy link
Collaborator

surban commented Feb 2, 2022

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

@zeenix
Copy link

zeenix commented Feb 2, 2022

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

Gotcha, thanks.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

Awesome! There is no hurry. :)

@surban
Copy link
Collaborator

surban commented Feb 4, 2022

Would you be open to accepting PRs to switch dbus to zbus?

@sinhpham Now that zbus is ready for use, would you be willing to provide some PRs? ;-)

@wash2
Copy link

wash2 commented Feb 2, 2023

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

@zeenix
Copy link

zeenix commented Feb 2, 2023

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

Pretty sure there is (right @surban?) but tbh I haven't yet gotten around to addressing https://gitlab.freedesktop.org/dbus/zbus/-/issues/251 yet. If you could contribute that first, that would be great. Otherwise, you'll have to either use low-level API for interface properties until the missing zbus support is added or wait till I get around to that.

@surban
Copy link
Collaborator

surban commented Feb 2, 2023

Yes, definitely!!!

But I agree with @zeenix that we should add missing features to zbus first. Using a low level API would make BlueR more complex without any benefit.

@wash2
Copy link

wash2 commented Feb 2, 2023

Ok I will look into that first 👍

@zeenix
Copy link

zeenix commented Feb 7, 2023

wow @wash2 wasn't messing around. Thanks to them, git main of zbus now supports fallible property getters. @surban There is a small gotcha that currently you can only return fdo::Error though but given that fdo:Error covers a lot of common errors and has a generic variant too, I'm hoping that's not a show-stopper here.

@zeenix
Copy link

zeenix commented Feb 11, 2023

just FYI I publish zbus 3.10.0 which includes the needed feature.

@zeenix
Copy link

zeenix commented Feb 22, 2023

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

@wash2
Copy link

wash2 commented Feb 22, 2023

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

Hi! To be honest, I have not made much progress on this in the last couple weeks. I will hopefully work on it more soon, but I'm worried that I won't be able to test everything that I'm changing 😅. I assume I will need some advice, so thank you for sharing the link :)

@zeenix
Copy link

zeenix commented Feb 22, 2023

but I'm worried that I won't be able to test everything that I'm changing sweat_smile

Let's hope @surban can help with that part. Maybe a Draft PR first?

I assume I will need some advice

I can certainly try my best to help with the D-Bus and zbus bits. Unfortunately don't know much about bluez.

@surban
Copy link
Collaborator

surban commented Feb 28, 2023

We don't have tests per se, but most of the functionality is exercised by the examples and tools. If they behave as before, you didn't break it ;)

For testing you don't need anything more that two Raspberry Pis and some basic knowledge of Bluetooth.

@jhartzell42
Copy link

Hi @wash2 , I'd be interested in collaborating on this.

@wash2
Copy link

wash2 commented Mar 20, 2023

Hi @wash2 , I'd be interested in collaborating on this.

@jhartzell42 Honestly, I really haven't had a chance to work on the PR yet, so if you'd like to work on it, go ahead. I would be happy to help where I can but I've unfortunately been very busy on some other projects 🥲

otaviojr added a commit to otaviojr/bluer that referenced this issue May 10, 2023
@otaviojr
# This is a combination of 62 commits.
71c8ca7 
# This is the 1st commit message:

BLE Passive Scanning

# This is the commit message #2:

monitor

# This is the commit message bluez#3:

monitor

# This is the commit message bluez#4:

monitor

# This is the commit message bluez#5:

monitor

# This is the commit message bluez#6:

monitor

# This is the commit message bluez#7:

monitor

# This is the commit message bluez#8:

monitor

# This is the commit message bluez#9:

monitor

# This is the commit message bluez#10:

monitor

# This is the commit message bluez#11:

monitor

# This is the commit message bluez#12:

monitor

# This is the commit message bluez#13:

monitor

# This is the commit message bluez#14:

monitor

# This is the commit message bluez#15:

monitor

# This is the commit message bluez#16:

monitor

# This is the commit message bluez#17:

monitor

# This is the commit message bluez#18:

monitor

# This is the commit message bluez#19:

monitor

# This is the commit message bluez#20:

monitor

# This is the commit message bluez#21:

monitor

# This is the commit message bluez#22:

monitor

# This is the commit message bluez#23:

monitor

# This is the commit message bluez#24:

monitor

# This is the commit message bluez#25:

monitor

# This is the commit message bluez#26:

monitor

# This is the commit message bluez#27:

monitor

# This is the commit message bluez#28:

monitor

# This is the commit message bluez#29:

monitor

# This is the commit message bluez#30:

monitor

# This is the commit message bluez#31:

monitor

# This is the commit message bluez#32:

monitor

# This is the commit message bluez#33:

monitor

# This is the commit message bluez#34:

monitor

# This is the commit message bluez#35:

monitor

# This is the commit message bluez#36:

monitor

# This is the commit message bluez#37:

monitor

# This is the commit message bluez#38:

monitor

# This is the commit message bluez#39:

monitor

# This is the commit message bluez#40:

monitor

# This is the commit message bluez#41:

monitor

# This is the commit message bluez#42:

monitor

# This is the commit message bluez#43:

monitor

# This is the commit message bluez#44:

monitor

# This is the commit message bluez#45:

monitor

# This is the commit message bluez#46:

monitor

# This is the commit message bluez#47:

monitor

# This is the commit message bluez#48:

monitor

# This is the commit message bluez#49:

monitor

# This is the commit message bluez#50:

monitor

# This is the commit message bluez#51:

monitor

# This is the commit message bluez#52:

monitor

# This is the commit message bluez#53:

monitor

# This is the commit message bluez#54:

monitor

# This is the commit message bluez#55:

monitor

# This is the commit message bluez#56:

monitor

# This is the commit message bluez#57:

monitor

# This is the commit message bluez#58:

monitor

# This is the commit message bluez#59:

monitor

# This is the commit message bluez#60:

monitor

# This is the commit message bluez#61:

monitor

# This is the commit message bluez#62:

monitor
@Athorus
Copy link

Athorus commented Feb 25, 2024

Hello, any news about zbus ?
I would like to cross compile from x64 linux to raspberry zero, so it would help a lot.

I was used to compile for target arm-unknown-linux-gnueabi, but since bookworm, ld-linux.so.3 file lib is no longer available on raspberry, so I cannot use anymore the package libdbus-1-dev:armel on compilation host.

Maybe buildroot can do the job…

@zeenix
Copy link

zeenix commented Feb 25, 2024

@Athorus I think it's just waiting on someone to do the work.

@surban
Copy link
Collaborator

surban commented Feb 26, 2024 •
edited
Loading

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

@Athorus
Copy link

Athorus commented Feb 26, 2024

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

It works for Raspberry pi Zero 2, because aarch64 is compiled with same options, but doern’t work for armhf, because Raspberry Pi armhf (arm v6 + hf) is not compiled with same options as standard Debian armhf (arm v7).
In bulleyes I used the trick to compile to armel (arm v5 without hf), but doesn’t work anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@zeenix @jhartzell42 @sinhpham @laszlourszuly @surban @Athorus @wash2