WIP: Update to zbus git #142
Conversation
There is an issue with non-Send future
| @@ -36,7 +34,7 @@ pub struct Bus { | |||
| // All (cheaply) cloneable fields of `Bus` go here. | |||
| #[derive(Clone, Debug)] | |||
| pub struct Inner { | |||
| address: Address, | |||
| address: String, | |||
There was a problem hiding this comment.
This is not acceptable to me. We should move from generic strings to specific types, not the other way around.
There was a problem hiding this comment.
yeah, but this is going to be refactored next when I rebase the config, to support multiple listenable address (same as dbus-daemon, apparently the last is printed in --print-address).
There was a problem hiding this comment.
hmm.. I'm not sure I want that. We should only support 1 address at a time. I want to keep things simpler. Unless there is a compelling use case for this?
There was a problem hiding this comment.
well, I have some use cases in mind, like allowing the guest services to connect to a host VM bus (think qemu / spice agents etc)
There was a problem hiding this comment.
That sounds good at first but giving raw direct access to the host's system bus would be a bad idea, security wise. Even for session, it can be argued that it's not good. There is a reason why xdg-dbus-proxy exists since people don't even want apps running on the same host, unfiltered access to the bus. So I wonder if there could better solutions for this, especially ones that don't require listening to multiple connections.
Also to keep in mind that you wouldn't want users to have to modify the dbus configuration but rather make everything work out of the box.
There was a problem hiding this comment.
no, it is a private bus
That's cool, but then why does it need to listen on multiple addresses?
There was a problem hiding this comment.
so the guest services can connect to the host bus, and management apps can use regular unix socket.
There was a problem hiding this comment.
so the guest services can connect to the host bus
You mean through vsock? I am not sure why qemu does it differently but the Firecracker's way of using a plain unix socket on the host side for vsock, makes a lot of sense to me. That will also solve this issue.
There was a problem hiding this comment.
You need some kind of vsock<->unix bridge for that, and you loose direct peer details.
There was a problem hiding this comment.
You need some kind of vsock<->unix bridge for that, and you loose direct peer details.
like peer credentials? I thought that's not possible and why we use anonymous auth with vsock. 🤔
Fixed your regression for you: dbus2/zbus#1036 :) |
weird stuff... why does it need to be declared Send+Sync+'static?? why isn't it infered like the rest ... |
Because you're the one declaring the type explicitly and therefore get to decided the guarantees. I know it's painful and annoying.. |
|
I rebased this branch on main here. It builds but all the tests fail/hang. I haven't investigated what the issue is but pretty sure it's some minor thing in either the branch or regression in zbus. |
I investigated this and it is indeed a regression in zbus main. dbus2/zbus#1055. |
This has been fixed in zbus git main, and my branch passes the tests. However, I have not addressed the review comments here, just made it build and pass the CI locally. I'd suggest resetting this branch to mine before addressing the review comments. |
|
Closing in favor of #151. |
There is an issue with a non-Send future..