On 3/2/20 9:39 AM, Bartosz Golaszewski wrote:
pon., 2 mar 2020 o 12:25 Otavio Salvador
<[email protected]> napisał(a):
On Mon, Mar 2, 2020 at 4:37 AM Bartosz Golaszewski <[email protected]> wrote:
niedz., 1 mar 2020 o 14:43 Otavio Salvador
<[email protected]> napisał(a):
This single class surely doesn't justify a new layer but I have a
bunch of other stuff lined up for upstreaming if this is accepted.
This is thematically separate from most of the recipes in meta-oe too.
So please give us an idea of what are your plans, so we can understand
it better.
Sure. Next steps would be:
- Adding a class for generating provisioning partition images.
Basically allowing to split parts of the rootfs into separate ext4 (or
other) image similar to what meta-mender does in its mender-dataimg
class for /data but generalized for configurable directories.
- Adding an image recipe for a factory reset system, where we would
store the provisioning rootfs on a read-only partition together with
an initramfs the role of which would be to reflash the A/B partitions
to bring the device to a known state, this is something we do a lot in
our consulting work.
- Adding standardized target-side scripts for applying binary-delta
images. This uses the fact that many OTA frameworks support extensions
to their client programs. For instance the same script could be used
for applying the vcdiff and rsync patches both as a mender update
module and a rauc handler (with a thin compatibility layer in their
respective OE layers).
It still doesn't exhaust the subject but I think this really makes
sense in a separate layer than being sprinkled all-over meta-oe.
Khem, Armin: any thoughts?
there are many ota layers on OE, most of them are self-contained, so a
question arises, how is this different, somethings here say it could be
a base layer for all OTAs, which actually seems quite valuable, but it
has to be such that the existing OTA layers start using pieces from this
layer, Other part seems to be that its yet another OTA using binary
delta update techniques, so in such a case, it should be thought of as
another OTA and perhaps maintained independendently, if there are
features which are common across all OTAs we can host them in core or
meta-oe,
Bart
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
