From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilias Apalodimas Date: Thu, 19 Mar 2020 11:30:33 +0200 Subject: [RFC 11/14] efi_loader: variable: export variables table for runtime access In-Reply-To: <20200318015343.GS13880@linaro.org> References: <20200317021247.5849-1-takahiro.akashi@linaro.org> <20200317021247.5849-12-takahiro.akashi@linaro.org> <20200318015343.GS13880@linaro.org> Message-ID: <20200319093033.GA2230@apalos.home> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Akashi-san, On Wed, Mar 18, 2020 at 10:53:45AM +0900, AKASHI Takahiro wrote: > On Tue, Mar 17, 2020 at 08:37:47AM +0100, Heinrich Schuchardt wrote: > > On 3/17/20 3:12 AM, AKASHI Takahiro wrote: > > > There are platforms on which OS's won't be able to access UEFI variables > > > at runtime (i.e. after ExitBootServices). > > > With this patch, all the UEFI variables are exported as a configuration > > > table so as to enable retrieving variables' values from the table, and > > > later modifying them via capsule-on-disk if necessary. > > > > I do not understand why we should expose our internal memory for holding > > UEFI variables to the operating system. This might end up in users > > trying to access the variables directly. > > I think that you somehow misunderstand my code as it never exposes > any "internal memory," although I don't know what it exactly means in > this context. > This configuration table is nothing but a list of data that represent > all the UEFI variables in implementation-agnostic format. > > > I do not understand why we should not keep the pointer in our private > > memory. > > Anyway, this patch naively implements Peter's proposal while I also > submitted another patch[1] that allows HL-OS to use GetVariable > interface directly via *caching*. How are the two approaches going to affect existig tools (i.e efivar --list) to read the variables? > > Since how we should enable accessing UEFI variables at runtime is > one of key issues, I'd rather discuss in boot-arch ML as I suggested > in the cover letter. > I have already re-activated the discussion there[2]. > Please make your comments there for wider audience. > > [1] https://lists.denx.de/pipermail/u-boot/2019-June/371769.html > [2] https://lists.linaro.org/pipermail/boot-architecture/2020-March/001149.html > Will do Regards /Ilias