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 <
stefan...@swupdate.org>
---
doc/source/improvement_proposals.rst | 201 ++++++++++++++++++++++++++-
1 file changed, 194 insertions(+), 7 deletions(-)
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 <
stefan...@swupdate.org>
+.. SPDX-FileCopyrightText: 2013-2024 Stefano Babic <
stefan...@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
--
2.34.1