Linux platform support #2098
Linux platform support #2098
Conversation
The build directories should not be commited and definitly not pushed to remote. This will prevent that from accidentally happening, and will declutter `git status`
This is the start of the implementing for the Linux platform. I aim to make this as similar to the Windows platform as possible, although due to the fundamental difference in the two OS's, there will be things that need to be different. As such, I will be using the Windows platform files as a base, and reimplementing the functions with Linux equivalents. I am sure this will have bugs, which by my best attempt will be fixed when found.
There was no free after we were finished with the interface pointer
There are a couple of places where apps can store data in Linux, one is in the HOME directory, which is being phased out, the second, is in HOME/.config, and the other is HOME/.local/share. This uses HOME/.local/share, and since there isn't a common appdata path on Linux that function will just return the local appdata path.
This adds a Linux equivalent to file path operations done in the Windows headers and source files. Some differences that will occur are the invalid path names and contents, as there are no invalid path names, and only one invalid path content (excluding non-printable characters) on Linux.
The `http_loader` class takes a `WebRequest` with information to send a web request, and sends it. This uses `libcurl`, which is present from installation on most major Linux distrobutions (e.g. Fedora, Ubuntu, PopOS...). If libcurl is not present on the target system, it will need to be installed.
A file was named wrong. It was changed.
The Windows implementation of the Timer class (in timer.h) used Timer Queues. This brings in implementation for a mostly Windows complient TimerQueue class to work with the Timer class.
This are unimplemented currently, but will be in the future.
I missed some implementation when I was looking over them. These are them.
This file contains additional methods that our Characteristic server interfaces don't support yet.
|
I have removed |
|
This looks promising! |
|
Hi! I was wondering if it would be possible to split up this PR into the following:
This would make this much easier to review (if you still would like to get this code merged), thanks! |
Summary
This PR adds an implementation geared towards Desktop Linux systems in
internal/platform/implementation/linux. The motivation behind the code is to rely on widely available interfaces to implement mediums, and to use D-Bus as the primary transport for talking to system services. The code is broadly untested (and undocumented!), and is currently missing an implementation for the Bluetooth Low Energy medium, as I still haven't gotten around to understanding BlueZ's LE interfaces, parts of which are currently marked as experimental.The implementation tries to rely on as few external libraries as possible, and as such, pulls in
sdbus-c++,libsystemd, andlibcurlviapkg-configrules added toWORKSPACE.Additionally, the branch also includes a prototype forconnectionsd, a daemon that will expose a D-Bus interface for theconnectionsv1 and v3 APIs, centralizing resource management and providing a portable API for app developers.To help aid understanding, here's a list of the main
ImplementationPlatformcomponents and the services/APIs used to implement them:Classic Bluetooth
api::BluetoothAdapter: Backed by theorg.bluez.Adapter1interface.api::BluetoothDevice: Usesorg.bluez.Device1.org.bluez.Device1, with sockets implemented by registeringorg.bluez.Profile1withorg.bluez.ProfileManager1(documented here). AProfileManageris in charge of tracking registered services, and any connections/sockets created on the same per device.org.bluez.Device1.Networking
NetworkManageras its status as the de-facto network configuration service on Linux desktops.NetworkManagerD-Bus APIs.api::WifiLanuses the Avahi's D-Bus interfaces for performing service discovery and advertising.api::DeviceInfoorg.freedesktop.login1(implemented by systemd-logind).org.freedesktop.hostname1(implemented by systemd-hostnamed).Miscellaneous
api::LogMessage: AllLogMessages are sent to aglogLogSinkthat implements theorg.freedesktop.LogControl1D-Bus interface, to allow the log target and severity threshold to be externally controlled via the default bus connection (at the namecom.google.nearby).libcurl.TODOs
BluetoothAdapter::SetNameconnectionsd.connectionsdgeneratedfolder.api::CredentialStorage, preferably usingorg.freedesktop.Secret.Service