diff mbox series

doc: provide more details and info to the proposals

Message ID 20240707122741.158905-1-stefano.babic@swupdate.org
State Accepted
Headers show
Series doc: provide more details and info to the proposals | expand

Commit Message

Stefano Babic July 7, 2024, 12:27 p.m. UTC
Try to better describe possible improvements for the project.
Add status for each feature to notify if something is already planned to
be implemented or is waiting for interest and/or sponsors.

This should clarify if a feature is already planned and will be part of
a next release.

Signed-off-by: Stefano Babic <stefano.babic@swupdate.org>
---
 doc/source/improvement_proposals.rst | 201 ++++++++++++++++++++++++++-
 1 file changed, 194 insertions(+), 7 deletions(-)

--
2.34.1
diff mbox series

Patch

diff --git a/doc/source/improvement_proposals.rst b/doc/source/improvement_proposals.rst
index 87fb6582..29de551e 100644
--- a/doc/source/improvement_proposals.rst
+++ b/doc/source/improvement_proposals.rst
@@ -1,4 +1,4 @@ 
-.. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <stefano.babic@swupdate.org>
+.. SPDX-FileCopyrightText: 2013-2024 Stefano Babic <stefano.babic@swupdate.org>
 .. SPDX-License-Identifier: GPL-2.0-only

 =============================
@@ -11,10 +11,63 @@  There is no plan when these features will be implemented - this depends
 if there will be contribution to the project in terms of patches or
 financial contributions to develop a feature.

+Each item listed here contains a status and if the feature is already planned or
+I am looking for sponsor to implement it. This should avoid double work and make
+more transparent what is going on with the project.
+
+If you have further ideas about the project, just send your proposal to the
+Mailing List or post a patch for this document.
+
 Thanks again to all companies that have supported my work up now and to
 everybody who has contributed to the project, let me bring SWUpdate
 to the current status !

+Legende
+=======
+
+.. table:: Feature's status
+
+   +-------------+---------------------------------------------------------------+
+   |  Value      | Description                                                   |
+   +=============+===============================================================+
+   |  Wait       |  No activity is planned, just proposal                        |
+   +-------------+---------------------------------------------------------------+
+   |  Design     | Design / Concept is done                                      |
+   +-------------+---------------------------------------------------------------+
+   |  Planned    | Feature will be implemented soon                              |
+   +-------------+---------------------------------------------------------------+
+   |  WIP        | Feature is current to be implemented and will be posted       |
+   +-------------+---------------------------------------------------------------+
+   |  Running    | Implemented                                                   |
+   +-------------+---------------------------------------------------------------+
+
+.. table:: Request for Support
+
+   +-------------+---------------------------------------------------------------+
+   |  Value      | Description                                                   |
+   +=============+===============================================================+
+   |  None       | No sponsoring required                                        |
+   +-------------+---------------------------------------------------------------+
+   |  Sponsor    | Looking for sponsors to finance the feature                   |
+   +-------------+----------+----------------------------------------------------+
+   |  Planned    | Feature is already sponsored                                  |
+   +-------------+---------------------------------------------------------------+
+
+
+.. table:: Priority
+
+   +-------------+---------------------------------------------------------------+
+   |  Value      | Description                                                   |
+   +=============+===============================================================+
+   |  Low        | Probably just an idea, feedback from community asked          |
+   +-------------+---------------------------------------------------------------+
+   |  Medium     | Not critical, but nice feature to have                        |
+   +-------------+----------+----------------------------------------------------+
+   |  High       | Critical feature, it should be implemented soon               |
+   +-------------+---------------------------------------------------------------+
+
+
+
 Main goal
 =========

@@ -23,6 +76,9 @@  SWUpdate suitable for a large number of products.
 This will help to build a community around the project
 itself.

+* Status : Running
+* Request for Support : None
+
 Core features
 =============

@@ -31,6 +87,10 @@  Support for OpenWRT

 OpenWRT is used on many routers and has its own way for updating that is not power-cut safe.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Low
+
 Software-Software compatibility
 -------------------------------

@@ -40,6 +100,10 @@  a sort of software compatibility check. For example, SWUpdate verifies if a comp
 (like an application) is compatible with a runningOS and reject the update in case of
 mismatch.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
 Support files bigger than 4GB
 -----------------------------

@@ -47,6 +111,10 @@  SWUpdate currently uses CPIO to pack updates in the 'newc' and 'crc' formats.
 These formats limit single files to 4GB - 1byte in size, which could become a
 problem as update size grows.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : High
+
 Parser
 ======

@@ -54,15 +122,67 @@  SWUpdate supports two parsers : libconfig and JSON. It would be nice if tools ca
 be used to convert from one format to the other one. Currently, due to some specialties
 in libconfig, a manual conversion is still required.

+* Status: Wait
+* Request for Support : None
+* Priority : Medium
+
 Fetcher and interfaces
 ======================

-- No plan
+Selective downloading
+---------------------
+
+SWUpdate starts to fetch the whole SWU and process it until an error is found. There are some requests
+to have a selective downloading, that means SWUpdate will load just the chunks are needed and not
+the whole SWU. An example for this use case is in case a single SWU contains software for
+multiple devices, and each of them needs a subset of the whole SWU. Like the delta handler,
+SWUpdate knows from sw-description which artifacts are to be installed, and reading the stream
+could decide to skip unnecessary components.
+
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium

 Tools and utilities
 ===================

-- No plan
+Single tool to create SWU
+-------------------------
+
+SWUGenerator is a separate project that helps to create SWUs. It is used on not OE projects. In OE,
+the SWU is created using code in meta-swupdate. This leads to a duplication of code with higher
+effort to maintain.
+
+Even if it was tried to have the same features, there are some important differences:
+
+- SWUGenerator is able to full understand a sw-description written in libconfig language and to rewrite it.
+  This means it is not yet possible to write sw-description using JSON if SWUGenerato is planned.
+  However, it is possible to split sww-description in small files (for example for the embedded Lua code),
+  and SWUGenerato is able to write the final sw-description combined all include files.
+- meta-swupdate is just able to replace variables known by bitbake, but it has no semantic knowledge.
+  It is not possible to use @include directive, but it is possible to use JSON as language.
+
+The logical step will be to use a single tool (SWUGenerator), and let meta-swupdate to use it. To do this,
+SWUGenerator should be enhance to understand and write sw-description in JSON, too.
+
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
+Further enhancement to SWUGenerator
+-----------------------------------
+
+SWUGenerator is thought to support multiple subcommands, but it currently supports just "create".
+It is thinkable, even if this can be done with other tools, to implement further commands like:
+
+- extract: take a SWU and extracts all artifacts in a directory
+- sign: take a SWU and resign with a new key. This is useful when it is required to install a new
+  Software, but the certificate or the key on the device is older and rejects the installation.
+- verify: just verify if the SWU is correctly signed.
+
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium

 Lua
 ===
@@ -70,6 +190,10 @@  Lua
 - API between SWUpdate and Lua is poorly documented.
 - Store in SWUpdate's repo Lua libraries and common functions to be reused by projects.

+* Status : Running
+* Request for Support : None
+* Priority : Medium
+
 Handlers:
 =========

@@ -87,6 +211,10 @@  Some ideas for new handlers:
         - Lua handlers should be added if possible to the project
           to show how to solve custom install.

+* Status : Running
+* Request for Support : None
+* Priority : Low
+
 Handlers installable as plugin at runtime
 ------------------------------------------

@@ -103,6 +231,9 @@  Current release supports verified images. That means that a handler
 written in Lua could be now be part of the compound image, because
 a unauthenticated handler cannot run.

+* Status : Running
+* Request for Support : None
+
 Support for BTRFS snapshot
 --------------------------

@@ -110,20 +241,28 @@  BTRFS supports subvolume and delta backup for volumes - supporting subvolumes is
 to move the delta approach to filesystems, while SWUpdate should apply the deltas
 generated by BTRFS utilities.

+* Status: Design
+* Request for Support : Planned
+* Priority : Medium
+
 Security / Crypto engines
 =========================

 - add support for asymmetryc decryption
 - rework support for crypto engine - let possible to load multiple libraries at
   the same time. Currently, there is support for openSSL, WolfSSL and mbedTLS.
-  However, WolfSSL are mising together. There should be a way to select one or more
+  However, WolfSSL are missing together. There should be a way to select one or more
   libraries and independently the algorithms that SWUpdate should support.
   Some hacks are currently built to avoid conflicts (pkcs#7 and CMS are the same
   thing, but supported by different libraries), and they should be solved.
-- add more algorythms for decryption, as AES-CTR can be very useful to decrypt
+- add more algorithms for decryption, as AES-CTR can be very useful to decrypt
   chunks in delta updates.
 - Support for TPM2 to store secrets (requires rework above).

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : High
+
 Back-end support (suricatta mode)
 =================================

@@ -135,6 +274,10 @@  This means that the IPC does not answer if Suricatta is doing something, special
 downloading and upgrading the system. This can be enhanced adding a separate thread for IPC and of course
 all required synchronization with the main modules.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
 Back-end: check before installing
 ---------------------------------

@@ -143,6 +286,10 @@  if an update must be installed instead of installing and performs checks later.
 If SWUpdate provides a way to inform a checker if an update can be accepted
 before downloading, a download is only done when it is really necessary.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
 Back-end: hawkBit Offline support
 ---------------------------------

@@ -152,13 +299,33 @@  the hawkBit's server. Currently, hawkBit thinks to be the only one
 deploying software. hawkBit DDI API should be extended, and afterwards
 changes must be implemented in SWUpdate.

-Back-end: support for generic down-loader
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Low
+
+Back-end: support for generic down-loader
 -----------------------------------------

 SWUpdate in down-loader mode works as one-shot: it simply try to download a SWU
 from a URL. For simple applications, it could be moved into `suricatta` to detect
 if a new version is available before downloading and installing.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
+Back-end: further connectors
+----------------------------
+
+Further connectors could be implemented. The structure in SWUpdate
+is modular, and allows to write new connectors, even in Lua. New connectors could be
+added if there are requests in this direction.
+
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Low
+
+
 Test and Continuous Integration
 ===============================

@@ -170,9 +337,29 @@  More in this direction must be done to perform test on targets. A suitable test
 should be found. Scope is to have a "SWUpdate factory" where patches are fast integrated
 and tested on real hardware.

+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
+Binding to languages
+====================
+
+libswupdate allows to write an application that can control SWUpdate's behavior and be informed
+about a running update. There are bindings for C/C++, Lua and nodejs (just progress).
+
+Applications can be written in other languages, and binding to Python and Rust can be
+implemented, too.
+
+* Status: Wait
+* Request for Support : Sponsor
+* Priority : Medium
+
 Documentation
 =============

-Documentation is a central point in SWUpdate - maintaining it up to date is a must in this project.
+Documentation is a central point in SWUpdate - maintaining it up to date is a must in this project.
 Help from any user fixing wrong sentence, bad english, adding missing topics is high
 appreciated.
+
+* Status : Running
+* Request for Support : None