mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Cory Tusar <cory.tusar@zii.aero>,
	Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 5/7] fs: Add a driver to access U-Boot environment variables
Date: Tue, 28 May 2019 19:05:35 -0700	[thread overview]
Message-ID: <CAHQ1cqHhYgfhojuRq6Czq4eW9Nuu=8LE79qszwuomcou3JFESg@mail.gmail.com> (raw)
In-Reply-To: <20190528095616.dlzxgutxlgkvuvxk@pengutronix.de>

On Tue, May 28, 2019 at 2:56 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> On Mon, May 27, 2019 at 01:18:51PM -0700, Andrey Smirnov wrote:
> > Add a driver working on top of ubootvar device and exposing U-Boot
> > environment variable data as files.
> >
> > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> > Signed-off-by: Cory Tusar <cory.tusar@zii.aero>
> > ---
> >  fs/Kconfig      |   8 +
> >  fs/Makefile     |   1 +
> >  fs/ubootvarfs.c | 499 ++++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 508 insertions(+)
> >  create mode 100644 fs/ubootvarfs.c
> >
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index e3a95321c..adf281a5b 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -118,4 +118,12 @@ config FS_RATP
> >         This enables support for transferring files over RATP. A host can
> >         export a directory which can then be mounted under barebox.
> >
> > +config FS_UBOOTVARFS
> > +     bool
> > +     depends on UBOOTVAR
> > +     prompt "U-Boot environment variable filesystem support"
> > +     help
> > +       This filesystem driver provides access to U-Boot environment
> > +       variables.
> > +
> >  endmenu
> > diff --git a/fs/Makefile b/fs/Makefile
> > index ac3e6a03a..9889a6507 100644
> > --- a/fs/Makefile
> > +++ b/fs/Makefile
> > @@ -18,3 +18,4 @@ obj-$(CONFIG_FS_SMHFS) += smhfs.o
> >  obj-$(CONFIG_FS_PSTORE) += pstore/
> >  obj-$(CONFIG_FS_SQUASHFS) += squashfs/
> >  obj-$(CONFIG_FS_RATP)        += ratpfs.o
> > +obj-$(CONFIG_FS_UBOOTVARFS) += ubootvarfs.o
> > diff --git a/fs/ubootvarfs.c b/fs/ubootvarfs.c
> > new file mode 100644
> > index 000000000..8de97b2de
> > --- /dev/null
> > +++ b/fs/ubootvarfs.c
> > @@ -0,0 +1,499 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 Zodiac Inflight Innovations
> > + */
> > +
> > +#define pr_fmt(fmt) "ubootvarfs: " fmt
> > +
> > +#include <common.h>
> > +#include <driver.h>
> > +#include <init.h>
> > +#include <malloc.h>
> > +#include <fs.h>
> > +#include <string.h>
> > +#include <errno.h>
> > +#include <linux/stat.h>
> > +#include <xfuncs.h>
> > +#include <fcntl.h>
> > +#include <efi.h>
> > +#include <wchar.h>
> > +#include <linux/err.h>
> > +#include <linux/ctype.h>
> > +
> > +/**
> > + * Some theory of operation:
> > + *
> > + * U-Boot environment variable data is expected to be presented as a
> > + * single blob containing an arbitrary number "<key>=<value>\0" paris
>
> s/paris/pairs/
>
> > + * without any other auxiliary information (accomplished by ubootvar
> > + * driver)
> > + *
> > + * Filesystem driver code in this file parses above data an creates a
> > + * linked list of all of the "variables" found (see @ubootvarfs_var to
> > + * what information is recorded).
> > + *
> > + * With that in place reading or writing file data becomes as trivial
> > + * as looking up a variable in the linked list by name and then
> > + * memcpy()-ing bytes from its value region.
> > + *
> > + * The only moderately tricky part is resising a given file/variable
>
> s/resising/resizing/
>
> > + * since, given the underlying data format, it requires us to move all
> > + * of the key/value data that comes after the given file/variable as
> > + * well as to adjust all of the cached offsets stored in varaible
>
> s/varaible/variable/
>
> > + * linked list. See ubootvarfs_adjust() for the implementation
> > + * details.
>
> Wouldn't it be easier and more straight forward to serialize and
> deserialize the U-Boot environment as a whole rather than trying to
> adjust an in-memory representation each time the env is changed?
>

Eh, I don't think it'll save much if at all. Ubootvarfs_create() might
loose a couple of lines of code, ubootvarfs_adjust() and
ubootvarfs_relocate_tail() will go away, but new code to do
serialization would partially negate gains there. Ubootvarfs_unlink()
will probably loose a line or two ubootvarfs_truncate() would probably
remain equally weird, just in a different way.

OTOH, going that way would mean that all of the data would have to be
cached twice (once in ubootvar blob and then seprartely in
ubootvarfs_var elements of the list) as well as having to do a bunch
of unnecessary data processing. Given typical data size those problems
are probably negligible, but combined with the fact that all of the
code would have to be re-tested it makes me less than eager to go that
way.

I can make this change if you insist, but if it is up to me, I'd rather not.

> > +static int ubootvarfs_create(struct inode *dir, struct dentry *dentry,
> > +                          umode_t mode)
> > +{
> > +     struct super_block *sb = dir->i_sb;
> > +     struct fs_device_d *fsdev = container_of(sb, struct fs_device_d, sb);
> > +     struct ubootvarfs_data *data = fsdev->dev.priv;
> > +     struct inode *inode;
> > +     struct ubootvarfs_var *var;
> > +     size_t len = strlen(dentry->name);
> > +     /*
> > +      * We'll be adding <varname>=\0\0 to the end of our data, so
> > +      * we need to make sure there's enough room for it. Note that
> > +      * + 3 is to accoutn for '=', and two '\0' from above
>
> s/accoutn/account/
>
> > +static void ubootvarfs_remove(struct device_d *dev)
> > +{
> > +     struct ubootvarfs_data *data = dev->priv;
> > +
> > +     flush(data->fd);
> > +     close(data->fd);
> > +     free(data);
> > +}
>
> So the environment is written only when the FS is unmounted. We might
> want to have some other method to trigger writing. I don't know how this
> method may look yet though.
>

One idea would be to add .fsync() callback to FS drivers struct as
well as implement "fsync" command that will go through all of the
filesystems and call their ->fsync() methods.

Thanks,
Andrey Smirnov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2019-05-29  2:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27 20:18 [PATCH 0/7] U-Boot environment data as a filesystem Andrey Smirnov
2019-05-27 20:18 ` [PATCH 1/7] filetype: Add "U-Boot environmemnt variable data" filetype Andrey Smirnov
2019-05-27 20:18 ` [PATCH 2/7] filetype: Allow specifying cdev's filetype explicitly Andrey Smirnov
2019-05-27 20:18 ` [PATCH 3/7] drivers: Introduce late_platform_driver() Andrey Smirnov
2019-05-27 20:18 ` [PATCH 4/7] misc: Add a driver to expose U-Boot environment variable data Andrey Smirnov
2019-05-28  9:34   ` Sascha Hauer
2019-05-29  1:19     ` Andrey Smirnov
2019-05-29  5:25       ` Sascha Hauer
2019-05-27 20:18 ` [PATCH 5/7] fs: Add a driver to access U-Boot environment variables Andrey Smirnov
2019-05-28  9:56   ` Sascha Hauer
2019-05-29  2:05     ` Andrey Smirnov [this message]
2019-05-29  6:08       ` Sascha Hauer
2019-05-27 20:18 ` [PATCH 6/7] ARM: rdu2: Add U-Boot environment partitions Andrey Smirnov
2019-05-28  9:57   ` Sascha Hauer
2019-05-29  0:56     ` Andrey Smirnov
2019-05-27 20:18 ` [PATCH 7/7] ARM: rdu1: Add U-Boot environment partition Andrey Smirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHQ1cqHhYgfhojuRq6Czq4eW9Nuu=8LE79qszwuomcou3JFESg@mail.gmail.com' \
    --to=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=cory.tusar@zii.aero \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox