On Tue, May 28, 2019 at 07:05:35PM -0700, Andrey Smirnov wrote: > On Tue, May 28, 2019 at 2:56 AM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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@xxxxxxxxx> > > > Signed-off-by: Cory Tusar <cory.tusar@xxxxxxxx> > > > --- > > > 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. I don't care that much, hopefully I'll never have to look at this code again ;) > > > > 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. This sounds good at first. One thing I see is that both the U-Boot and barebox environment is normally actively saved. You normally don't expect that a fsync has effects that the user doesn't want to have (at least not at the moment). Anyway, we can leave this topic for later. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
