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
prev parent 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