tree: c71ea93fd777c820aef700cd44474459ba5c377e [path history] [tgz]
  1. telemetry/
  2. BUILD.gn
  3. core.cc
  4. core.h
  5. core_delegate_impl.cc
  6. core_delegate_impl.h
  7. core_test.cc
  8. daemon.cc
  9. daemon.h
  10. dbus_service.cc
  11. dbus_service.h
  12. dbus_service_test.cc
  13. ec_constants.cc
  14. ec_constants.h
  15. ec_constants_test.cc
  16. fake_browser.cc
  17. fake_browser.h
  18. fake_diagnostics_service.cc
  19. fake_diagnostics_service.h
  20. fake_probe_service.cc
  21. fake_probe_service.h
  22. fake_wilco_dtc.cc
  23. fake_wilco_dtc.h
  24. grpc_client_manager.cc
  25. grpc_client_manager.h
  26. grpc_service.cc
  27. grpc_service.h
  28. grpc_service_test.cc
  29. json_utils.cc
  30. json_utils.h
  31. main.cc
  32. mock_mojo_client.cc
  33. mock_mojo_client.h
  34. mojo_grpc_adapter.cc
  35. mojo_grpc_adapter.h
  36. mojo_service.cc
  37. mojo_service.h
  38. mojo_service_factory.cc
  39. mojo_service_factory.h
  40. mojo_service_test.cc
  41. probe_service.h
  42. probe_service_impl.cc
  43. probe_service_impl.h
  44. probe_service_impl_test.cc
  45. README.md
  46. routine_service.cc
  47. routine_service.h
  48. routine_service_test.cc
  49. service_util.h
diagnostics/wilco_dtc_supportd/README.md

wilco_dtc_supportd daemon

Warning: This document is old & has moved. Please update any links:
https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/diagnostics/wilco_dtc_supportd/README.md

Please see ../README.md for general information.

IPC mechanisms

This daemon uses three IPC mechanisms:

  • gRPC - for talking to the wilco_dtc daemon.
  • Mojo - for talking to the browser.
  • D-Bus - for receiving Mojo bootstrap requests from the browser.

Class structure

`Daemon`
 ^
 |
 v
`Core`
 ^
 |
 |   // gRPC-related members:
 +-> `GrpcService`
 |       (handles incoming gRPC requests)
 +-> `AsyncGrpcServer<grpc_api::WilcoDtcSupportd>`
 |       (connects `GrpcService` with the actual gRPC
 |        pipe)
 +-> `AsyncGrpcClient<grpc_api::WilcoDtc>`
 |       (sends outgoing gRPC requests through the actual gRPC pipe)
 |
 |   // Mojo-related members:
 +-> `MojoService`
 |       (handles incoming Mojo requests and sends outgoing ones)
 +-> `mojo::Binding<mojom::WilcoDtcSupportdService>`
 |       (connects `MojoService` with the actual Mojo pipe)
 +-> `RoutineService`
 |       (handles diagnostics routines requests to cros_healthd)
 +-> `ProbeService`
 |       (handles probe requests to cros_healthd)
 |
 |   // D-Bus-related members:
 +-> `DBusService`
 |       (handles incoming D-Bus requests)
 +-> `brillo::dbus_utils::DBusObject`
         (connects `DBusService` with the actual D-Bus pipe)

Classes are generally organized such that they don't know about their owners or siblings in this graph. Instead, these classes are parameterized with delegate(s), which implement these cross-class calls. This allows to test each individual piece of logic separately.