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.yli...@intel.com> wrote: > > Hi, > > On Fri, Jan 27, 2017 at 6:05 PM, Wold, Saul <saul.w...@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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-intel -- _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
