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