| # Hacking debugd |
| |
| [iface]: ../dbus_bindings/org.chromium.debugd.xml |
| [impl]: implementation.md |
| [design]: design.md |
| [makefile]: ../BUILD.gn |
| |
| If you're reading this doc, you hopefully want to add a new feature to debugd |
| (or fix a bug). You should have a look at [the implementation doc][impl] and |
| [the design doc][design], and perhaps the existing [interface][iface]. |
| |
| The first and most important question to ask yourself is whether the thing |
| you're trying to do belongs in debugd. We sandbox debugd, but it still has |
| access to many privileged parts of the system, which means any code in debugd |
| exposes a large attack surface. In general, you should aim to have as little |
| code as possible in debugd - if you need elevated privileges to get a piece of |
| data, add an accessor for that piece of data in debugd, and do any analytics you |
| need elsewhere. |
| |
| Once you've looked at those documents and pondered that question, here's how |
| you'd go about adding a new piece of data debugd can return: |
| |
| 1. Decide whether it fits logically with an existing piece of data we return. If |
| so, you're going to want to hack the tool that returns the existing data; if |
| not, you're going to need to add a new tool. |
| |
| 2. If you're adding a new tool, add it to the `static_library("libdebugd")` |
| sources in [`/BUILD.gn`][makefile]. You will also need to add an entry in |
| [`/dbus_bindings/org.chromium.debugd.xml`][iface] for every method you create. |
| Tools follow the general pattern of having a header called `/src/foo_tool.h` and |
| an implementation file called `/src/foo_tool.cc`. |
| |
| 3. If you're doing anything at all complicated, add a helper (see |
| `/src/helpers`), and use `ProcessWithOutput` (see `/src/process_with_output.h`) |
| to capture its output before returning it over DBus. Helpers are subprograms |
| that we can launch in sandboxes. |
| |
| 4. Once you've added your new tool (or hacked an existing one) and added your |
| new helper (if necessary), write an autotest (or extended the existing |
| `platform_DebugDaemon` test) to cover the feature you added. |
| |
| 5. Test, review, submit. |
| |
| 6. Hack the debugd ebuild to install your new helper (if applicable). |