From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hVnyP-0007Um-1L for barebox@lists.infradead.org; Wed, 29 May 2019 02:05:50 +0000 Received: by mail-io1-xd43.google.com with SMTP id u25so425610iot.13 for ; Tue, 28 May 2019 19:05:48 -0700 (PDT) MIME-Version: 1.0 References: <20190527201853.18853-1-andrew.smirnov@gmail.com> <20190527201853.18853-6-andrew.smirnov@gmail.com> <20190528095616.dlzxgutxlgkvuvxk@pengutronix.de> In-Reply-To: <20190528095616.dlzxgutxlgkvuvxk@pengutronix.de> From: Andrey Smirnov Date: Tue, 28 May 2019 19:05:35 -0700 Message-ID: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: [PATCH 5/7] fs: Add a driver to access U-Boot environment variables To: Sascha Hauer Cc: Cory Tusar , Barebox List On Tue, May 28, 2019 at 2:56 AM Sascha Hauer 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 > > Signed-off-by: Cory Tusar > > --- > > 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 > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/** > > + * Some theory of operation: > > + * > > + * U-Boot environment variable data is expected to be presented as a > > + * single blob containing an arbitrary number "=\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 =\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