mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Michael Olbrich <m.olbrich@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 0/2] efivarfs: rework the filesystem to make it human readable
Date: Mon, 13 Mar 2017 18:19:58 +0800	[thread overview]
Message-ID: <FD96AE73-808A-45E0-AF81-86F03DD28BC7@jcrosoft.com> (raw)
In-Reply-To: <20170313082042.clsq2tqito7tt7h7@pengutronix.de>


> On 13 Mar 2017, at 4:20 PM, Michael Olbrich <m.olbrich@pengutronix.de> wrote:
> 
> Hi,
> 
> On Mon, Mar 13, 2017 at 08:24:42AM +0100, Sascha Hauer wrote:
>> On Thu, Mar 09, 2017 at 03:38:40PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> 	Sascha is this one ok?
>> 
>> I asked Michael to have a look at this series, so far he didn't find
>> time.
> 
> I'm not sure I like it this way. The old way matches what the Linux kernel
> does so it's familiar. And the mix of guids and 'names' is rather
> cluttered because they are not grouped separately.
we can split them in sub dirs

/efivars/by-guid/<guid>/var

and keep the known one in

/efivars/Efi/…
/efivars/barebox/…
/efivars/systemd/…

as we will use known guid for most of the time

as does linux too most of the time

> Maybe keep the old version and add something like the by-name etc. symlinks
> used in udev:
> 
> <guid-for-foo>-bar
> <something>
>  EFI
>    [...]
>  foo
>    bar -> ../../<guid-for-foo>-bar

<guid-for-foo>-bar is un readable 

and we need to parse a filename which is a prone to error even when creating new variable
and today we only allow to create var for barebox guid in the "user space”
So this is easier to handle

and when you ls it at the end is hard to read

The efivarfs is for user not C Code 

That’s why I prefer to have a design that is easy to read

Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2017-03-13 10:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 15:27 Jean-Christophe PLAGNIOL-VILLARD
2017-03-03 15:31 ` [PATCH 1/2] ls: allow to list a symlink ending with '/' as a dir Jean-Christophe PLAGNIOL-VILLARD
2017-03-03 15:31   ` [PATCH 2/2] efivarfs: rework the filesystem to make it human readable Jean-Christophe PLAGNIOL-VILLARD
2017-03-09 14:38 ` [PATCH 0/2] " Jean-Christophe PLAGNIOL-VILLARD
2017-03-13  7:24   ` Sascha Hauer
2017-03-13  8:20     ` Michael Olbrich
2017-03-13 10:19       ` Jean-Christophe PLAGNIOL-VILLARD [this message]

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=FD96AE73-808A-45E0-AF81-86F03DD28BC7@jcrosoft.com \
    --to=plagnioj@jcrosoft.com \
    --cc=barebox@lists.infradead.org \
    --cc=m.olbrich@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