snapd icon indicating copy to clipboard operation
snapd copied to clipboard

interfaces/builtin: add usbmuxd interface

Open qmfrederik opened this issue 4 years ago • 3 comments

This patch adds the usbmuxd interface, providing access to iOS devices.

Multiple applications can access the same iOS device at the same time. To avoid concurrency issues, access to iOS devices via USB is managed by usbmuxd, the USB multiplexing daemon. This daemon has exclusive access to the devices, and exposes the /var/run/usbmuxd socket, which can be used by client applications.

The implementation is modeled after the docker interface. There isn't an usbmuxd-support interface yet; that could come as a follow-up PR. Meanwhile, this should unblock scenarios where usbmuxd has been installed via the traditional package managers.

qmfrederik avatar Sep 21 '20 20:09 qmfrederik

I signed the CLA just before submitting the PR, hopefully CI gets notified ;-).

qmfrederik avatar Sep 21 '20 20:09 qmfrederik

Thanks for the prompt reply!

It seems that although currently usbmuxd is not a snap package, there is a good chance one will exist if work on a usbmuxd-support interface is planned or being explored

Absolutely, I'd actually consider contributing such a package once the infrastructure is in place.

The upstream libimobiledevice/usbmuxd project frequently provides patches which give you compatibility with new versions of iOS, but these patches often do not make it to the Linux distro's - so I assume it would be a great candidate for a snap.

It's perhaps worth mentioning that the default usbmuxd daemon will only start when you connect an iOS device to your computer, and shut down when you disconnect the latest device. Not sure whether this is a behavior that could be replicated by a snap package.

we need to finish having an internal conversation about how to handle these kinds of interfaces allowing access to a global resource

Just so I get my expectations right, what timeline would you anticipate here?

qmfrederik avatar Sep 21 '20 20:09 qmfrederik

which would eventually open up for the possibility of introducing a snapped daemon with a different socket path.

Does this mean you consider the possibility of having two daemons running at the same time, one deployed via a snap package and one deployed via a traditional Linux package?

qmfrederik avatar Sep 28 '20 11:09 qmfrederik

is there still interest in this? there was no more discussion here

pedronis avatar Sep 07 '23 12:09 pedronis

@qmfrederik I'll close this soon if there is no communication from you, is this still relevant?

Meulengracht avatar Feb 21 '24 08:02 Meulengracht

@Meulengracht I think the problem is still relevant, but I'm working on other things nowadays, so I'll close the PR.

qmfrederik avatar Feb 21 '24 09:02 qmfrederik

If it ever becomes relevant again feel free to reopen

Meulengracht avatar Feb 21 '24 10:02 Meulengracht