public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2 1/1] efi_loader: prepare for read only OP-TEE variables
Date: Wed, 24 Jun 2020 15:29:34 +0900	[thread overview]
Message-ID: <20200624062934.GA13531@laputa> (raw)
In-Reply-To: <0b809a09-6194-a909-504d-67648d2049a2@gmx.de>

On Wed, Jun 24, 2020 at 07:51:42AM +0200, Heinrich Schuchardt wrote:
> On 6/23/20 1:44 AM, AKASHI Takahiro wrote:
> > On Mon, Jun 22, 2020 at 06:10:27PM +0200, Heinrich Schuchardt wrote:
> >> We currently have two implementations of UEFI variables:
> >>
> >> * variables provided via an OP-TEE module
> >> * variables stored in the U-Boot environment
> >>
> >> Read only variables are up to now only implemented in the U-Boot
> >> environment implementation.
> >>
> >> Provide a common interface for both implementations that allows handling
> >> read-only variables.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >> v2:
> >> 	add missing efi_variable.h
> >> 	consider attributes==NULL in efi_variable_get()
> >> ---
> >>  include/efi_variable.h               |  40 +++++++
> >>  lib/efi_loader/Makefile              |   1 +
> >>  lib/efi_loader/efi_variable.c        | 171 ++++++++-------------------
> >>  lib/efi_loader/efi_variable_common.c |  79 +++++++++++++
> >>  lib/efi_loader/efi_variable_tee.c    |  75 ++++--------
> >>  5 files changed, 188 insertions(+), 178 deletions(-)
> >>  create mode 100644 include/efi_variable.h
> >>  create mode 100644 lib/efi_loader/efi_variable_common.c
> >>
> >> diff --git a/include/efi_variable.h b/include/efi_variable.h
> >> new file mode 100644
> >> index 0000000000..784dbd9cf4
> >> --- /dev/null
> >> +++ b/include/efi_variable.h
> >
> > I think that all the stuff here should be put in efi_loader.h.
> > I don't see any benefit of having a separate header.
> >
> >
> 
> This is more or less a question of taste. My motivation is:

I can agree, but at the same time, I don't like such an ad-hoc
confusing approach. I think that you should have a firm discipline.

> * efi_loader.h is rather large (805 lines).
> * Other variable functions will be added.
> * The functions defined here are used only in very few places
>   while efi_loader.h is included in 57 files.

If we allow this, we will have a number of small headers,
which will contradict a notion of efi_loader.h.

-Takahiro Akashi

> Best regards
> 
> Heinrich

      reply	other threads:[~2020-06-24  6:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 16:10 [PATCH v2 1/1] efi_loader: prepare for read only OP-TEE variables Heinrich Schuchardt
2020-06-22 23:44 ` AKASHI Takahiro
2020-06-24  5:51   ` Heinrich Schuchardt
2020-06-24  6:29     ` AKASHI Takahiro [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=20200624062934.GA13531@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.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