blob: 59ba63ce85aaf1380fed99f2c82805f2e2705076 [file] [log] [blame]
/*
* Copyright (C) 2021 CESNET, https://photonics.cesnet.cz/
*
* Written by Tomáš Pecka <tomas.pecka@fit.cvut.cz>
*
*/
#pragma once
#include <map>
#include <sdbus-c++/sdbus-c++.h>
#include <string>
#include <variant>
#include "utils/log-fwd.h"
namespace velia::system {
class RAUC {
public:
using SlotProperties = std::map<std::string, std::variant<std::string, uint64_t, uint32_t>>;
RAUC(sdbus::IConnection& signalConnection, sdbus::IConnection& methodConnection, std::function<void(const std::string&)> operCb, std::function<void(int32_t, const std::string&)> progressCb, std::function<void(int32_t, const std::string&)> completedCb);
std::string primarySlot() const;
std::map<std::string, SlotProperties> slotStatus() const;
void install(const std::string& source);
void mark(const std::string& how, const std::string& what);
std::string operation() const;
std::string lastError() const;
private:
/* We have two objects on two connections here intentionally. On a D-Bus signal PropertyChanged we invoke a callback that does something
* with Sysrepo's operational datastore in velia::system::Firmware class. While executing this code, sdbus-c++'s mutex (sdbus-c++ src/SdBus.h, sdbusMutex_) is locked.
* However, this operational datastore change invokes a code, that (again) calls a D-Bus method via sdbus-c++ on the same sdbus::IProxy object.
* Calling method on this object would require to acquire the same mutex that is already held, which results in deadlock.
* Therefore, we maintain two separate connections to the same D-Bus object. The first one is used for handling signal callbacks and
* the second is only for calling the D-Bus methods.
*/
std::shared_ptr<sdbus::IProxy> m_dbusObjectProxySignals, m_dbusObjectProxyMethods;
std::function<void(const std::string&)> m_operCb;
std::function<void(int32_t, const std::string&)> m_progressCb;
std::function<void(int32_t, const std::string&)> m_completedCb;
velia::Log m_log;
};
}