[meta-intel] [PATCH 1/2] systemd-boot: use RMC database in EFI stub

Jianxun Zhang jianxun.zhang at linux.intel.com
Sun Feb 5 20:51:14 PST 2017


I noticed there are several RMC patches in mailing list and should review them tomorrow. (Just returned from a vacation)

Refer to my initial comment for Saul’s. Appreciate Mikko going through the following up when I was off.


> On Feb 2, 2017, at 12:46 PM, Ylinen, Mikko <mikko.ylinen at intel.com> wrote:
> 
> Hi,
> 
> On Fri, Jan 27, 2017 at 6:05 PM, Wold, Saul <saul.wold at intel.com> wrote:
> On Fri, 2017-01-27 at 15:36 +0200, Mikko Ylinen wrote:
> > systemd-boot's EFI stub can be built in an EFI executable
> > with the kernel, cmdline, and initrd.
> >
> > This commit enables the EFI stub code to use the RMC database
> > and appends the board specific cmdline (KBOOTPARAM) to the
> > built-in cmdline.
> >
> If we are going to expose the KBOOTPARAM this way, shouldn't that be
> done inside of RMC proper and a getter type of API to provide
> KBOOTPARAM directly?
Assuming this thoughts is to the upstream RMC project.

I have to stress my opinion. RMC is designed as a _generic_ file-based centralized solution so that any software (EFI and user space) could get its service within just 1~2 API calls.

KBOOTPARAM and how to parse or use its content is too client-specific. (Even the name “KBOOMPARAM” is derived from kernel doc, nothing about RMC).

Packing client-specifc stuff in RMC core could damage the scalability in the future. Say, how could we support bootloaders that need different behavior of KBOOTPARAM in RMC?

I understand people want to get rid of another copy of this logic, and am thinking maybe we should have a new file/API in systemd-boot as the shim (?)

Thanks



> 
> Makes a lot of sense to me. However, until that API is in place, I'd suggest
> we use what I'm proposing for the stub here (that's the same approach used with
> the full bootloader as well).
Just want to point out the a small difference between main bootloader and stub at this point. the main is implemented with single-action APIs for a potentially better performance when query multiple files. The stub uses double-action API to simplify the code because it only read one file so far.
> 
> -- Mikko 
> -- 
> _______________________________________________
> meta-intel mailing list
> meta-intel at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel



More information about the meta-intel mailing list