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

Cal Sullivan california.l.sullivan at intel.com
Mon Feb 6 10:36:19 PST 2017


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.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