Thanks for reviewing these. Since they look fine to you and my build went well I went ahead and merged them.

Thanks,
Cal

On 02/05/2017 08:51 PM, Jianxun Zhang wrote:
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

Reply via email to