From 0e39ff0ef856b9b4abff507e1707d0744f12a726 Mon Sep 17 00:00:00 2001 From: Richard Hughes Date: Thu, 12 Mar 2020 08:43:06 +0000 Subject: [PATCH] trivial: Add a section on using a compat layers in fwupd --- docs/fwupd-docs.xml | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/fwupd-docs.xml b/docs/fwupd-docs.xml index 541a189a0..129aa40f2 100644 --- a/docs/fwupd-docs.xml +++ b/docs/fwupd-docs.xml @@ -432,6 +432,38 @@ fu_plugin_update_reload (FuPlugin *plugin, FuDevice *device, GError **error) +
+ Using existing code to develop a plugin + + It is not usually possible to share a plugin codebase with + firmware update programs designed for other operating systems. + Matching the same rationale as the Linux kernel, trying to use one + code base between projects with a compatibility shim layer in-between + is real headache to maintain. + + + The general consensus is that trying to use a abstraction layer for + hardware is a very bad idea as you're not able to take advantage of the + platform specific helpers -- for instance quirk files and the custom + GType device creation. + The time the vendor saves by creating a shim layer and + importing existing source code into fwupd will be overtaken 100x by + upstream maintenance costs longer term, which isn't fair. + + + In a similar way, using C++ rather than GObject C means expanding the + test matrix to include clang in C++ mode and GNU g++ too. + It's also doubled the runtime requirements to now include both the C + standard library as well as the C++ standard library and increases the + dependency surface. + + + Most rewritten fwupd plugins at up to x10 smaller than the standalone + code as they can take advantage of helpers provided by fwupd rather + than re-implementing error handling, device quirking and data chunking. + +
+