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
