pon., 2 mar 2020 o 12:25 Otavio Salvador <otavio.salva...@ossystems.com.br> napisał(a): > > On Mon, Mar 2, 2020 at 4:37 AM Bartosz Golaszewski <b...@bgdev.pl> wrote: > > niedz., 1 mar 2020 o 14:43 Otavio Salvador > > <otavio.salva...@ossystems.com.br> 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? Bart -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel