I've already updated the docs and will submit the patch as soon as this series is approved and merged.
Vyacheslav On Fri, Aug 6, 2021, 16:06 Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Fri, 2021-08-06 at 15:00 +0200, Michael Opdenacker wrote: > > Slava, Richard, > > > > On 8/6/21 2:06 PM, Vyacheslav Yurkov wrote: > > > It's often desired in Embedded System design to have a read-only > rootfs. > > > But a lot of different applications might want to have a read-write > access > > > to some parts of a filesystem. It can be especially useful when your > update > > > mechanism overwrites the whole rootfs, but you want your application > data > > > to be preserved between updates. This class provides a way to achieve > that > > > by means of overlayfs and at the same time keeping the base rootfs > read-only. > > > > > > Signed-off-by: Vyacheslav Yurkov <uvv.m...@gmail.com> > > > --- > > > meta/classes/overlayfs.bbclass | 111 +++++++++++++++++++++++++++++++++ > > > 1 file changed, 111 insertions(+) > > > create mode 100644 meta/classes/overlayfs.bbclass > > > > > > diff --git a/meta/classes/overlayfs.bbclass > b/meta/classes/overlayfs.bbclass > > > new file mode 100644 > > > index 0000000000..8d9b59c9bf > > > --- /dev/null > > > +++ b/meta/classes/overlayfs.bbclass > > > @@ -0,0 +1,111 @@ > > > +# Class for generation of overlayfs mount units > > > +# > > > +# It's often desired in Embedded System design to have a read-only > rootfs. > > > +# But a lot of different applications might want to have a read-write > access to > > > +# some parts of a filesystem. It can be especially useful when your > update mechanism > > > +# overwrites the whole rootfs, but you want your application data to > be preserved > > > +# between updates. This class provides a way to achieve that by means > > > +# of overlayfs and at the same time keeping the base rootfs read-only. > > > +# > > > +# Usage example. > > > +# > > > +# Set a mount point for a partition overlayfs is going to use as > upper layer > > > +# in your machine configuration. Underlying file system can be > anything that > > > +# is supported by overlayfs. This has to be done in your machine > configuration. > > > +# QA check fails to catch file existence if you redefine this > variable in your recipe! > > > +# > > > +# OVERLAYFS_MOUNT_POINT[data] ?= "/data" > > > +# > > > +# The class assumes you have a data.mount systemd unit defined in your > > > +# systemd-machine-units recipe and installed to the image. > > > +# > > > +# Then you can specify writable directories on a recipe base > > > +# > > > +# OVERLAYFS_WRITABLE_PATHS[data] = > "/usr/share/my-custom-application" > > > +# > > > +# To support several mount points you can use a different variable > flag. Assume we > > > +# want to have a writable location on the file system, but not > interested where the data > > > +# survive a reboot. Then we could have a mnt-overlay.mount unit for a > tmpfs file system: > > > +# > > > +# OVERLAYFS_MOUNT_POINT[mnt-overlay] = "/mnt/overlay" > > > +# OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = > "/usr/share/another-application" > > > +# > > > +# Note: the class does not support /etc directory itself, because > systemd depends on it > > > > > > Many thanks for this new class and the corresponding documentation. > > Richard, I guess that's something we'll need to document in the manual, > > once it's merge, right? > > Ideally, yes, correct. > > Cheers, > > Richard > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154560): https://lists.openembedded.org/g/openembedded-core/message/154560 Mute This Topic: https://lists.openembedded.org/mt/84706478/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
